Internet Draft Paul Hoffman, IMC draft-ietf-smime-x400transport-01.txt Chris Bonatti, IECA November 22, 2000 Expires May 22, 2001 Transporting S/MIME Objects in X.400 Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task 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 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 http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. Abstract This document describes protocol options for conveying CMS-protected objects associated with S/MIME version 3 over an X.400 message transfer system. 1. Introduction The techniques described in the Cryptographic Message Syntax [CMS] specification and message specifications can reasonably be transported via a variety of electronic mail systems. This specification defines the options and values necessary to enable interoperable transport of S/MIME messages over an X.400 system. 1.1 Terminology The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" in this document are to be interpreted as described in RFC 2119 [MUSTSHOULD]. 1.2 Definitions For the purposes of this document, the following definitions apply. ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824. Object Identifier (OID): A globally unique identifier value consisting of a sequence of integer values assigned through distributed registration as specified by ISO/IEC 8824. 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. 2. S/MIME Packaging 2.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]: Envelope -- An information object whose composition varies from one 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. Content -- The content is the piece of information that the originating User Agent wants to be delivered to one or more recipients. The MTS neither examines nor modifies the content, except for conversion, during its conveyance of the message. 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) that denotes the syntax and semantics of the content overall. This identifier enables the MTS to determine the message's deliverability to particular users, and enables User Agents and Message Stores to interpret and process the content. 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 Interpersonal Messaging System (IPMS). The IPMS content structure is 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 denotes the syntax and semantics of the body part in question. 2.2 Carrying S/MIME as X.400 Content 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 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.3 Carrying S/MIME as IPMS Body Parts Under some circumstances S/MIME CMS objects MAY be conveyed within select body parts of the content. Implementations generally SHOULD NOT 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 X.400 content types will necessarily include structured content, much 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 forwarding function, use of a body part is necessary. When forwarding a 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 for reference. content-body-part {ExtendedContentType:content-type} EXTENDED-BODY-PART-TYPE ::= { PARAMETERS {ForwardedContentParameters IDENTIFIED BY {id-ep-content -- concatenated with content-type -- }}, DATA {Content IDENTIFIED BY {id-et-content -- concatenated with content-type -- }} } ForwardedContentParameters ::= SET { delivery-time [0] MessageDeliveryTime OPTIONAL, delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL, mts-identifier [2] MessageDeliveryIdentifier OPTIONAL} 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 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 id-ep-content value and 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} The ForwardedContentParameters are optional and MAY be supported at the discretion of the implementor. 2.4 Transfer Encoding According to various S/MIME specifications for message wrapping, CMS objects MAY optionally be wrapped in MIME to dynamically support 7-bit transport. This outer wrapping is not required for X.400 transport, and generally SHOULD NOT be applied in a homogeneous X.400 environment. Heterogeneous mail systems or other factors MAY require the presence of this outer MIME wrapper 3. Security Considerations This entire document discusses the topic of conveying security protocol structures. Additional security issues are identified in section 5 of [MSG], section 6 of [ESS] and the Security Considerations section of [CMS]. A. References [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. [MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", RFC 2633, June 1999. [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997. [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 1.5", RFC 2315, March 1998. [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. B. Differences between version -00 and -01 Many small corrections from Bill Ottaway. C. Editors' Addresses Paul Hoffman Internet Mail Consortium 127 Segre Place Santa Cruz, CA 95060 USA phoffman@imc.org Chris Bonatti IECA, Inc. bonattic@ieca.com