draft-ietf-smime-x400wrap-09.txt   rfc3854.txt 
S/MIME Working Group
Internet Draft Paul Hoffman, IMC
draft-ietf-smime-x400wrap-09.txt Chris Bonatti, IECA
August 14, 2003 Anders Eggen, FFI
Expires February 14, 2004
Securing X.400 Content with S/MIME Network Working Group P. Hoffman
Request for Comments: 3854 IMC
Category: Standards Track C. Bonatti
IECA
A. Eggen
FFI
July 2004
Securing X.400 Content with Secure/Multipurpose Internet Mail
Extensions (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 specifies an Internet standards track protocol for the
provisions of Section 10 of RFC2026. Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Internet-Drafts are working documents of the Internet Engineering Task Copyright Notice
Force (IETF), its areas, and its working groups. Note that other groups
may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Copyright (C) The Internet Society (2004).
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at Abstract
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at This document describes a protocol for adding cryptographic signature
http://www.ietf.org/shadow.html. and encryption services to X.400 content with Secure/Multipurpose
Internet Mail Extensions (S/MIME).
Abstract 1. Introduction
This document describes a protocol for adding cryptographic signature The techniques described in the Cryptographic Message Syntax [CMS]
and encryption services to X.400 content. specification are general enough to support many different content
types. The [CMS] specification thus provides many options for
providing different security mechanisms. In order to ensure
interoperability of systems within the X.400 community, it is
necessary to specify the use of CMS features to protect X.400 content
(called "CMS-X.400" in this document).
1. Introduction 1.1. Specification Overview
The techniques described in the Cryptographic Message Syntax [CMS] This document is intended to be similar to the S/MIME Version 3.1
specification are general enough to support many different content Message Specification [MSG] except that it is tailored to the
types. The [CMS] specification thus provides many options for providing requirements of X.400 content rather than Multipurpose Internet Mail
different security mechanisms. In order to ensure interoperability of Extensions (MIME).
systems within the X.400 community, it is necessary to specify the use
of CMS features to protect X.400 content (called "CMS-X.400" in this
document).
1.1 Specification Overview This document defines how to create an X.400 content type that has
been cryptographically enhanced according to [CMS]. In order to
create S/MIME messages carrying X.400 content, an S/MIME agent has to
follow specifications in this document, as well as the specifications
listed in [CMS]. This memo also defines new parameter values for the
application/pkcs7-mime MIME type that can be used to transport those
body parts.
This document is intended to be similar to the S/MIME Version 3 Message Throughout this document, there are requirements and recommendations
Specification [MSG] except that it is tailored to the requirements of made for how receiving agents handle incoming messages. There are
X.400 content rather than Multipurpose Internet Mail Extensions (MIME). separate requirements and recommendations for how sending agents
create outgoing messages. In general, the best strategy is to "be
liberal in what you receive and conservative in what you send". Most
of the requirements are placed on the handling of incoming messages
while the recommendations are mostly on the creation of outgoing
messages.
This document defines how to create an X.400 content type that has been This document does not address transport of CMS-X.400 content. It is
cryptographically enhanced according to [CMS]. In order to create S/MIME assumed that CMS-X.400 content would be transported by Internet mail
messages carrying X.400 content, an S/MIME agent has to follow systems, X.400, or other suitable transport.
specifications in this document, as well as the specifications listed in
[CMS]. This memo also defines new parameter values for the
application/pkcs7-mime MIME type that can be used to transport those
body parts.
Throughout this document, there are requirements and recommendations This document describes applying security services to the content of
made for how receiving agents handle incoming messages. There are entire X.400 messages, which may or may not be IPMS messages. These
separate requirements and recommendations for how sending agents create objects can be carried by several means, including SMTP-based mail
outgoing messages. In general, the best strategy is to "be liberal in and X.400 mail. Note that cooperating S/MIME agents must support
what you receive and conservative in what you send". Most of the common forms of message content in order to achieve interoperability.
requirements are placed on the handling of incoming messages while the
recommendations are mostly on the creation of outgoing messages.
This document does not address transport of CMS-X.400 content. It is If the CMS objects are sent as parts of an RFC 822 message, a
assumed that CMS-X.400 content would be transported by Internet mail standard MIXER gateway [MIXER] will most likely choose to encapsulate
systems, X.400, or other suitable transport. the message. This is not likely to be a format that is usable by an
X.400 recipient. MIXER is specifically focused on translation
between X.420 Interpersonal Messages and non-secure RFC822/MIME
messages. The discussion of security-related body parts in sections
7.3 and 7.4 of [BODYMAP] is relevant to CMS messages.
This document describes applying security services to the content of Definition of gateway services to support relay of CMS object between
entire X.400 messages, which may or may not be IPMS messages. These X.400 and SMTP environments is beyond the scope of this document.
objects can be carried by several means, including SMTP-based mail and
X.400 mail. Note that cooperating S/MIME agents must support common
forms of message content in order to achieve interoperability.
If the CMS objects are sent as parts of an RFC 822 message, a standard 1.2. Terminology
MIXER gateway [MIXER] will most likely choose to encapsulate the
message. This is not likely to be a format that is usable by an X.400
recipient. MIXER is specifically focused on translation between X.420
Interpersonal Messages and non-secure RFC822/MIME messages. The
discussion of security- related body parts in sections 7.3 and 7.4 of
[BODYMAP] is relevant to CMS messages.
Definition of gateway services to support relay of CMS object between The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
X.400 and SMTP environments is beyond the scope of this document. and "MAY" in this document are to be interpreted as described in BCP
14, RFC 2119 [MUSTSHOULD].
1.2 Terminology 1.3. Definitions
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and For the purposes of this document, the following definitions apply.
"MAY" in this document are to be interpreted as described in RFC 2119
[MUSTSHOULD].
1.3 Definitions ASN.1: Abstract Syntax Notation One, as defined in
ISO/IEC 8824.
For the purposes of this document, the following definitions apply. BER: Basic Encoding Rules for ASN.1, as defined in
ISO/IEC 8825-1.
ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824. Certificate: A type that binds an entity's distinguished name
to a public key with a digital signature.
BER: Basic Encoding Rules for ASN.1, as defined in ISO/IEC 8825-1. DER: Distinguished Encoding Rules for ASN.1, as defined
in ISO/IEC 8825-1.
Certificate: A type that binds an entity's distinguished name to a 7-bit data: Text data with lines less than 998 characters
public key with a digital signature. long, where none of the characters have the 8th
bit set, and there are no NULL characters. <CR>
and <LF> occur only as part of a <CR><LF> end of
line delimiter.
DER: Distinguished Encoding Rules for ASN.1, as defined in ISO/IEC 8-bit data: Text data with lines less than 998 characters, and
8825-1. where none of the characters are NULL characters.
<CR> and <LF> occur only as part of a <CR><LF> end
of line delimiter.
7-bit data: Text data with lines less than 998 characters long, where Binary data: Arbitrary data.
none of the characters have the 8th bit set, and there are no NULL
characters. <CR> and <LF> occur only as part of a <CR><LF> end of line
delimiter.
8-bit data: Text data with lines less than 998 characters, and where Transfer Encoding: A reversible transformation made on data so 8-bit
none of the characters are NULL characters. <CR> and <LF> occur only as or binary data may be sent via a channel that only
part of a <CR><LF> end of line delimiter. transmits 7-bit data.
Binary data: Arbitrary data. Receiving agent: Software that interprets and processes S/MIME CMS
objects.
Transfer Encoding: A reversible transformation made on data so 8-bit or Sending agent: Software that creates S/MIME CMS objects.
binary data may be sent via a channel that only transmits 7-bit data.
Receiving agent: Software that interprets and processes S/MIME CMS S/MIME agent: User software that is a receiving agent, a sending
objects. agent, or both.
Sending agent: Software that creates S/MIME CMS objects. 1.4. Compatibility with Prior Practice of S/MIME
S/MIME agent: User software that is a receiving agent, a sending agent, There are believed to be no existing X.400 implementations that
or both. support S/MIME version 2. Further, signed interoperability between
X.400 and MIME systems that support S/MIME version 2 is not believed
to be easily achievable. Therefore backward compatibility with
S/MIME version 2 is not considered to be a requirement for this
document.
1.4 Compatibility with Prior Practice of S/MIME It is a goal of this document to, if possible, maintain backward
compatibility with existing X.400 implementations that employ S/MIME
v3.1 wrappers.
There are believed to be no existing X.400 implementations that support 2. CMS Options
S/MIME version 2. Further, signed interoperability between X.400 and
MIME systems that support S/MIME version 2 is not believed to be easily
achievable. Therefore backward compatibility with S/MIME version 2 is
not considered to be a requirement for this document.
It is a goal of this draft to, if possible, maintain backward CMS allows for a wide variety of options in content and algorithm
compatibility with existing X.400 implementations that employ S/MIME v3 support. This section puts forth a number of support requirements
wrappers. and recommendations in order to achieve a base level of
interoperability among all CMS-X.400 implementations. [CMS] provides
additional details regarding the use of the cryptographic algorithms.
2. CMS Options 2.1. DigestAlgorithmIdentifier
CMS allows for a wide variety of options in content and algorithm Sending and receiving agents MUST support SHA-1 [CMSALG].
support. This section puts forth a number of support requirements and
recommendations in order to achieve a base level of interoperability
among all CMS-X.400 implementations. [CMS] provides additional details
regarding the use of the cryptographic algorithms.
2.1 DigestAlgorithmIdentifier 2.2. SignatureAlgorithmIdentifier
Sending and receiving agents MUST support SHA-1 [CMSALG]. Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG].
The algorithm parameters MUST be absent (not encoded as NULL).
Receiving agents MUST support rsaEncryption, defined in [CMSALG].
2.2 SignatureAlgorithmIdentifier Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption.
Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG]. The 2.3. KeyEncryptionAlgorithmIdentifier
algorithm parameters MUST be absent (not encoded as NULL). Receiving
agents MUST support rsaEncryption, defined in [CMSALG].
Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption. Sending and receiving agents MUST support rsaEncryption, defined in
[CMSALG].
2.3 KeyEncryptionAlgorithmIdentifier Sending and receiving agents SHOULD support Diffie-Hellman defined in
[CMSALG].
Sending and receiving agents MUST support rsaEncryption, defined in 2.4. General Syntax
[CMSALG].
Sending and receiving agents SHOULD support Diffie-Hellman defined in The general syntax of CMS objects consist of an instance of the
[CMSALG]. ContentInfo structure containing one of several defined CMS content
types. CMS defines multiple content types. Of these, only the
SignedData and EnvelopedData content types are used for CMS-X.400.
2.4 General Syntax 2.4.1. SignedData Content Type
The general syntax of CMS objects consist of an instance of the Sending agents MUST use the signedData content type to apply a
ContentInfo structure containing one of several defined CMS content digital signature to a message or, in a degenerate case where there
types. CMS defines multiple content types. Of these, only the SignedData is no signature information, to convey certificates.
and EnvelopedData content types are used for CMS-X.400.
2.4.1 SignedData Content Type 2.4.2. EnvelopedData Content Type
Sending agents MUST use the signedData content type to apply a digital Senders MUST use the envelopedData content type to apply privacy
signature to a message or, in a degenerate case where there is no protection to a message. A sender needs to have access to a public
signature information, to convey certificates. key for each intended message recipient to use this service. This
content type does not provide authentication.
2.4.2 EnvelopedData Content Type 2.5. Attribute SignerInfo Type
Senders MUST use the envelopedData content type to apply privacy The SignerInfo type allows the inclusion of unsigned and signed
protection to a message. A sender needs to have access to a public key attributes to be included along with a signature.
for each intended message recipient to use this service. This content
type does not provide authentication.
2.5 Attribute SignerInfo Type Receiving agents MUST be able to handle zero or one instance of each
of the signed attributes listed here. Sending agents SHOULD generate
one instance of each of the following signed attributes in each CMS-
X400 message:
The SignerInfo type allows the inclusion of unsigned and signed - signingTime
attributes to be included along with a signature. - sMIMECapabilities
- sMIMEEncryptionKeyPreference
Receiving agents MUST be able to handle zero or one instance of each of Requirements for processing of these attributes MUST be in accordance
the signed attributes listed here. Sending agents SHOULD generate one with the S/MIME Message Specification [MSG]. Handling of the
instance of each of the following signed attributes in each CMS-X400 signingTime attribute MUST comply with clause 2.5.1 of [MSG].
message: Handling of the sMIMECapabilities attribute MUST comply with clause
- signingTime 2.5.2 of [MSG]. Handling of the sMIMEEncryptionKeyPreference
- sMIMECapabilities attribute MUST comply with clause 2.5.3 of [MSG].
- sMIMEEncryptionKeyPreference
Requirements for processing of these attributes MUST be in accordance Further, receiving agents SHOULD be able to handle zero or one
with the S/MIME Message Specification [MSG]. Handling of the signingTime instance in the signed attributes of the signingCertificate attribute
attribute MUST comply with clause 2.5.1 of [MSG]. Handling of the [ESS].
sMIMECapabilities attribute MUST comply with clause 2.5.2 of [MSG].
Handling of the sMIMEEncryptionKeyPreference attribute MUST comply with
clause 2.5.3 of [MSG].
Further, receiving agents SHOULD be able to handle zero or one instance Sending agents SHOULD generate one instance of the signingCertificate
in the signed attributes of the signingCertificate attribute [ESS]. signed attribute in each CMS-X400 message.
Sending agents SHOULD generate one instance of the signingCertificate Additional attributes and values for these attributes may be defined
signed attribute in each CMS-X400 message. in the future. Receiving agents SHOULD handle attributes or values
that they do not recognize in a graceful manner.
Additional attributes and values for these attributes may be defined in Sending agents that include signed attributes that are not listed
the future. Receiving agents SHOULD handle attributes or values that it here SHOULD display those attributes to the user, so that the user is
does not recognize in a graceful manner. aware of all of the data being signed.
Sending agents that include signed attributes that are not listed here 2.6. ContentEncryptionAlgorithmIdentifier
SHOULD display those attributes to the user, so that the user is aware
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" [CMSALG]. Sending
and receiving agents SHOULD support encryption and decryption with
AES [CMSAES] at a key size of 128, 192 and 256 bits.
Sending and receiving agents MUST support encryption and decryption 3. Creating S/MIME Messages
with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Sending
and receiving agents SHOULD support encryption and decryption with AES
[CMSAES] at a key size of 128, 192 and 256 bits.
3. Creating S/MIME Messages 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 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, such as certificates and algorithm identifiers, are
given to CMS processing facilities which produces a CMS object. This
document also describes how nested, secured S/MIME messages should be
formatted when encapsulating an X.400 content, and provides an
example of how a triple-wrapped S/MIME message over X.400 content
should be created if backwards compatibility with S/MIME version 2 is
of no concern.
This section describes the S/MIME message formats and how they can be S/MIME provides one format for enveloped-only data, several formats
used to secure X.400 contents. The S/MIME messages are a combination of for signed-only data, and several formats for signed and enveloped
X.400 contents and CMS objects (i.e., a ContentInfo structure containing data. The different formats are required to accommodate several
one of the CMS-defined content types). The X.400 content and other data, environments, in particular for signed messages. Only one of these
such as certificates and algorithm identifiers, are given to CMS signed formats is applicable to X.400.
processing facilities which produces a CMS object. This document also
describes how nested, secured S/MIME messages should be formatted when
encapsulating an X.400 content, and provides an example of how a
triple-wrapped S/MIME message over X.400 content should be created if
backwards compatibility with S/MIME version 2 is of no concern.
S/MIME provides one format for enveloped-only data, several formats for Note that canonicalization is not required for X.400 content because
signed-only data, and several formats for signed and enveloped data. The it is a binary rather than text encoding, and only the "embedded"
different formats are required to accommodate several environments, in content version is used. These dramatically simplify the description
particular for signed messages. Only one of these signed formats is of S/MIME productions.
applicable to X.400.
Note that canonicalization is not required for X.400 content because it The reader of this section is expected to understand X.400 as
is a binary rather than text encoding, and only the "embedded" content described in [X.400] and S/MIME as described in [CMS] and [ESS].
version is used. These dramatically simplify the description of S/MIME
productions.
The reader of this section is expected to understand X.400 as described 3.1. The X.400 Message Structure
in [X.400] and S/MIME as described in [CMS] and [ESS].
3.1 The X.400 Message Structure This section reviews the X.400 message format. An X.400 message has
two parts, the envelope and the content, as described in X.402
[X.400]:
This section reviews the X.400 message format. An X.400 message has two Envelope -- An information object whose composition varies from one
parts, the envelope and the content, as described in X.402 [X.400]: transmittal step to another and that variously identifies the
message's originator and potential recipients, documents its previous
conveyance and directs its subsequent conveyance by the Message
Transfer System (MTS), and characterizes its content.
Envelope -- An information object whose composition varies from one Content -- The content is the piece of information that the
transmittal step to another and that variously identifies the message's originating User Agent wants to be delivered to one or more
originator and potential recipients, documents its previous conveyance recipients. The MTS neither examines nor modifies the content,
and directs its subsequent conveyance by the Message Transfer System except for conversion, during its conveyance of the message. MTS
(MTS), and characterizes its content. conversion is not applicable to the scenario of this document because
such conversion is incompatible with CMS protection mechanisms.
Content -- The content is the piece of information that the originating One piece of information borne by the envelope identifies the type of
User Agent wants to be delivered to one or more recipients. The MTS the content. The content type is an identifier (an ASN.1 OID or
neither examines nor modifies the content, except for conversion, during Integer) that denotes the syntax and semantics of the content
its conveyance of the message. MTS conversion is not applicable to the overall. This identifier enables the MTS to determine the message's
scenario of this draft because such conversion is incompatible with CMS deliverability to particular users, and enables User Agents and
protection mechanisms. Message Stores to interpret and process the content.
One piece of information borne by the envelope identifies the type of Another piece of information borne by the envelope identifies the
the content. The content type is an identifier (an ASN.1 OID or Integer) types of encoded information represented in the content. An encoded
that denotes the syntax and semantics of the content overall. This information type (EIT) is an identifier (an ASN.1 Object Identifier
identifier enables the MTS to determine the message's deliverability to or Integer) that denotes the medium and format (e.g., IA5 text or
particular users, and enables User Agents and Message Stores to Group 3 facsimile) of individual portions of the content. It further
interpret and process the content. enables the MTS to determine the message's deliverability to
particular users, and to identify opportunities for it to make the
message deliverable by converting a portion of the content from one
EIT to another.
Another piece of information borne by the envelope identifies the types This document describes how S/MIME CMS is used to secure the content
of encoded information represented in the content. An encoded part of X.400 messages.
information type (EIT) is an identifier (an ASN.1 Object Identifier or
Integer) that denotes the medium and format (e.g., IA5 text or Group 3
facsimile) of individual portions of the content. It further enables the
MTS to determine the message's deliverability to particular users, and
to identify opportunities for it to make the message deliverable by
converting a portion of the content from one EIT to another.
This document describes how S/MIME CMS is used to secure the content 3.2. Creating a Signed-only Message with X.400 Content
part of X.400 messages.
3.2 Creating a Signed-only Message with X.400 Content The SignedData format as described in the Cryptographic Message
Syntax [CMS] MUST be used for signing of X.400 contents.
The SignedData format as described in the Cryptographic Message Syntax The X.400 content to be protected MUST be placed in the SignedData
[CMS] MUST be used for signing of X.400 contents. encapContentInfo eContent field. Note that this X.400 content SHOULD
maintain the encoding defined by the content type, but SHOULD NOT be
MIME wrapped. The object identifier for the content type of the
protected X.400 content MUST be placed in the SignedData
encapContentInfo eContentType field.
The X.400 content to be protected MUST be placed in the SignedData The signedData object is encapsulated by a ContentInfo SEQUENCE with
encapContentInfo eContent field. Note that this X.400 content SHOULD a contentType of id-signedData.
maintain the encoding defined by the content type, but SHOULD NOT be
MIME wrapped. The object identifier for the content type of the
protected X.400 content MUST be placed in the SignedData
encapContentInfo eContentType field.
The signedData object is encapsulated by a ContentInfo SEQUENCE with a Note that if SMTP [SMTP] is used to transport the resulting signed-
contentType of id-signedData. only message then the optional MIME encoding SHOULD be used. If
binary transports such as X.400 are used then the optional MIME
encoding SHOULD NOT be used.
Note that if SMTP [SMTP] is used to transport the resulting signed-only There are many reasons for this requirement. An outer MIME wrapper
message then the optional MIME encoding SHOULD be used. If binary should not be used in X.400. Further, there are places where X.400
transports such as X.400 are used then the optional MIME encoding SHOULD systems will interact with SMTP/MIME systems where the outer MIME
NOT be used. wrapper might be necessary. Because this wrapping is outside the
security wrappers, any gateway system that might bridge the gap
between the two systems will be smart enough to apply or remove the
outer MIME wrapper as appropriate.
There are many reasons for this requirement. An outer MIME wrapper 3.2.1. MIME Wrapping to Dynamically Support 7-bit Transport
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, any gateway system that might bridge 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 The signedData object MAY optionally be wrapped in MIME. This allows
the system to support 7-bit transport when required. This outer MIME
wrapper MAY be dynamically added or removed throughout the delivery
path since it is outside the signature and encryption wrappers. In
this case the application/pkcs7-mime type as defined in S/MIME
Version 3.1 Message Specification [MSG] SHOULD be used with the
following parameters:
The signedData object MAY optionally be wrapped in MIME. This allows Content-Type: application/pkcs7-mime; smime-type=signed-x400
the system to support 7-bit transport when required. This outer MIME Content-Transfer-Encoding: base64
wrapper MAY be dynamically added or removed throughout the delivery path
since it is outside the signature and encryption wrappers. In this
case the application/pkcs7-mime type as defined in S/MIME Version 3
Message Specification [MSG] SHOULD be used with the following
parameters:
Content-Type: application/pkcs7-mime; smime-type=signed-x400 If the application/pkcs7-mime MIME type is used to support 7-bit
Content-Transfer-Encoding: base64 transport, the steps to create this format are:
If the application/pkcs7-mime MIME type is used to support 7-bit Step 1. The X.400 content to be signed is ASN.1 encoded.
transport, the steps to create this format are:
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
processed into a CMS object of type SignedData. The SignedData
structure is encapsulated by a ContentInfo SEQUENCE with a
contentType of id-signedData.
Step 2. The ASN.1 encoded X.400 content and other required data is Step 3. The CMS object is inserted into an application/pkcs7-mime
processed into a CMS object of type SignedData. The SignedData structure MIME entity.
is encapsulated by a ContentInfo SEQUENCE with a contentType of
id-signedData.
Step 3. The CMS object is inserted into an application/pkcs7-mime MIME The smime-type parameter for messages using application/pkcs7-mime
entity. with SignedData is "signed-x400" as defined in [TRANSPORT].
The smime-type parameter for messages using application/pkcs7-mime with 3.3. Creating an Enveloped-only Message with X.400 Content
SignedData is "signed-x400" as defined in [TRANSPORT].
3.3 Creating an Enveloped-only Message with X.400 Content This section describes the format for enveloping an X.400 content
without signing it. It is important to note that sending enveloped
but not signed messages does not provide for data integrity. It is
possible to replace ciphertext in such a way that the processed
message will still be valid, but the meaning is altered.
This section describes the format for enveloping an X.400 content The EnvelopedData format as described in [CMS] is used for
without signing it. It is important to note that sending enveloped but confidentiality of the X.400 contents.
not signed messages does not provide for data integrity. It is possible
to replace ciphertext in such a way that the processed message will
still be valid, but the meaning is altered.
The EnvelopedData format as described in [CMS] is used for The X.400 content to be protected MUST be placed in the EnvelopedData
confidentiality of the X.400 contents. encryptedContentInfo encryptedContent field. Note that this X.400
content SHOULD maintain the encoding defined by the content type, but
SHOULD NOT be MIME wrapped. The object identifier for content type
of the protected X.400 content MUST be placed in the EnvelopedData
encryptedContentInfo contentType field.
The X.400 content to be protected MUST be placed in the EnvelopedData The envelopedData object is encapsulated by a ContentInfo SEQUENCE
encryptedContentInfo encryptedContent field. Note that this X.400 with a contentType of id-envelopedData.
content SHOULD maintain the encoding defined by the content type, but
SHOULD NOT be MIME wrapped. The object identifier for content type of
the protected X.400 content MUST be placed in the EnvelopedData
encryptedContentInfo contentType field.
The envelopedData object is encapsulated by a ContentInfo SEQUENCE with Note that if SMTP is used to transport the resulting enveloped-only
a contentType of id-envelopedData. message then the optional MIME encoding SHOULD be used. If other
transport (e.g., X.400) that is optimized for binary content is used
then the optional MIME encoding SHOULD NOT be used.
Note that if SMTP is used to transport the resulting enveloped-only 3.3.1. MIME Wrapping to Dynamically Support 7-bits Transport
message then the optional MIME encoding SHOULD be used. If other
transport (e.g., X.400) that is optimized for binary content is used
then the optional MIME encoding SHOULD NOT be used.
3.3.1 MIME Wrapping to Dynamically Support 7-bits Transport The envelopedData object MAY optionally be wrapped in MIME. This
allows the system to support 7-bit transport when required. This
outer MIME wrapper MAY be dynamically added or removed throughout the
delivery path since it is outside the signature and encryption
wrappers. In this case, the application/pkcs7-mime type as defined
in S/MIME Version 3.1 Message Specification [MSG] SHOULD be used with
the following parameters:
The envelopedData object MAY optionally be wrapped in MIME. This allows Content-Type: application/pkcs7-mime; smime-type=enveloped-x400
the system to support 7-bit transport when required. This outer MIME Content-Transfer-Encoding: base64
wrapper MAY be dynamically added or removed throughout the delivery path
since it is outside the signature and encryption wrappers. In this
case, the application/pkcs7-mime type as defined in S/MIME Version 3
Message Specification [MSG] SHOULD be used with the following
parameters:
Content-Type: application/pkcs7-mime; smime-type=enveloped-x400 If the application/pkcs7-mime MIME type is used to support 7-bit
Content-Transfer-Encoding: base64 transport, the steps to create this format are:
If the application/pkcs7-mime MIME type is used to support 7-bit Step 1. The X.400 content to be enveloped is ASN.1 encoded.
transport, the steps to create this format are:
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
processed into a CMS object of type EnvelopedData. In addition to
encrypting a copy of the content-encryption key for each recipient, a
copy of the content encryption key SHOULD be encrypted for the
originator and included in the EnvelopedData (see [CMS] Section 6).
The EnvelopedData structure is encapsulated by a ContentInfo SEQUENCE
with a contentType of id-envelopedData.
Step 2. The ASN.1 encoded X.400 content and other required data is Step 3. The CMS object is inserted into an application/pkcs7-mime
processed into a CMS object of type EnvelopedData. In addition to MIME entity to allow for 7-bit transport.
encrypting a copy of the content-encryption key for each recipient, a
copy of the content encryption key SHOULD be encrypted for the
originator and included in the EnvelopedData (see CMS Section 6). The
EnvelopedData structure is encapsulated by a ContentInfo SEQUENCE with a
contentType of id-envelopedData.
Step 3. The CMS object is inserted into an application/pkcs7-mime MIME If the application/pkcs7-mime MIME entity is used, the smime-type
entity to allow for 7-bit transport. parameter for enveloped-only messages is "enveloped-x400" as defined
in [TRANSPORT].
If the application/pkcs7-mime MIME entity is used, the smime-type 3.4. Nested CMS Structures
parameter for enveloped-only messages is "enveloped-x400" as defined in
[TRANSPORT].
3.4 Nested CMS Structures To achieve signing and enveloping, any of the signed-only and
encrypted-only CMS objects may be nested.
To achieve signing and enveloping, any of the signed-only and When nesting is used, backwards compatibility with S/MIME version 2
encrypted-only CMS objects may be nested. requires that each layer of the nested message are identified with
the OID id-data, and when id-data is used a MIME wrapper is required.
This can potentially lead to an enormous amount of overhead and
should be avoided. Because S/MIME version 2 compatibility is of no
concern, implementations SHOULD directly encode the encapsulated
object as the eContent of the current structure.
When nesting is used, backwards compatibility with S/MIME version 2 MIME wrapping to support 7-bit transport is optional and need only be
requires that each layer of the nested message are identified with the used around the outermost CMS structure. In this case, the
OID id-data, and when id-data is used a MIME wrapper is required. This application/pkcs7 content type MUST be used.
can potentially lead to an enormous amount of overhead and should be
avoided. Because S/MIME version 2 compatibility is of no concern,
implementations SHOULD directly encode the encapsulated object as the
eContent of the current structure.
MIME wrapping to support 7-bit transport is optional and need only be An S/MIME implementation MUST be able to receive and process
used around the outermost CMS structure. In this case, the arbitrarily nested CMS structures within reasonable resource limits
application/pkcs7 content type MUST be used. of the recipient computer.
An S/MIME implementation MUST be able to receive and process arbitrarily 3.4.1. Creating a Triple Wrapped Message With an X.400 Content
nested CMS structures within reasonable resource limits of the recipient
computer.
3.4.1 Creating a Triple Wrapped Message With an X.400 Content The Enhanced Security Services for S/MIME [ESS] document provides
examples of how nested, secured S/MIME messages are formatted. ESS
provides an example of how a triple-wrapped S/MIME message is
formatted using application/pkcs7-mime for the signatures.
The Enhanced Security Services for S/MIME [ESS] document provides This section explains how an X.400 content may be conveyed within a
examples of how nested, secured S/MIME messages are formatted. ESS Triple Wrapped Message because S/MIME version 2 compatibility is of
provides an example of how a triple-wrapped S/MIME message is formatted no concern:
using application/pkcs7-mime for the signatures.
This section explains how an X.400 content may be conveyed within a Step 1. Start with the X.400 content (called the "original
Triple Wrapped Message because S/MIME version 2 compatibility is of no content"). The X.400 content MUST be ASN.1 encoded, but SHOULD NOT
concern: be MIME wrapped.
Step 1. Start with the X.400 content (called the "original content"). Step 2. Place the ASN.1 encoded X.400 content to be protected in the
The X.400 content MUST be ASN.1 encoded, but SHOULD NOT be MIME wrapped. SignedData encapContentInfo eContent field. Add any attributes that
are to be signed.
Step 2. Place the ASN.1 encoded X.400 content to be protected in the Step 3. Sign the result of step 2 (the original content). The
SignedData encapContentInfo eContent field. Add any attributes SignedData encapContentInfo eContentType MUST contain the object
that are to be signed. identifier of the X.400 content.
Step 3. Sign the result of step 2 (the original content). The SignedData Step 4. Encrypt the result of step 3 as a single block. The
encapContentInfo eContentType MUST contain the object identifier of the EnvelopedData encryptedContentInfo contentType MUST be set to id-
X.400 content. signedData. This is called the "encrypted body".
Step 4. Encrypt the result of step 3 as a single block. The Step 5. Using the same logic as in step 2 and 3 above, sign the
EnvelopedData encryptedContentInfo contentType MUST be set to result of step 4 (the encrypted body) as a single block. The
id-signedData. This is called the "encrypted body". SignedData encapContentInfo eContentType MUST be set to id-
envelopedData. The outer SignedData structure is encapsulated by a
ContentInfo SEQUENCE with a contentType of id-signedData.
Step 5. Using the same logic as in step 2 and 3 above, sign the result Step 6. The resulting message is called the "outer signature", and
of step 4 (the encrypted body) as a single block. The SignedData is also the triple wrapped message.
encapContentInfo eContentType MUST be set to id-envelopedData. The outer
SignedData structure is encapsulated by a ContentInfo SEQUENCE with a
contentType of id-signedData.
Step 6. The resulting message is called the "outer signature", and is MIME wrapping to support 7-bit transport is optional and MUST only be
also the triple wrapped message. used around the outermost CMS structure. In this case, the
application/pkcs7-mime content type MUST be used. The smime-type in
the case of adding a MIME wrapper MUST be consistent with that
appropriate to the innermost protection layer.
MIME wrapping to support 7-bit transport is optional and MUST only be In some instances, an smime-type will be created that only reflects
used around the outermost CMS structure. In this case, the one security service (such as certs-only, which applies only to
application/pkcs7-mime content type MUST be used. The smime-type signed-only messages). However, as new layers are wrapped, this
in the case of adding a MIME wrapper MUST be consistent with smime-type SHOULD be propagated upwards. Thus if a certs-only
that appropriate to the innermost protection layer. message were to be encrypted, or wrapped in a new SignedData
structure, the smime-type of certs-only should be propagated up to
the next MIME wrapper. In other words, the innermost type is
reflected outwards.
In some instances, an smime-type will be created that only reflects one 3.5. Carrying Plaintext X.400 Content in SMTP
security service (such as certs-only, which applies only to signed-
only messages). However, as new layers are wrapped, this smime-type
SHOULD be propagated upwards. Thus if a certs-only message were to be
encrypted, or wrapped in a new SignedData structure, the smime-type of
certs-only should be propagated up to the next MIME wrapper. In other
words, the innermost type is reflected outwards.
3.5 Carrying Plaintext X.400 Content in SMTP While the objectives of this document focus on protecting X.400
content with CMS wrappers, it is a reality that users do not
generally send all message using security. It therefore stands to
reason that a means to carry non-secured X.400 content over the
chosen transport system must be seamlessly provided. While
transporting X.400 content in an X.400 system is trivial, carrying
X.400 content in SMTP requires additional definition.
While the objectives of this draft focus on protecting X.400 content Content-Type: application/x400-content; content-type = 1*DIGIT *( "."
with CMS wrappers, it is a reality that users do not generally send 1*DIGIT)
all message using security. It therefore stands to reason that a
means to carry non-secured X.400 content over the chosen transport
system must be seemlessly provided. While transporting X.400 content
in an X.400 system is trivial, carrying X.400 content in SMTP
requires additional definition.
Content-Type: application/x400-content; content-type = where the content-type parameter value is either a single integer
1*DIGIT *( "." 1*DIGIT) (for a built-in content-type) or an OID in dotted notation (for an
extended content-type).
where the content-type parmeter value is either a single integer (for 4. Use of Certificates
a built-in content-type) or an OID in dotted notation (for an extended
content-type).
4. Use of Certificates 4.1. Certificate Enrollment
4.1 Certificate Enrollment S/MIME v3.1 does not specify how to get a certificate from a
certificate authority, but instead mandates that every sending agent
already has a certificate. The PKIX Working Group has, at the time
of this writing, produced two separate standards for certificate
enrollment: CMP (RFC 2510) and CMC (RFC 2792).
S/MIME v3 does not specify how to get a certificate from a certificate 4.2. Certificate Processing
authority, but instead mandates that every sending agent already has a
certificate. The PKIX Working Group has, at the time of this writing,
produced two separate standards for certificate enrollment: CMP (RFC
2510) and CMC (RFC 2792).
4.2 Certificate Processing A receiving agent MUST provide some certificate retrieval mechanism
in order to gain access to certificates for recipients of digital
envelopes. This document does not cover how S/MIME agents handle
certificates, only what they do after a certificate has been
validated or rejected. S/MIME certification issues are covered in
[CERT31].
A receiving agent MUST provide some certificate retrieval mechanism in At a minimum, for initial S/MIME deployment, a user agent could
order to gain access to certificates for recipients of digital automatically generate a message to an intended recipient requesting
envelopes. This document does not cover how S/MIME agents handle that recipient's certificate in a signed return message. Receiving
certificates, only what they do after a certificate has been validated and sending agents SHOULD also provide a mechanism to allow a user to
or rejected. S/MIME certification issues are covered in [CERT31]. "store and protect" certificates for correspondents in such a way so
as to guarantee their later retrieval.
At a minimum, for initial S/MIME deployment, a user agent could 4.3. Certificate Name Use for X.400 Content
automatically generate a message to an intended recipient requesting
that recipient's certificate in a signed return message. Receiving and
sending agents SHOULD also provide a mechanism to allow a user to "store
and protect" certificates for correspondents in such a way so as to
guarantee their later retrieval.
4.3. Certificate Name Use for X.400 Content End-entity certificates used in the context of this document MAY
contain an X.400 address as described in [X.400]. The address must
be in the form of an "ORAddress". The X.400 address SHOULD be in the
subjectAltName extension, and SHOULD NOT be in the subject
distinguished name.
End-entity certificates used in the context of this draft MAY contain Sending agents SHOULD make the originator address in the X.400
an X.400 address as described in [X.400]. The address must be in the content (e.g., the "originator" field in P22) match an X.400 address
form of an "ORAddress". The X.400 address SHOULD be in the subjectAltName in the signer's certificate.
extension, and SHOULD NOT be in the subject distinguished name.
Sending agents SHOULD make the originator address in the X.400 content Receiving agents MUST recognize X.400 addresses in the subjectAltName
(e.g., the "originator" field in P22) match an X.400 address in the field.
signer's certificate.
Receiving agents MUST recognize X.400 addresses in the subjectAltName Receiving agents SHOULD check that the originator address in the
field. X.400 content matches an X.400 address in the signer's certificate,
if X.400 addresses are present in the certificate and an originator
address is available in the content. A receiving agent SHOULD
provide some explicit alternate processing of the message if this
comparison fails, which may be to display a message that shows the
recipient the addresses in the certificate or other certificate
details.
Receiving agents SHOULD check that the originator address in the X.400 The subject alternative name extension is used in S/MIME as the
content matches an X.400 address in the signer's certificate, if X.400 preferred means to convey the X.400 address(es) that correspond to
addresses are present in the certificate and an originator address is the entity for this certificate. Any X.400 addresses present MUST be
available in the content. A receiving agent SHOULD provide some explicit encoded using the x400Address CHOICE of the GeneralName type. Since
alternate processing of the message if this comparison fails, which may be the SubjectAltName type is a SEQUENCE OF GeneralName, multiple X.400
to display a message that shows the recipient the addresses in the addresses MAY be present.
certificate or other certificate details.
The subject alternative name extension is used in S/MIME as the preferred 5. Security Considerations
means to convey the X.400 address(es) that correspond to the entity for
this certificate. Any X.400 addresses present MUST be encoded using the
x400Address CHOICE of the GeneralName type. Since the SubjectAltName type
is a SEQUENCE OF GeneralName, multiple X.400 addresses MAY be present.
5. Security Considerations This specification introduces no new security concerns to the CMS or
S/MIME models. Security issues are identified in section 5 of [MSG],
section 6 of [ESS] and the Security Considerations section of [CMS].
This specification introduces no new security concerns to the CMS or 6. References
S/MIME models. Security issues are identified in section 5 of [MSG],
section 6 of [ESS] and the Security Considerations section of [CMS].
A. References 6.1. Normative References
A.1 Normative References [CERT31] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Certificate Handling",
RFC 3850, July 2004.
[CERT31] Ramsdell, B., Editor, "S/MIME Version 3 Certificate [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
Handling", Internet-Draft draft-ietf-smime-rfc2632bis. 3852, July 2004.
[CMS] Housley, R., "Cryptographic Message Syntax", Internet-Draft [CMSAES] Schaad, J., "Use of the AES Encryption Algorithm in
draft-ietf-smime-rfc2630bis. CMS", RFC 3565, July 2003.
[CMSAES] J. Schaad, "Use of the AES Encryption Algorithm in CMS", [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
Internet Draft draft-ietf-smime-aes-alg. Algorithms", RFC 3370, August 2002.
[CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", Internet- [ESS] Hoffman, P., Editor "Enhanced Security Services for
Draft draft-ietf-smime-cmsalg S/MIME", RFC 2634, June 1999.
[ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME", [MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
RFC 2634, June 1999. Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, July 2004.
[MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Internet-Draft draft-ietf-smime-rfc2633bis. Requirement Levels", BCP 14, RFC 2119, March 1997.
[TRANSPORT] Hoffman, P. and Bonatti, C., "Transporting S/MIME Objects in [TRANSPORT] Hoffman, P. and C. Bonatti, "Transporting
X.400", work in progress (will progress with this document). Secure/Multipurpose Internet Mail Extensions (S/MIME)
Objects in X.400", RFC 3855, July 2004.
[X.400] ITU-T X.400 Series of Recommendations, Information technology [X.400] ITU-T X.400 Series of Recommendations, Information
- Message Handling Systems (MHS). X.400: System and Service Overview; technology - Message Handling Systems (MHS). X.400:
X.402: Overall Architecture; X.411: Message Transfer System: Abstract System and Service Overview; X.402: Overall
Service Definition and Procedures; X.420: Interpersonal Messaging Architecture; X.411: Message Transfer System: Abstract
System; 1996. Service Definition and Procedures; X.420: Interpersonal
Messaging System; 1996.
A.2 Non-normative References 6.2. Informative References
[BODYMAP] Alvestrand, H., Editor, "Mapping between X.400 and [BODYMAP] Alvestrand, H., Ed., "Mapping between X.400 and RFC-
RFC-822/MIME Message Bodies", RFC 2157, January 1998. 822/MIME Message Bodies", RFC 2157, January 1998.
[MIXER] Kille, S., Editor, "MIXER (Mime Internet X.400 Enhanced [MIXER] Kille, S., Ed., "MIXER (Mime Internet X.400 Enhanced
Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, Relay): Mapping between X.400 and RFC 822/MIME", RFC
January 1998. 2156, January 1998.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
Requirement Levels", BCP14, RFC 2119, March 1997. April, 2001.
[SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 7. Editors' Addresses
April, 2001.
B. Editor's Address Paul Hoffman
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA 95060 USA
Paul Hoffman EMail: phoffman@imc.org
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA 95060 USA
phoffman@imc.org
Chris Bonatti Chris Bonatti
IECA, Inc. IECA, Inc.
15309 Turkey Foot Road 15309 Turkey Foot Road
Darnestown, MD 20878-3640 USA Darnestown, MD 20878-3640 USA
bonattic@ieca.com
Anders Eggen EMail: bonattic@ieca.com
Forsvarets Forskningsinstitutt
Postboks 25
2027 Kjeller, Norway
anders.eggen@ffi.no
draft-ietf-smime-x400wrap-09.txt expires February 14, 2004. Anders Eggen
Forsvarets Forskningsinstitutt
Postboks 25
2027 Kjeller, Norway
EMail: anders.eggen@ffi.no
8. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 157 change blocks. 
463 lines changed or deleted 479 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/