draft-ietf-smime-x400wrap-07.txt   draft-ietf-smime-x400wrap-08.txt 
S/MIME Working Group S/MIME Working Group
Internet Draft Paul Hoffman, IMC Internet Draft Paul Hoffman, IMC
draft-ietf-smime-x400wrap-07.txt Chris Bonatti, IECA draft-ietf-smime-x400wrap-08.txt Chris Bonatti, IECA
June 29, 2003 Anders Eggen, FFI August 8, 2003 Anders Eggen, FFI
Expires December 29, 2003 Expires February 8, 2004
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
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
skipping to change at line 226 skipping to change at line 226
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 2.6 ContentEncryptionAlgorithmIdentifier
Sending and receiving agents MUST support encryption and decryption Sending and receiving agents MUST support encryption and decryption
with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Sending and with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Sending
receiving agents SHOULD support encryption and decryption using the AES and receiving agents SHOULD support encryption and decryption with AES
algorithm [AES]. [CMSAES] at a key size of 128, 192 and 256 bits.
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
skipping to change at line 318 skipping to change at line 318
Note that if SMTP [SMTP] is 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 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 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 systems will interact with SMTP/MIME systems where the outer MIME
wrapper might be necessary. Because this wrapping is outside the wrapper might be necessary. Because this wrapping is outside the
security wrappers, whatever gateway system that is bridging the gap security wrappers, any gateway system that might bridge the gap
between the two systems will be smart enough to apply or remove the between the two systems will be smart enough to apply or remove the
outer MIME wrapper as appropriate. 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. This allows The signedData object MAY optionally be wrapped in MIME. This allows
the system to support 7-bit transport when required. This outer MIME the system to support 7-bit transport when required. This outer MIME
wrapper MAY be dynamically added or removed throughout the delivery path wrapper MAY be dynamically added or removed throughout the delivery path
since it is out the signature and encryption wrappers. In this case the since it is outside the signature and encryption wrappers. In this
application/pkcs7-mime type as defined in S/MIME Version 3 Message case the application/pkcs7-mime type as defined in S/MIME Version 3
Specification [MSG] SHOULD be used with the following parameters: Message Specification [MSG] SHOULD be used with the following
parameters:
Content-Type: application/pkcs7-mime; smime-type=signed-x400 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
skipping to change at line 372 skipping to change at line 373
encryptedContentInfo encryptedContent field. Note that this X.400 encryptedContentInfo encryptedContent field. Note that this X.400
content SHOULD maintain the encoding defined by the content type, but content SHOULD maintain the encoding defined by the content type, but
SHOULD NOT be MIME wrapped. The object identifier for content type of SHOULD NOT be MIME wrapped. The object identifier for content type of
the protected X.400 content MUST be placed in the EnvelopedData the protected X.400 content MUST be placed in the EnvelopedData
encryptedContentInfo contentType field. encryptedContentInfo contentType field.
The envelopedData object is encapsulated by a ContentInfo SEQUENCE with The envelopedData object is encapsulated by a ContentInfo SEQUENCE with
a contentType of id-envelopedData. a contentType of id-envelopedData.
Note that if SMTP is used to transport the resulting enveloped-only Note that if SMTP is used to transport the resulting enveloped-only
message then the optional MIME encoding SHOULD be used. If other binary message then the optional MIME encoding SHOULD be used. If other
transport (e.g., X.400) is used then the optional MIME encoding SHOULD transport (e.g., X.400) that is optimized for binary content is used
NOT be used. then the optional MIME encoding SHOULD NOT be used.
3.3.1 MIME Wrapping to Dynamically Support 7-bits Transport 3.3.1 MIME Wrapping to Dynamically Support 7-bits Transport
The envelopedData object MAY optionally be wrapped in MIME. This allows The envelopedData object MAY optionally be wrapped in MIME. This allows
the system to support 7-bit transport when required. This outer MIME the system to support 7-bit transport when required. This outer MIME
wrapper MAY be dynamically added or removed throughout the delivery path wrapper MAY be dynamically added or removed throughout the delivery path
since it is out the signature and encryption wrappers. In this case, since it is outside the signature and encryption wrappers. In this
the application/pkcs7-mime type as defined in S/MIME Version 3 Message case, the application/pkcs7-mime type as defined in S/MIME Version 3
Specification [MSG] SHOULD be used with the following parameters: Message Specification [MSG] SHOULD be used with the following
parameters:
Content-Type: application/pkcs7-mime; smime-type=enveloped-x400 Content-Type: application/pkcs7-mime; smime-type=enveloped-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 enveloped is ASN.1 encoded. Step 1. The X.400 content to be enveloped 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
skipping to change at line 464 skipping to change at line 466
Step 5. Using the same logic as in step 2 and 3 above, sign the result Step 5. Using the same logic as in step 2 and 3 above, sign the result
of step 4 (the encrypted body) as a single block. The SignedData of step 4 (the encrypted body) as a single block. The SignedData
encapContentInfo eContentType MUST be set to id-envelopedData. The outer encapContentInfo eContentType MUST be set to id-envelopedData. The outer
SignedData structure is encapsulated by a ContentInfo SEQUENCE with a SignedData structure is encapsulated by a ContentInfo SEQUENCE with a
contentType of id-signedData. contentType of id-signedData.
Step 6. The resulting message is called the "outer signature", and is Step 6. The resulting message is called the "outer signature", and is
also the triple wrapped message. also the triple wrapped message.
MIME wrapping to support 7-bit transport, is optional and MUST only be MIME wrapping to support 7-bit transport is optional and MUST only be
used around the outermost CMS structure. In this case, the used around the outermost CMS structure. In this case, the
application/pkcs7-mime content type MUST be used. The smime-type application/pkcs7-mime content type MUST be used. The smime-type
in the case of adding a MIME wrapper MUST be consistent with in the case of adding a MIME wrapper MUST be consistent with
that appropriate to the innermost protection layer. that appropriate to the innermost protection layer.
In some instances, an smime-type will be created that only reflects one In some instances, an smime-type will be created that only reflects one
security service (such as certs-only, which is only for signed). security service (such as certs-only, which applies only to signed-
However, as new layers are wrapped, this smime-type SHOULD be propagated only messages). However, as new layers are wrapped, this smime-type
upwards. Thus if a certs-only message were to be encrypted, or wrapped SHOULD be propagated upwards. Thus if a certs-only message were to be
in a new SignedData structure, the smime-type of certs-only should be encrypted, or wrapped in a new SignedData structure, the smime-type of
propagated up to the next MIME wrapper. In other words, the innermost certs-only should be propagated up to the next MIME wrapper. In other
type is reflected outwards. words, the innermost type is reflected outwards.
3.5 Carrying Plaintext X.400 Content in SMTP 3.5 Carrying Plaintext X.400 Content in SMTP
While the objectives of this draft focus on protecting X.400 content While the objectives of this draft focus on protecting X.400 content
with CMS wrappers, it is a reality that users do not generally send with CMS wrappers, it is a reality that users do not generally send
all message using security. It therefore stands to reason that a all message using security. It therefore stands to reason that a
means to carry non-secured X.400 content over the chosen transport means to carry non-secured X.400 content over the chosen transport
system must be seemlessly provided. While transporting X.400 content system must be seemlessly provided. While transporting X.400 content
in an X.400 system is trivial, carrying X.400 content in SMTP in an X.400 system is trivial, carrying X.400 content in SMTP
requires additional definition. requires additional definition.
skipping to change at line 558 skipping to change at line 560
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
A.1 Normative References A.1 Normative References
[AES] J. Schaad, "Use of the AES Encryption Algorithm in CMS", Internet
Draft draft-ietf-smime-aes-alg.
[CERT31] Ramsdell, B., Editor, "S/MIME Version 3 Certificate [CERT31] Ramsdell, B., Editor, "S/MIME Version 3 Certificate
Handling", Internet-Draft draft-ietf-smime-rfc2632bis. Handling", Internet-Draft draft-ietf-smime-rfc2632bis.
[CMS] Housley, R., "Cryptographic Message Syntax", Internet-Draft [CMS] Housley, R., "Cryptographic Message Syntax", Internet-Draft
draft-ietf-smime-rfc2630bis. draft-ietf-smime-rfc2630bis.
[CMSAES] J. Schaad, "Use of the AES Encryption Algorithm in CMS",
Internet Draft draft-ietf-smime-aes-alg.
[CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", Internet- [CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", Internet-
Draft draft-ietf-smime-cmsalg Draft draft-ietf-smime-cmsalg
[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",
Internet-Draft draft-ietf-smime-rfc2633bis. Internet-Draft draft-ietf-smime-rfc2633bis.
[TRANSPORT] Hoffman, P. and Bonatti, C., "Transporting S/MIME Objects in [TRANSPORT] Hoffman, P. and Bonatti, C., "Transporting S/MIME Objects in
skipping to change at line 620 skipping to change at line 622
15309 Turkey Foot Road 15309 Turkey Foot Road
Darnestown, MD 20878-3640 USA Darnestown, MD 20878-3640 USA
bonattic@ieca.com bonattic@ieca.com
Anders Eggen Anders Eggen
Forsvarets Forskningsinstitutt Forsvarets Forskningsinstitutt
Postboks 25 Postboks 25
2027 Kjeller, Norway 2027 Kjeller, Norway
anders.eggen@ffi.no anders.eggen@ffi.no
draft-ietf-smime-x400wrap-06.txt expires November 1, 2003. draft-ietf-smime-x400wrap-08.txt expires February 8, 2004.
 End of changes. 

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