draft-ietf-smime-x400transport-09.txt   rfc3855.txt 
S/MIME Working Group
Internet Draft Paul Hoffman, IMC
draft-ietf-smime-x400transport-09.txt Chris Bonatti, IECA
August 8, 2003
Expires February 8, 2004
Transporting S/MIME Objects in X.400
Status of this Memo Network Working Group P. Hoffman
Request for Comments: 3855 IMC
Category: Standards Track C. Bonatti
IECA
July 2004
This document is an Internet-Draft and is in full conformance with all Transporting Secure/Multipurpose Internet Mail
provisions of Section 10 of RFC2026. Extensions (S/MIME) Objects in X.400
Internet-Drafts are working documents of the Internet Engineering Task Status of this Memo
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 This document specifies an Internet standards track protocol for the
and may be updated, replaced, or obsoleted by other documents at any Internet community, and requests discussion and suggestions for
time. It is inappropriate to use Internet-Drafts as reference material improvements. Please refer to the current edition of the "Internet
or to cite them other than as "work in progress." Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
The list of current Internet-Drafts can be accessed at Copyright Notice
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at Copyright (C) The Internet Society (2004).
http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes protocol options for conveying CMS-protected This document describes protocol options for conveying objects that
objects associated with S/MIME version 3 over an X.400 message transfer have been protected using the Cryptographic Message Syntax (CMS) and
system. Secure/Multipurpose Internet Mail Extensions (S/MIME) version 3.1
over an X.400 message transfer system.
1. Introduction 1. Introduction
The techniques described in the Cryptographic Message Syntax [CMS] The techniques described in the Cryptographic Message Syntax [CMS]
specification and message specifications can reasonably be transported specification and message specifications can reasonably be
via a variety of electronic mail systems. This specification defines transported via a variety of electronic mail systems. This
the options and values necessary to enable interoperable transport of specification defines the options and values necessary to enable
S/MIME messages over an X.400 system. interoperable transport of S/MIME messages over an X.400 system.
This document describes a mechanism for using CMS objects as the message This document describes a mechanism for using CMS objects as the
content of X.400 messages in a native X.400 environment. This means message content of X.400 messages in a native X.400 environment.
that gateways or other functions that expect to deal with IPMS, such as This means that gateways or other functions that expect to deal with
those specified in [MIXER] and [BODYMAP], cannot do anything with these IPMS, such as those specified in [MIXER] and [BODYMAP], cannot do
messages. Note that cooperating S/MIME agents must support common forms anything with these messages. Note that cooperating S/MIME agents
of message content in order to achieve interoperability. must support common forms of message content in order to achieve
interoperability.
Definition of gateway services to support relay of CMS object between Definition of gateway services to support relay of CMS object between
X.400 and SMTP environments is beyond the scope of this document. X.400 and SMTP environments is beyond the scope of this document.
1.1 Terminology 1.1. Terminology
The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED",
"MAY" in this document are to be interpreted as described in RFC 2119 and "MAY" in this document are to be interpreted as described in BCP
[MUSTSHOULD]. 14, RFC 2119 [MUSTSHOULD].
1.2 Definitions 1.2. Definitions
For the purposes of this document, the following definitions apply. For the purposes of this document, the following definitions apply.
ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824. ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824.
Object Identifier (OID): A globally unique identifier value consisting Object Identifier (OID): A globally unique identifier value
of a sequence of integer values assigned through distributed consisting of a sequence of integer values assigned through
registration as specified by ISO/IEC 8824. distributed registration as specified by ISO/IEC 8824.
Transfer Encoding: A reversible transformation made on data so 8-bit or Transfer Encoding: A reversible transformation made on data so 8-bit
binary data may be sent via a channel that only transmits 7-bit data. or binary data may be sent via a channel that only transmits 7-bit
data.
1.3 Compatibility with Existing S/MIME Implementations 1.3. Compatibility with Existing S/MIME Implementations
It is a goal of this draft to, if possible, maintain backward It is a goal of this document to, if possible, maintain backward
compatibility with existing X.400 implementations that employ S/MIME v3 compatibility with existing X.400 implementations that employ S/MIME
wrappers. v3.1 wrappers.
2. S/MIME Packaging 2. S/MIME Packaging
2.1 The X.400 Message Structure 2.1. The X.400 Message Structure
This section reviews the X.400 message format. An X.400 message has two This section reviews the X.400 message format. An X.400 message has
parts, the envelope and the content, as described in X.402 [X.400]: two parts, the envelope and the content, as described in X.402
[X.400]:
Envelope -- An information object whose composition varies from one Envelope -- An information object whose composition varies from one
transmittal step to another and that variously identifies the message's transmittal step to another and that variously identifies the
originator and potential recipients, documents its previous conveyance message's originator and potential recipients, documents its
and directs its subsequent conveyance by the Message Transfer System previous conveyance and directs its subsequent conveyance by the
(MTS), and characterizes its content. Message Transfer System (MTS), and characterizes its content.
Content -- The content is the piece of information that the originating Content -- The content is the piece of information that the
User Agent wants to be delivered to one or more recipients. The MTS originating User Agent wants to be delivered to one or more
neither examines nor modifies the content, except for conversion, during recipients. The MTS neither examines nor modifies the content,
its conveyance of the message. MTS conversion is not applicable to the except for conversion, during its conveyance of the message. MTS
scenario of this draft because such conversion is incompatible with CMS conversion is not applicable to the scenario of this document
protection mechanisms. because such conversion is incompatible with CMS protection
mechanisms.
One piece of information borne by the envelope identifies the type of One piece of information borne by the envelope identifies the type of
the content. The content type is an identifier (an ASN.1 OID or Integer) the content. The content type is an identifier (an ASN.1 OID or
that denotes the syntax and semantics of the content overall. This Integer) that denotes the syntax and semantics of the content
identifier enables the MTS to determine the message's deliverability to overall. This identifier enables the MTS to determine the message's
particular users, and enables User Agents and Message Stores to deliverability to particular users, and enables User Agents and
interpret and process the content. Message Stores to interpret and process the content.
Some X.400 content types further refine the structure of content as a Some X.400 content types further refine the structure of content as a
set of heading elements and body parts. An example of this is the set of heading elements and body parts. An example of this is the
Interpersonal Messaging System (IPMS). The IPMS content structure is Interpersonal Messaging System (IPMS). The IPMS content structure is
able to convey zero or more arbitrary body parts each identified by the able to convey zero or more arbitrary body parts each identified by
body part type. The body part type is an ASN.1 OID or Integer that the body part type. The body part type is an ASN.1 OID or Integer
denotes the syntax and semantics of the body part in question. that denotes the syntax and semantics of the body part in question.
2.2 Carrying S/MIME as X.400 Content 2.2. Carrying S/MIME as X.400 Content
When transporting a CMS-protected message in X.400, the preferred When transporting a CMS-protected message in X.400, the preferred
approach (except as discussed in section 2.3 below) is to convey the approach (except as discussed in section 2.3 below) is to convey the
object as X.400 message content. This section describes how S/MIME CMS object as X.400 message content. This section describes how S/MIME
objects are conveyed as the content part of X.400 messages. This CMS objects are conveyed as the content part of X.400 messages. This
mechanism is suitable for transport of CMS-protected messages regardless mechanism is suitable for transport of CMS-protected messages
of the mail content that has been encapsulated. regardless of the mail content that has been encapsulated.
Implementations MUST include the CMS object in the content field of the Implementations MUST include the CMS object in the content field of
X.400 message. the X.400 message.
If the CMS object is covered by an outer MIME wrapper, the content-type If the CMS object is covered by an outer MIME wrapper, the content-
field of the P1 envelope MUST be set to the following CMS-defined value: type field of the P1 envelope MUST be set to the following CMS-
defined value:
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 } rsadsi(113549) pkcs(1) pkcs7(7) 1 }
If the CMS object is not covered by an outer MIME wrapper, the If the CMS object is not covered by an outer MIME wrapper, the
content-type field of the P1 envelope MUST be set to the following content-type field of the P1 envelope MUST be set to the following
CMS-defined value: CMS-defined value:
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
content-types(1) 6} content-types(1) 6}
2.2.1 Carrying Plaintext MIME objects as X.400 Content 2.2.1. Carrying Plaintext MIME objects as X.400 Content
When transporting a plaintext MIME object in X.400, the preferred When transporting a plaintext MIME object in X.400, the preferred
approach is to convey the object as X.400 message content. The content- approach is to convey the object as X.400 message content. The
type field of the P1 envelope MUST be set to the following CMS-defined content-type field of the P1 envelope MUST be set to the following
value: CMS-defined value:
id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840)
rsadsi(113549) pkcs(1) pkcs7(7) 1 } rsadsi(113549) pkcs(1) pkcs7(7) 1 }
2.3 Carrying S/MIME as IPMS Body Parts 2.3. Carrying S/MIME as IPMS Body Parts
Under some circumstances S/MIME CMS-protected messages can be conveyed Under some circumstances S/MIME CMS-protected messages can be
within select body parts of the content. Implementations generally conveyed within select body parts of the content. Implementations
SHOULD NOT embed CMS objects within X.400 body parts, but should instead generally SHOULD NOT embed CMS objects within X.400 body parts, but
convey them as content as described in section 2.2. Nevertheless, one should instead convey them as content as described in section 2.2.
notable exception is necessary for the case of forwarding. Nevertheless, one notable exception is necessary for the case of
forwarding.
In instances when CMS objects are forwarded as part of a message In instances when CMS objects are forwarded as part of a message
forwarding function, use of a body part is necessary. When forwarding a forwarding function, use of a body part is necessary. When
CMS object in an IPMS or IPMS-compatible body part, implementations MUST forwarding a CMS object in an IPMS or IPMS-compatible body part,
use the content-body-part as formally defined by [X.400], as shown below implementations MUST use the content-body-part as formally defined by
for reference. [X.400], as shown below for reference.
content-body-part {ExtendedContentType:content-type} content-body-part {ExtendedContentType:content-type}
EXTENDED-BODY-PART-TYPE ::= { EXTENDED-BODY-PART-TYPE ::= {
PARAMETERS {ForwardedContentParameters IDENTIFIED BY PARAMETERS {ForwardedContentParameters IDENTIFIED BY
{id-ep-content -- concatenated with content-type -- }}, {id-ep-content -- concatenated with content-type -- }},
DATA {Content IDENTIFIED BY DATA {Content IDENTIFIED BY
{id-et-content -- concatenated with content-type -- }} } {id-et-content -- concatenated with content-type -- }} }
ForwardedContentParameters ::= SET { ForwardedContentParameters ::= SET {
delivery-time [0] MessageDeliveryTime OPTIONAL, delivery-time [0] MessageDeliveryTime OPTIONAL,
delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL, delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL,
mts-identifier [2] MessageDeliveryIdentifier OPTIONAL} mts-identifier [2] MessageDeliveryIdentifier OPTIONAL }
id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17} id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17}
id-et-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) et(4) 17} id-et-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) et(4) 17}
The implementation MUST copy the CMS object to be forwarded into the The implementation MUST copy the CMS object to be forwarded into the
Content field of the content-body-part. The direct-reference field of Content field of the content-body-part. The direct-reference field
the body part MUST include the OID formed by the concatenation of the of the body part MUST include the OID formed by the concatenation of
id-et-content value and the following CMS-defined value. the id-et-content value and the following CMS-defined value.
id-ct-contentInfo OBJECT IDENTIFIER ::= id-ct-contentInfo OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) content-types(1) 6} pkcs-9(9) smime(16) content-types(1) 6}
For example, to forward any CMS object the DATA component of the body For example, to forward any CMS object the DATA component of the body
part would be identified by { 2 6 1 4 17 1 2 840 113549 1 9 16 1 6 }. part would be identified by { 2 6 1 4 17 1 2 840 113549 1 9 16 1 6 }.
The ForwardedContentParameters are optional and MAY be supported at the The ForwardedContentParameters are optional and MAY be supported at
discretion of the implementor. The OID value id-et-content MAY also be the discretion of the implementor. The OID value id-et-content MAY
included in the original-encoded-information-types field of the X.400 also be included in the original-encoded-information-types field of
message envelope at the discretion of the sending S/MIME agent. the X.400 message envelope at the discretion of the sending S/MIME
agent.
In this instance, the content-type field of the P1 envelope MUST be set In this instance, the content-type field of the P1 envelope MUST be
to the value associate with the forwarding content (e.g., integer 22 for set to the value associate with the forwarding content (e.g., integer
IPMS). 22 for IPMS).
2.4 Transfer Encoding 2.4. Transfer Encoding
According to various S/MIME specifications for message wrapping, CMS According to various S/MIME specifications for message wrapping, CMS
objects MAY optionally be wrapped in MIME to dynamically support 7-bit objects MAY optionally be wrapped in MIME to dynamically support 7-
transport. This outer wrapping is not required for X.400 transport, and bit transport. This outer wrapping is not required for X.400
generally SHOULD NOT be applied in a homogeneous X.400 environment. transport, and generally SHOULD NOT be applied in a homogeneous X.400
Heterogeneous mail systems or other factors MAY require the presence of environment. Heterogeneous mail systems or other factors MAY require
this outer MIME wrapper the presence of this outer MIME wrapper
2.5 Encoded Information Type Indication 2.5. Encoded Information Type Indication
In [MSG], the application/pkcs7-mime content type and optional In [MSG], the application/pkcs7-mime content type and optional
"smime-type" parameter are used to convey details about the security "smime-type" parameter are used to convey details about the security
applied (signed or enveloped) along with information about the contained applied (signed or enveloped) along with information about the
content. This may aid receiving S/MIME implementations in correctly contained content. This may aid receiving S/MIME implementations in
processing the secured content. Additional values of smime-type are correctly processing the secured content. Additional values of
defined in [ESS]. In an X.400 transport environment, MIME typing is smime-type are defined in [ESS]. In an X.400 transport environment,
not available. Therefore the equivalent semantic is conveyed using the MIME typing is not available. Therefore the equivalent semantic is
Encoded Information Types (EITs). The EITs are conveyed in the conveyed using the Encoded Information Types (EITs). The EITs are
original-encoded-information-types field of the X.400 message envelope. conveyed in the original-encoded-information-types field of the X.400
This memo defines the following smime-types. message envelope. This memo defines the following smime-types.
+-----------------------------------------------------+ +-----------------------------------------------------+
| | | |
| smime-type EIT Value (OID) | | smime-type EIT Value (OID) |
| CMS protection type Inner Content | | CMS protection type Inner Content |
| | | |
+-----------------------------------------------------+ +-----------------------------------------------------+
| | | |
| enveloped-data id-eit-envelopedData | | enveloped-data id-eit-envelopedData |
| EnvelopedData Data | | EnvelopedData Data |
| | | |
| signed-data id-eit-signedData | | signed-data id-eit-signedData |
| SignedData Data | | SignedData Data |
| | | |
| certs-only id-eit-certsOnly | | certs-only id-eit-certsOnly |
| SignedData empty (zero-length content) | | SignedData empty (zero-length content) |
| | | |
| signed-receipt id-eit-signedReceipt | | signed-receipt id-eit-signedReceipt |
| SignedData Receipt | | SignedData Receipt |
| | | |
| enveloped-x400 id-eit-envelopedx400 | | enveloped-x400 id-eit-envelopedx400 |
| EnvelopedData X.400 content | | EnvelopedData X.400 content |
| | | |
| signed-x400 id-eit-signedx400 | | signed-x400 id-eit-signedx400 |
| SignedData X.400 content | | SignedData X.400 content |
| | | |
| compressed-data id-eit-compressedData | | compressed-data id-eit-compressedData |
| CompressedData RFC 3274 compression wrapper | | CompressedData RFC 3274 compression wrapper |
| | | |
+-----------------------------------------------------+ +-----------------------------------------------------+
Sending agents SHOULD include the appropriate S/MIME EIT OID value. Sending agents SHOULD include the appropriate S/MIME EIT OID value.
Receiving agents SHOULD recognize S/MIME OID values in the EITs field, Receiving agents SHOULD recognize S/MIME OID values in the EITs
and process the message appropriately according to local procedures. field, and process the message appropriately according to local
procedures.
In order that consistency can be obtained in future S/MIME EIT In order that consistency can be obtained in future S/MIME EIT
assignments, the following guidelines should be followed when assigning assignments, the following guidelines should be followed when
new EIT values. Values assigned for S/MIME EITs should correspond to assigning new EIT values. Values assigned for S/MIME EITs should
assigned smime-type values on a one-to-one basis. The restrictions of correspond to assigned smime-type values on a one-to-one basis. The
section 3.2.2 of [MSG] therefore apply. S/MIME EIT values may coexist restrictions of section 3.2.2 of [MSG] therefore apply. S/MIME EIT
with other EIT values intended to further qualify the makeup of the values may coexist with other EIT values intended to further qualify
protected content. the makeup of the protected content.
2.5.1 Enveloped Data 2.5.1. Enveloped Data
The enveloped data EIT indicates that the X.400 content field contains a The enveloped data EIT indicates that the X.400 content field
MIME type that has been protected by the CMS enveloped-data content type contains a MIME type that has been protected by the CMS enveloped-
in accordance with [MSG]. The resulting enveloped data CMS content is data content type in accordance with [MSG]. The resulting enveloped
conveyed in accordance with section 2.2. This EIT should be indicated by data CMS content is conveyed in accordance with section 2.2. This
the following OID value: EIT should be indicated by the following OID value:
id-eit-envelopedData OBJECT IDENTIFIER ::= id-eit-envelopedData OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedData(1) } pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedData(1) }
2.5.2 Signed Data 2.5.2. Signed Data
The signed data EIT indicates that the X.400 content field contains a The signed data EIT indicates that the X.400 content field contains a
MIME type that has been protected by the CMS signed-data content type in MIME type that has been protected by the CMS signed-data content type
accordance with [MSG]. The resulting signed data CMS content is conveyed in accordance with [MSG]. The resulting signed data CMS content is
in accordance with section 2.2. This EIT should be indicated by the conveyed in accordance with section 2.2. This EIT should be
following OID value: indicated by the following OID value:
id-eit-signedData OBJECT IDENTIFIER ::= id-eit-signedData OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-signedData(2) } pkcs-9(9) smime(16) id-eit(10) id-eit-signedData(2) }
2.5.3 Certs Only 2.5.3. Certs Only
The certs-only message is used to transport certificates The certs-only message is used to transport certificates and/or CRLs,
and/or CRLs, such as in response to a registration request. This is such as in response to a registration request. This is described in
described in [CERT31]. The certs-only message consists of a [CERT31]. The certs-only message consists of a single instance of
single instance of CMS content of type signed-data. The encapContentInfo CMS content of type signed-data. The encapContentInfo eContent field
eContent field MUST be absent and signerInfos field MUST be empty. The MUST be absent and signerInfos field MUST be empty. The resulting
resulting certs-only CMS content is conveyed in accordance certs-only CMS content is conveyed in accordance with section 2.2.
with section 2.2. This EIT should be indicated by the following OID This EIT should be indicated by the following OID value:
value:
id-eit-certsOnly OBJECT IDENTIFIER ::= id-eit-certsOnly OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-certsOnly(3) } pkcs-9(9) smime(16) id-eit(10) id-eit-certsOnly(3) }
2.5.4 Signed Receipt 2.5.4. Signed Receipt
The signed receipt EIT indicates that the X.400 content field contains a The signed receipt EIT indicates that the X.400 content field
Receipt content that has been protected by the CMS signed-data content contains a Receipt content that has been protected by the CMS
type in accordance with [ESS]. The resulting CMS signed-data content is signed-data content type in accordance with [ESS]. The resulting CMS
conveyed in accordance with section 2.2. This EIT should be indicated by signed-data content is conveyed in accordance with section 2.2. This
the following OID value: EIT should be indicated by the following OID value:
id-eit-signedReceipt OBJECT IDENTIFIER ::= id-eit-signedReceipt OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-signedReceipt(4) } pkcs-9(9) smime(16) id-eit(10) id-eit-signedReceipt(4) }
2.5.5 Enveloped X.400 2.5.5. Enveloped X.400
The enveloped X.400 EIT indicates that the X.400 content field contains The enveloped X.400 EIT indicates that the X.400 content field
X.400 content that has been protected by the CMS enveloped-data content contains X.400 content that has been protected by the CMS enveloped-
type in accordance with [X400WRAP]. The resulting enveloped X.400 CMS data content type in accordance with [X400WRAP]. The resulting
content is conveyed in accordance with section 2.2. This EIT should be enveloped X.400 CMS content is conveyed in accordance with section
indicated by the following OID value: 2.2. This EIT should be indicated by the following OID value:
id-eit-envelopedX400 OBJECT IDENTIFIER ::= id-eit-envelopedX400 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedX400(5) } pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedX400(5) }
2.5.6 Signed X.400 2.5.6. Signed X.400
The signed X.400 EIT indicates that the X.400 content field contains The signed X.400 EIT indicates that the X.400 content field contains
X.400 content that has been protected by the CMS signed-data content X.400 content that has been protected by the CMS signed-data content
type in accordance with [X400WRAP]. The resulting signed X.400 CMS type in accordance with [X400WRAP]. The resulting signed X.400 CMS
content is conveyed in accordance with section 2.2. This EIT should be content is conveyed in accordance with section 2.2. This EIT should
indicated by the following OID value: be indicated by the following OID value:
id-eit-signedX400 OBJECT IDENTIFIER ::= id-eit-signedX400 OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-signedX400(6) } pkcs-9(9) smime(16) id-eit(10) id-eit-signedX400(6) }
2.5.7 Compressed Data 2.5.7. Compressed Data
The compressed data EIT indicates that the X.400 content field contains The compressed data EIT indicates that the X.400 content field
a another type that has been compressed by the compressed-data content contains a another type that has been compressed by the compressed-
type in accordance with [COMPRESS]. The resulting CMS content is data content type in accordance with [COMPRESS]. The resulting CMS
conveyed in accordance with section 2.2. This EIT should be indicated by content is conveyed in accordance with section 2.2. This EIT should
the following OID value: be indicated by the following OID value:
id-eit-compressedData OBJECT IDENTIFIER ::= id-eit-compressedData OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1)
pkcs-9(9) smime(16) id-eit(10) id-eit-compressedData(7) } pkcs-9(9) smime(16) id-eit(10) id-eit-compressedData(7) }
2.6 Interaction with X.400 Elements of Service 2.6. Interaction with X.400 Elements of Service
Care should be taken in the selection of X.400 services to be used in Care should be taken in the selection of X.400 services to be used in
conjunction with CMS objects. Services affecting conversion of the conjunction with CMS objects. Services affecting conversion of the
content, expansion of Distribution Lists (DLs), and message redirection content, expansion of Distribution Lists (DLs), and message
can interact badly with services provided by the "EnvelopedData" and redirection can interact badly with services provided by the
"SignedData" CMS content types. "EnvelopedData" and "SignedData" CMS content types.
2.6.1 MTS Conversion Services 2.6.1. MTS Conversion Services
MTS conversion is not applicable to the scenario of this draft because MTS conversion is not applicable to the scenario of this document
such conversion is incompatible with CMS protection mechanisms. X.400 because such conversion is incompatible with CMS protection
systems that implement conversion services should generally be unable to mechanisms. X.400 systems that implement conversion services should
attempt conversion of CMS content types because those types do not generally be unable to attempt conversion of CMS content types
conform to X.420 structure rules. Nevertheless, when transporting CMS because those types do not conform to X.420 structure rules.
objects within an X.400 environment, the Conversion Prohibition service Nevertheless, when transporting CMS objects within an X.400
SHOULD be selected. environment, the Conversion Prohibition service SHOULD be selected.
2.6.2 Message Redirection Services 2.6.2. Message Redirection Services
X.400 message redirection services can have an indirect impact on the X.400 message redirection services can have an indirect impact on the
application of the CMS "EnvelopedData" content type. Several different application of the CMS "EnvelopedData" content type. Several
forms of redirection are possible in X.400, including: different forms of redirection are possible in X.400, including:
- Originator Requested Alternate Recipient (ORAR) - Originator Requested Alternate Recipient (ORAR)
- Alternate Recipient Assignment - Alternate Recipient Assignment
- Redirection of Incoming Messages - Redirection of Incoming Messages
In addition, any auto-forwarding services that are not security-aware In addition, any auto-forwarding services that are not security-aware
may share the same problem. An auto-forwarding implementation that may share the same problem. An auto-forwarding implementation that
removes the EnvelopedData and reapplies it for the forwarded recipient removes the EnvelopedData and reapplies it for the forwarded
is not affected by this problem. The normal case is that the private key recipient is not affected by this problem. The normal case is that
is not available when the human user is not present, thus decryption is the private key is not available when the human user is not present,
not possible. However, if the private key is present, forwarding can be thus decryption is not possible. However, if the private key is
used instead. present, forwarding can be used instead.
When the "EnvelopedData" content type is used to protect message When the "EnvelopedData" content type is used to protect message
contents, an instance of RecipientInfo is needed for each recipient and contents, an instance of RecipientInfo is needed for each recipient
alternate recipient in order to ensure the desired access to the and alternate recipient in order to ensure the desired access to the
message. A RecipientInfo for the originator is a good practice just in message. A RecipientInfo for the originator is a good practice just
case the MTS returns the whole message. in case the MTS returns the whole message.
In the event that ORAR is used, the originator is aware of the identity In the event that ORAR is used, the originator is aware of the
of the alternate recipient and SHOULD include a corresponding identity of the alternate recipient and SHOULD include a
RecipientInfo element. For other forms of redirection (including corresponding RecipientInfo element. For other forms of redirection
non-security-aware auto-forwarding) the alternate recipient must either (including non-security-aware auto-forwarding) the alternate
have access to the intended recipient's keys (not recommended) or must recipient must either have access to the intended recipient's keys
relay the message to the intended recipient by other means. (not recommended) or must relay the message to the intended recipient
by other means.
2.6.3 DL Expansion 2.6.3. DL Expansion
X.400 DLs can have an indirect impact on the application of the CMS X.400 DLs can have an indirect impact on the application of the CMS
"EnvelopedData" content type. When the "EnvelopedData" content type "EnvelopedData" content type. When the "EnvelopedData" content type
is used to protect message contents, an instance of RecipientInfo is is used to protect message contents, an instance of RecipientInfo is
needed for each recipient in order to ensure the desired access to the needed for each recipient in order to ensure the desired access to
message. Messages to a DL would typically include only a single the message. Messages to a DL would typically include only a single
RecipientInfo associated with the DL. Unlike Mail Lists (MLs) described RecipientInfo associated with the DL. Unlike Mail Lists (MLs)
in [ESS], however, X.400 DLs are not generally security-aware and do not described in [ESS], however, X.400 DLs are not generally security-
regenerate RecipientInfo elements for the DL members. It is recommended aware and do not regenerate RecipientInfo elements for the DL
that a security-aware ML conforming to [ESS] be used in preference to members. It is recommended that a security-aware ML conforming to
X.400 DLs. When transporting CMS objects within an X.400 environment, [ESS] be used in preference to X.400 DLs. When transporting CMS
the DL Expansion Prohibited service SHOULD be selected. objects within an X.400 environment, the DL Expansion Prohibited
service SHOULD be selected.
3. Security Considerations 3. Security Considerations
This specification introduces no new security concerns to the CMS or This specification introduces no new security concerns to the CMS or
S/MIME models. Security issues are identified in section 5 of [MSG], S/MIME models. Security issues are identified in section 5 of [MSG],
section 6 of [ESS] and the Security Considerations section of [CMS]. section 6 of [ESS] and the Security Considerations section of [CMS].
A. References 4. References
A.1 Normative References 4.1. Normative References
[CERT31] Ramsdell, B., Editor, "S/MIME Version 3 Certificate [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Handling", Internet-Draft draft-ietf-smime-rfc2632bis. Requirement Levels", BCP 14, RFC 2119, March 1997.
[CMS] Housley, R., "Cryptographic Message Syntax", Internet-Draft [CERT31] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
draft-ietf-smime-rfc2630bis. Extensions (S/MIME) Version 3.1 Certificate Handling",
RFC 3850, July 2004.
[COMPRESS] Gutmann, P., Editor, "Compressed Data Content Type for [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
Cryptographic Message Syntax (CMS)", RFC 3274, June 2002. 3852, July 2004.
[ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME", [COMPRESS] Gutmann, P., "Compressed Data Content Type for
RFC 2634, June 1999. Cryptographic Message Syntax (CMS)", RFC 3274, June
2002.
[MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", [ESS] Hoffman, P., Ed., "Enhanced Security Services for
Internet-Draft draft-ietf-smime-rfc2633bis. S/MIME", RFC 2634, June 1999.
[X.400] ITU-T X.400 Series of Recommendations, Information technology - [MSG] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Message Handling Systems (MHS). X.400: System and Service Overview; Extensions (S/MIME) Version 3.1 Message Specification",
X.402: Overall Architecture; X.411: Message Transfer System: Abstract RFC 3851, July 2004.
Service Definition and Procedures; X.420: Interpersonal Messaging
System; 1996.
A.2 Non-normative References [X.400] ITU-T X.400 Series of Recommendations, Information
technology - Message Handling Systems (MHS). X.400:
System and Service Overview; X.402: Overall
Architecture; X.411: Message Transfer System: Abstract
Service Definition and Procedures; X.420: Interpersonal
Messaging System; 1996.
[BODYMAP] Alvestrand, H., Editor, "Mapping between X.400 and 4.2. Informative References
RFC-822/MIME Message Bodies", RFC 2157, January 1998.
[MIXER] Kille, S., Editor, "MIXER (Mime Internet X.400 Enhanced [BODYMAP] Alvestrand, H., "Mapping between X.400 and RFC-822/MIME
Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, Message Bodies", RFC 2157, January 1998.
January 1998.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate [MIXER] Kille, S., "MIXER (Mime Internet X.400 Enhanced Relay):
Requirement Levels", RFC 2119, March 1997. Mapping between X.400 and RFC 822/MIME", RFC 2156,
January 1998.
B. Editors' Addresses [X400WRAP] Hoffman, P., Bonatti, C., and A. Eggen, "Securing X.400
Content with Secure/Multipurpose Internet Mail
Extensions (S/MIME), RFC 3854, July 2004.
Paul Hoffman 5. Authors' Addresses
Internet Mail Consortium
127 Segre Place
Santa Cruz, CA 95060 USA
phoffman@imc.org
Chris Bonatti Paul Hoffman
IECA, Inc. Internet Mail Consortium
15309 Turkey Foot Road 127 Segre Place
Darnestown, MD 20878-3640 USA Santa Cruz, CA 95060 USA
bonattic@ieca.com
draft-ietf-smime-x400transport-09.txt expires February 8, 2004. EMail: phoffman@imc.org
Chris Bonatti
IECA, Inc.
15309 Turkey Foot Road
Darnestown, MD 20878-3640 USA
EMail: bonattic@ieca.com
6. 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. 101 change blocks. 
341 lines changed or deleted 346 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/