draft-ietf-smime-x400transport-02.txt   draft-ietf-smime-x400transport-03.txt 
Internet Draft Paul Hoffman, IMC Internet Draft Paul Hoffman, IMC
draft-ietf-smime-x400transport-02.txt Chris Bonatti, IECA draft-ietf-smime-x400transport-03.txt Chris Bonatti, IECA
May 2, 2000 July 19, 2001
Expires in six months Expires in six months
Transporting S/MIME Objects in X.400 Transporting S/MIME Objects in X.400
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
skipping to change at line 77 skipping to change at line 77
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 message's
originator and potential recipients, documents its previous conveyance originator and potential recipients, documents its previous conveyance
and directs its subsequent conveyance by the Message Transfer System and directs its subsequent conveyance by the Message Transfer System
(MTS), and characterizes its content. (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 originating
User Agent wants to be delivered to one or more recipients. The MTS User Agent wants to be delivered to one or more recipients. The MTS
neither examines nor modifies the content, except for conversion, during neither examines nor modifies the content, except for conversion, during
its conveyance of the message. its conveyance of the message. MTS conversion is not applicable to the
scenario of this draft 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 Integer)
that denotes the syntax and semantics of the content overall. This that denotes the syntax and semantics of the content overall. This
identifier enables the MTS to determine the message's deliverability to identifier enables the MTS to determine the message's deliverability to
particular users, and enables User Agents and Message Stores to particular users, and enables User Agents and Message Stores to
interpret and process the content. 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
skipping to change at line 121 skipping to change at line 123
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.3 Carrying S/MIME as IPMS Body Parts 2.3 Carrying S/MIME as IPMS Body Parts
Under some circumstances S/MIME CMS objects MAY be conveyed within Under some circumstances S/MIME CMS objects can be conveyed within
select body parts of the content. Implementations generally SHOULD NOT select body parts of the content. Implementations generally SHOULD NOT
embed CMS objects within X.400 body parts because of the dependency on embed CMS objects within X.400 body parts because of the dependency on
the support provided by the content type. There is no guarantee that all the support provided by the content type. There is no guarantee that all
X.400 content types will necessarily include structured content, much X.400 content types will necessarily include structured content, much
less body parts. Furthermore, the structure of different X.400 body less body parts. Furthermore, the structure of different X.400 body
parts may vary to the extent that it is difficult to universally specify parts may vary to the extent that it is difficult to universally specify
the conveyance of CMS objects. Nevertheless, one notable exception is the conveyance of CMS objects. Nevertheless, one notable exception is
necessary. necessary.
In instances when CMS objects are forwarded as part of a message In instances when CMS objects are forwarded as part of a message
skipping to change at line 151 skipping to change at line 153
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}
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 of
the body part MUST include the OID formed by the concatenation of the the body part MUST include the OID formed by the concatenation of the
id-ep-content value and the following CMS-defined value. id-ep-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
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 the
discretion of the implementor. discretion of the implementor. The OID value id-et-content MAY also be
included in the original-encoded-information-types field of the X.400
message envelope at the discretion of the sending S/MIME agent.
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-bit
transport. This outer wrapping is not required for X.400 transport, and transport. This outer wrapping is not required for X.400 transport, and
generally SHOULD NOT be applied in a homogeneous X.400 environment. generally SHOULD NOT be applied in a homogeneous X.400 environment.
Heterogeneous mail systems or other factors MAY require the presence of Heterogeneous mail systems or other factors MAY require the presence of
this outer MIME wrapper this outer MIME wrapper
skipping to change at line 185 skipping to change at line 194
"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 contained
content. This may aid receiving S/MIME implementations in correctly content. This may aid receiving S/MIME implementations in correctly
processing the secured content. Additional values of smime-type are processing the secured content. Additional values of smime-type are
defined in [ESS] and [X400WRAP]. In an X.400 transport environment, MIME defined in [ESS] and [X400WRAP]. In an X.400 transport environment, MIME
typing is not available. Therefore the equivalent semantic is conveyed typing is not available. Therefore the equivalent semantic is conveyed
using the Encoded Information Types (EITs). The EITs are conveyed in using the Encoded Information Types (EITs). The EITs are conveyed in
the original-encoded-information-types field of the X.400 message the original-encoded-information-types field of the X.400 message
envelope. This memo defines the following smime-types. envelope. This memo defines the following smime-types.
smime-type EIT Value (OID) +-----------------------------------------------------+
CMS protection type Inner Content | |
| smime-type EIT Value (OID) |
enveloped-data id-eit-envelopedData | CMS protection type Inner Content |
EnvelopedData Data | |
+-----------------------------------------------------+
signed-data id-eit-signedData | |
SignedData Data | enveloped-data id-eit-envelopedData |
| EnvelopedData Data |
cert-management id-eit-certManagement | |
SignedData empty (zero-length content) | signed-data id-eit-signedData |
| SignedData Data |
signed-receipt id-eit-signedReceipt | |
SignedData Receipt | cert-management id-eit-certManagement |
| SignedData empty (zero-length content) |
enveloped-x400 id-eit-envelopedx400 | |
EnvelopedData X.400 content | signed-receipt id-eit-signedReceipt |
| SignedData Receipt |
signed-x400 id-eit-signedx400 | |
SignedData X.400 content | enveloped-x400 id-eit-envelopedx400 |
| EnvelopedData X.400 content |
| |
| signed-x400 id-eit-signedx400 |
| SignedData X.400 content |
| |
+-----------------------------------------------------+
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 field,
and process the message appropriately according to local procedures. 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 assigning
a new values of EIT. Values assigned for S/MIME EITs should correspond new EIT values. Values assigned for S/MIME EITs should correspond to
to assigned smime-type values on a one to one basis. The restrictions of assigned smime-type values on a one-to-one basis. The restrictions of
section 3.2.2 of [MSG] therefore apply. S/MIME EIT values may coexist section 3.2.2 of [MSG] therefore apply. S/MIME EIT values may coexist
with other EIT values intended to further qualify the makeup of the with other EIT values intended to further qualify the makeup of the
protected content. 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 contains a
MIME type that has been protected by the CMS Enveloped-data content type MIME type that has been protected by the CMS enveloped-data content type
in accordance with [MSG]. The resulting enveloped data CMS content is in accordance with [MSG]. The resulting enveloped data CMS content is
conveyed in accordance with section 2.2. This EIT should be indicated by conveyed in accordance with section 2.2. This EIT should be indicated by
the following OID value: 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) eits(***) envelopedData(0) } 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 in
accordance with [MSG]. The resulting signed data CMS content is conveyed accordance with [MSG]. The resulting signed data CMS content is conveyed
in accordance with section 2.2. This EIT should be indicated by the in accordance with section 2.2. This EIT should be indicated by the
following OID value: 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) eits(***) signedData(1) } pkcs-9(9) smime(16) id-eit(10) id-eit-signedData(2) }
2.5.3 Certificate Management 2.5.3 Certificate Management
The certificate management message is used to transport certificates The certificate management message is used to transport certificates
and/or CRLs, such as in response to a registration request. This is and/or CRLs, such as in response to a registration request. This is
described in [CERT3]. The certificate management message consists of a described in [CERT3]. The certificate management message consists of a
single instance of CMS content of type Signed-data. The encapContentInfo single instance of CMS content of type signed-data. The encapContentInfo
eContent field MUST be absent and signerInfos field MUST be empty. The eContent field MUST be absent and signerInfos field MUST be empty. The
resulting certificate management CMS content is conveyed in accordance resulting certificate management CMS content is conveyed in accordance
with section 2.2. This EIT should be indicated by the following OID with section 2.2. This EIT should be indicated by the following OID
value: value:
id-eit-certManagement OBJECT IDENTIFIER ::= id-eit-certManagement 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) eits(***) certManagement(2) } pkcs-9(9) smime(16) id-eit(10) id-eit-certManagement(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 contains a
Receipt content that has been protected by the CMS Signed-data content Receipt content that has been protected by the CMS signed-data content
type in accordance with [ESS]. The resulting signed data CMS content is type in accordance with [ESS]. The resulting CMS signed-data content is
conveyed in accordance with section 2.2. This EIT should be indicated by conveyed in accordance with section 2.2. This EIT should be indicated by
the following OID value: 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) eits(***) signedReceipt(3) } 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 contains
X.400 content that has been protected by the CMS Enveloped-data content X.400 content that has been protected by the CMS enveloped-data content
type in accordance with [X400WRAP]. The resulting enveloped X.400 CMS type in accordance with [X400WRAP]. The resulting enveloped 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 be
indicated by the following OID value: 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) eits(***) envelopedX400(4) } 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 be
indicated by the following OID value: 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) eits(***) signedX400(5) } pkcs-9(9) smime(16) id-eit(10) id-eit-signedX400(6) }
2.6 Interaction with X.400 Elements of Service
Care should be taken in the selection of X.400 services to be used in
conjunction with CMS objects. Services affecting conversion of the
content, expansion of Distribution Lists (DLs), and message redirection
can interact badly with services provided by the "EnvelopedData" and
"SignedData" CMS content types.
2.6.1 MTS Conversion Services
MTS conversion is not applicable to the scenario of this draft because
such conversion is incompatible with CMS protection mechanisms. X.400
systems that implement conversion services should generally be unable to
attempt conversion of CMS content types because those type do not
conform to X.420 structure rules. Nevertheless, when transporting CMS
objects within an X.400 environment, the Conversion Prohibition service
SHOULD be selected.
2.6.2 Message Redirection Services
X.400 message redirection services can have an indirect impact on the
application of the CMS "EnvelopedData" content type. Several different
forms of redirection are possible in X.400, including:
- Originator Requested Alternate Recipient (ORAR)
- Alternate Recipient Assignment
- Redirection of Incoming Messages
In addition, any auto-forwarding services that are not security-aware
may share the same problem. An auto-forwarding implementation that
removes the EnvelopedData and reapplies it for the forwarded recipient
is not affected by this problem. The normal case is that the private key
is not available when the human user is not present, thus decryption is
not possible. However, if the private key is present, forwarding can be
used instead.
When the "EnvelopedData" content type is used to protect message
contents, an instance of RecipientInfo is needed for each recipient and
alternate recipient in order to ensure the desired access to the
message. A RecipeintInfo for the originator is a good practice just in
case the MTS returns the whole message.
In the event that ORAR is used, the originator is aware of the identity
of the alternate recipient and SHOULD include a corresponding
RecipientInfo element. For other forms of redirection (including
non-security-aware auto-forwarding) the alternate recipient must either
have access to the intended recipient's keys (not recommended) or must
relay the message to the intended recipient by other means.
2.6.3 DL Expansion
X.400 DLs can have an indirect impact on the application of the CMS
"EnvelopedData" content type. When the "EnvelopedData" content type
is used to protect message contents, an instance of RecipientInfo is
needed for each recipient in order to ensure the desired access to the
message. Messages to a DL would typically include only a single
RecipientInfo associated with the DL. Unlike Mail Lists (MLs) described
in [ESS], however, X.400 DLs are not generally security-aware and do not
regenerate RecipientInfo elements for the DL members. It is recommended
that a security-aware ML conforming to [ESS] be used in preference to
X.400 DLs. When transporting CMS objects within an X.400 environment,
the DL Expansion Prohibited service SHOULD be selected.
3. Security Considerations 3. Security Considerations
This entire document discusses the topic of conveying security protocol This entire document discusses the topic of conveying security protocol
structures. Additional security issues are identified in section 5 of structures. Additional security issues are identified in section 5 of
[MSG], section 6 of [ESS] and the Security Considerations section of [MSG], section 6 of [ESS] and the Security Considerations section of
[CMS]. [CMS].
A. References A. References
skipping to change at line 322 skipping to change at line 400
[PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version
1.5", RFC 2315, March 1998. 1.5", RFC 2315, March 1998.
[X.400] ITU-T X.400 Series of Recommendations, Information technology - [X.400] ITU-T X.400 Series of Recommendations, Information technology -
Message Handling Systems (MHS). X.400: System and Service Overview; Message Handling Systems (MHS). X.400: System and Service Overview;
X.402: Overall Architecture; X.411: Message Transfer System: Abstract X.402: Overall Architecture; X.411: Message Transfer System: Abstract
Service Definition and Procedures; X.420: Interpersonal Messaging Service Definition and Procedures; X.420: Interpersonal Messaging
System; 1996. System; 1996.
B. Differences between version -01 and -02 B. Editors' Addresses
Added section 2.5 and its sub-sections.
Added [CERT3] to Appendix A.
C. Editors' Addresses
Paul Hoffman Paul Hoffman
Internet Mail Consortium Internet Mail Consortium
127 Segre Place 127 Segre Place
Santa Cruz, CA 95060 USA Santa Cruz, CA 95060 USA
phoffman@imc.org phoffman@imc.org
Chris Bonatti Chris Bonatti
IECA, Inc. IECA, Inc.
15309 Turkey Foot Road
Darnestown, MD 20878-3640 USA
bonattic@ieca.com bonattic@ieca.com
 End of changes. 

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