draft-ietf-smime-x400wrap-03.txt   draft-ietf-smime-x400wrap-04.txt 
Internet Draft Paul Hoffman, IMC Internet Draft Paul Hoffman, IMC
draft-ietf-smime-x400wrap-03.txt Chris Bonatti, IECA draft-ietf-smime-x400wrap-04.txt Chris Bonatti, IECA
July 19, 2001 Anders Eggen, FFI August 27, 2001 Anders Eggen, FFI
Expires in six months Expires in six months
Securing X.400 Content with S/MIME Securing X.400 Content with S/MIME
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
skipping to change at line 203 skipping to change at line 203
signed attribute in each CMS-X400 message. signed attribute in each CMS-X400 message.
Additional attributes and values for these attributes may be defined in Additional attributes and values for these attributes may be defined in
the future. Receiving agents SHOULD handle attributes or values that it the future. Receiving agents SHOULD handle attributes or values that it
does not recognize in a graceful manner. does not recognize in a graceful manner.
Sending agents that include signed attributes that are not listed here Sending agents that include signed attributes that are not listed here
SHOULD display those attributes to the user, so that the user is aware SHOULD display those attributes to the user, so that the user is aware
of all of the data being signed. of all of the data being signed.
2.6 ContentEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support encryption and decryption
with DES EDE3 CBC, hereinafter called "tripleDES" [3DES] [DES].
3. Creating S/MIME Messages 3. Creating S/MIME Messages
This section describes the S/MIME message formats and how they can be This section describes the S/MIME message formats and how they can be
used to secure X.400 contents. The S/MIME messages are a combination of used to secure X.400 contents. The S/MIME messages are a combination of
X.400 contents and CMS objects (i.e., a ContentInfo structure containing X.400 contents and CMS objects (i.e., a ContentInfo structure containing
one of the CMS-defined content types). The X.400 content and other data, one of the CMS-defined content types). The X.400 content and other data,
such as certificates and algorithm identifiers, are given to CMS such as certificates and algorithm identifiers, are given to CMS
processing facilities which produces a CMS object. This document also processing facilities which produces a CMS object. This document also
describes how nested, secured S/MIME messages should be formatted when describes how nested, secured S/MIME messages should be formatted when
encapsulating an X.400 content, and provides an example of how a encapsulating an X.400 content, and provides an example of how a
skipping to change at line 273 skipping to change at line 278
This document describes how S/MIME CMS is used to secure the content This document describes how S/MIME CMS is used to secure the content
part of X.400 messages. part of X.400 messages.
3.2 Creating a Signed-only Message with X.400 Content 3.2 Creating a Signed-only Message with X.400 Content
The SignedData format as described in the Cryptographic Message Syntax The SignedData format as described in the Cryptographic Message Syntax
[CMS] MUST be used for signing of X.400 contents. [CMS] MUST be used for signing of X.400 contents.
The protected X.400 content MUST be placed in the SignedData The protected X.400 content MUST be placed in the SignedData
encapContentInfo eContent field. The eContent field MUST either (a) encapContentInfo eContent field. Note that this X.400 content SHOULD
contain the contentType OID and MUST NOT be MIME-wrapped or (b) contain maintain the encoding defined by the content type, but SHOULD NOT be
the id-data OID and a MIME-wrapped content. The object identifier for MIME wrapped. The object identifier for content type of the protected
content type of the protected X.400 content MUST be placed in the X.400 content MUST be placed in the SignedData encapContentInfo
SignedData encapContentInfo eContentType field. eContentType field.
The signedData object is encapsulated by a ContentInfo SEQUENCE with a The signedData object is encapsulated by a ContentInfo SEQUENCE with a
contentType of id-signedData. The resulting CMS object MAY optionally be contentType of id-signedData. The resulting CMS object MAY optionally be
wrapped in a MIME encoding. wrapped in a MIME encoding.
Note that if SMTP [SMTP] used to transport the resulting signed-only Note that if SMTP [SMTP] is used to transport the resulting signed-only
message then the optional MIME encoding SHOULD be used. If binary message then the optional MIME encoding SHOULD be used. If binary
transports such as X.400 are used then the optional MIME encoding SHOULD transports such as X.400 are used then the optional MIME encoding SHOULD
NOT be used. NOT be used.
There are many reasons for this requirement. An outer MIME wrapper
should not be used in X.400. Further, there are places where X.400
systems will interact with SMTP/MIME systems where the outer MIME
wrapper might be necessary. Because this wrapping is outside the
security wrappers, whatever gateway system that is bridging the gap
between the two systems will be smart enough to apply or remove the
outer MIME wrapper as appropriate.
3.2.1 MIME Wrapping to Dynamically Support 7-bit Transport 3.2.1 MIME Wrapping to Dynamically Support 7-bit Transport
The signedData object MAY optionally be wrapped in MIME to dynamically The signedData object MAY optionally be wrapped in MIME to dynamically
support 7-bit transport. In this case the application/pkcs7-mime type as support 7-bit transport. In this case the application/pkcs7-mime type as
defined in S/MIME Version 3 Message Specification [MSG] SHOULD be used defined in S/MIME Version 3 Message Specification [MSG] SHOULD be used
with the following parameters: with the following parameters:
Content-Type: application/pkcs7-mime; smime-type=signed-data Content-Type: application/pkcs7-mime; smime-type=signed-x400
Content-Transfer-Encoding: base64 Content-Transfer-Encoding: base64
If the application/pkcs7-mime MIME type is used to support 7-bit If the application/pkcs7-mime MIME type is used to support 7-bit
transport, the steps to create this format are: transport, the steps to create this format are:
Step 1. The X.400 content to be signed is ASN.1 encoded. Step 1. The X.400 content to be signed is ASN.1 encoded.
Step 2. The ASN.1 encoded X.400 content and other required data is Step 2. The ASN.1 encoded X.400 content and other required data is
processed into a CMS object of type SignedData. The SignedData structure processed into a CMS object of type SignedData. The SignedData structure
is encapsulated by a ContentInfo SEQUENCE with a contentType of is encapsulated by a ContentInfo SEQUENCE with a contentType of
skipping to change at line 474 skipping to change at line 487
guarantee their later retrieval. guarantee their later retrieval.
5. Security Considerations 5. Security Considerations
This entire document discusses security. Additional security issues are This entire document discusses security. Additional security issues are
identified in section 5 of [MSG], section 6 of [ESS] and the Security identified in section 5 of [MSG], section 6 of [ESS] and the Security
Considerations section of [CMS]. Considerations section of [CMS].
A. References A. References
[3DES] ANSI X9.52-1998, "Triple Data Encryption Algorithm Modes of
Operation", American National Standards Institute, 1998.
[CERT3] Ramsdell, B., Editor, "S/MIME Version 3 Certificate [CERT3] Ramsdell, B., Editor, "S/MIME Version 3 Certificate
Handling", RFC 2632, June 1999. Handling", RFC 2632, June 1999.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June
1999. 1999.
[DES] ANSI X3.106, "American National Standard for Information Systems-
Data Link Encryption," American National Standards Institute, 1983.
[DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, [DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631,
June 1999. June 1999.
[DSS] NIST FIPS PUB 186, "Digital Signature Standard", 18 May 1994. [DSS] NIST FIPS PUB 186, "Digital Signature Standard", 18 May 1994.
[ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME", [ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
[MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", [MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification",
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/