draft-ietf-smime-x400transport-04.txt   draft-ietf-smime-x400transport-05.txt 
Internet Draft Paul Hoffman, IMC Internet Draft Paul Hoffman, IMC
draft-ietf-smime-x400transport-04.txt Chris Bonatti, IECA draft-ietf-smime-x400transport-05.txt Chris Bonatti, IECA
October 19, 2001 November 1, 2002
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 42 skipping to change at line 42
system. 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 transported
via a variety of electronic mail systems. This specification defines via a variety of electronic mail systems. This specification defines
the options and values necessary to enable interoperable transport of the options and values necessary to enable interoperable transport of
S/MIME messages over an X.400 system. S/MIME messages over an X.400 system.
This document describes a mechanism for using CMS objects as the message
content of X.400 messages in a native X.400 environment. This means
that gateways or other functions that expect to deal with IPMS, such as
those specified in [MIXER] and [BODYMAP], cannot do anything with these
messages. Note that cooperating S/MIME agents must support common forms
of message content in order to achieve interoperability.
Definition of gateway services to support relay of CMS object between
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", and
"MAY" in this document are to be interpreted as described in RFC 2119 "MAY" in this document are to be interpreted as described in RFC 2119
[MUSTSHOULD]. [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 consisting
of a sequence of integer values assigned through distributed of a sequence of integer values assigned through distributed
registration as specified by ISO/IEC 8824. 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 or
binary data may be sent via a channel that only transmits 7-bit data. binary data may be sent via a channel that only transmits 7-bit data.
1.3 Compatibility with Existing S/MIME Implementations
It is a goal of this draft to, if possible, maintain backward
compatibility with existing X.400 implementations that employ S/MIME v3
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 two
parts, the envelope and the content, as described in X.402 [X.400]: 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 message's
originator and potential recipients, documents its previous conveyance originator and potential recipients, documents its previous conveyance
skipping to change at line 97 skipping to change at line 113
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 the
body part type. The body part type is an ASN.1 OID or Integer that body part type. The body part type is an ASN.1 OID or Integer that
denotes the syntax and semantics of the body part in question. 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
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
objects are conveyed as the content part of X.400 messages. This
mechanism is suitable for transport of CMS-protected messages regardless
of the mail content that has been encapsulated.
Implementations MUST include the CMS object in the content field of the
X.400 message.
If the CMS object is covered by an outer MIME wrapper, the content-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)
rsadsi(113549) pkcs(1) pkcs7(7) 1 }
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
CMS-defined value:
id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2)
us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16)
content-types(1) 6}
2.2.1 Carrying Plaintext MIME objects as X.400 Content
When transporting a CMS object in X.400, the preferred approach (except When transporting a CMS object in X.400, the preferred approach (except
as discussed in section 2.3 below) is to convey the object as X.400 as discussed in section 2.3 below) is to convey the object as X.400
message content. This section describes how S/MIME CMS objects are message content. This section describes how S/MIME CMS objects are
conveyed as the content part of X.400 messages. This mechanism is conveyed as the content part of X.400 messages. This mechanism is
suitable for transport of CMS-protected messages regardless of the mail suitable for transport of CMS-protected messages regardless of the mail
content that has been encapsulated. 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 the
X.400 message. X.400 message.
skipping to change at line 123 skipping to change at line 165
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 can be conveyed within Under some circumstances S/MIME CMS-protected messages can be conveyed
select body parts of the content. Implementations generally SHOULD NOT within select body parts of the content. Implementations generally
embed CMS objects within X.400 body parts because of the dependency on SHOULD NOT embed CMS objects within X.400 body parts, but should instead
the support provided by the content type. There is no guarantee that all convey them as content as described in section 2.2. Nevertheless, one
X.400 content types will necessarily include structured content, much notable exception is necessary for the case of forwarding.
less body parts. Furthermore, the structure of different X.400 body
parts may vary to the extent that it is difficult to universally specify
the conveyance of CMS objects. Nevertheless, one notable exception is
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
forwarding function, use of a body part is necessary. When forwarding a forwarding function, use of a body part is necessary. When forwarding a
CMS object in an IPMS or IPMS-compatible body part, implementations MUST CMS object in an IPMS or IPMS-compatible body part, implementations MUST
use the content-body-part as formally defined by [X.400], as shown below use the content-body-part as formally defined by [X.400], as shown below
for reference. 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
skipping to change at line 172 skipping to change at line 210
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 the
discretion of the implementor. The OID value id-et-content MAY also be 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 included in the original-encoded-information-types field of the X.400
message envelope at the discretion of the sending S/MIME agent. 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
to the value associate with the forwarding content (e.g., integer 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-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
2.5 Encoded Information Type Indication 2.5 Encoded Information Type Indication
skipping to change at line 261 skipping to change at line 303
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) id-eit(10) id-eit-signedData(2) } 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 [CERT31]. 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) id-eit(10) id-eit-certManagement(3) } pkcs-9(9) smime(16) id-eit(10) id-eit-certManagement(3) }
skipping to change at line 380 skipping to change at line 422
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
[CERT3] Ramsdell, B., Editor, "S/MIME Version 3 Certificate A.1 Normative References
Handling", RFC 2632, June 1999.
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [CERT31] Ramsdell, B., Editor, "S/MIME Version 3 Certificate
Handling", Internet-Draft draft-ietf-smime-rfc2632bis.
[MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", RFC [CMS] Housley, R., "Cryptographic Message Syntax", Internet-Draft
2633, June 1999. draft-ietf-smime-rfc2630bis.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate [ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME",
Requirement Levels", RFC 2119, March 1997. RFC 2634, June 1999.
[PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version [MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification",
1.5", RFC 2315, March 1998. Internet-Draft draft-ietf-smime-rfc2633bis.
[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.
A.2 Non-normative References
[BODYMAP] Alvestrand, H., Editor, "Mapping between X.400 and
RFC-822/MIME Message Bodies", RFC 2157, January 1998.
[MIXER] Kille, S., Editor, "MIXER (Mime Internet X.400 Enhanced
Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156,
January 1998.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997.
B. Editors' Addresses B. 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
 End of changes. 

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