draft-ietf-smime-x400transport-00.txt   draft-ietf-smime-x400transport-01.txt 
Internet Draft Paul Hoffman, IMC Internet Draft Paul Hoffman, IMC
draft-ietf-smime-x400transport-00.txt Chris Bonatti, IECA draft-ietf-smime-x400transport-01.txt Chris Bonatti, IECA
November 2, 2000 November 22, 2000
Expires in six months Expires May 22, 2001
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
Force (IETF), its areas, and its working groups. Note that other groups Force (IETF), its areas, and its working groups. Note that other groups
skipping to change at line 36 skipping to change at line 36
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document describes protocol options for conveying CMS-protected This document describes protocol options for conveying CMS-protected
objects associated with S/MIME version 3 over an X.400 message transfer objects associated with S/MIME version 3 over an X.400 message transfer
system. system.
1. Introduction 1. Introduction
The techniques described in 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.
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].
skipping to change at line 75 skipping to change at line 75
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
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 which is delivered to one or more recipients. The MTS neither User Agent wants to be delivered to one or more recipients. The MTS
examines nor modifies the content, except for conversion, during its neither examines nor modifies the content, except for conversion, during
conveyance of the message. its conveyance of the message.
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 149 skipping to change at line 149
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 mhs(6) ipms(1) ep(11) 17} id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 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}
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.
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 factor may dictate the presence MAY Heterogeneous mail systems or other factors MAY require the presence of
require the presence of this outer MIME wrapper. this outer MIME wrapper
3. Security 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
[CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999.
skipping to change at line 198 skipping to change at line 198
[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. Editors' Addresses B. Differences between version -00 and -01
Many small corrections from Bill Ottaway.
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.
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/