idnits 2.17.1 draft-ietf-smime-x400transport-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 220 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 102: '...Implementations MUST include the CMS o...' RFC 2119 keyword, line 106: '... the P1 envelope MUST be set to the fo...' RFC 2119 keyword, line 112: '... the P1 envelope MUST be set to the fo...' RFC 2119 keyword, line 121: '...MIME CMS objects MAY be conveyed withi...' RFC 2119 keyword, line 122: '.... Implementations generally SHOULD NOT...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 22, 2001) is 8365 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'CMS' on line 181 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 186 looks like a reference -- Missing reference section? '0' on line 145 looks like a reference -- Missing reference section? '1' on line 146 looks like a reference -- Missing reference section? '2' on line 147 looks like a reference -- Missing reference section? 'MSG' on line 183 looks like a reference -- Missing reference section? 'ESS' on line 176 looks like a reference -- Missing reference section? 'PKCS-7' on line 189 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Paul Hoffman, IMC 2 draft-ietf-smime-x400transport-01.txt Chris Bonatti, IECA 3 November 22, 2000 4 Expires May 22, 2001 6 Transporting S/MIME Objects in X.400 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with all 11 provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering Task 14 Force (IETF), its areas, and its working groups. Note that other groups 15 may also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference material 20 or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 This document describes protocol options for conveying CMS-protected 31 objects associated with S/MIME version 3 over an X.400 message transfer 32 system. 34 1. Introduction 36 The techniques described in the Cryptographic Message Syntax [CMS] 37 specification and message specifications can reasonably be transported 38 via a variety of electronic mail systems. This specification defines 39 the options and values necessary to enable interoperable transport of 40 S/MIME messages over an X.400 system. 42 1.1 Terminology 44 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and 45 "MAY" in this document are to be interpreted as described in RFC 2119 46 [MUSTSHOULD]. 48 1.2 Definitions 50 For the purposes of this document, the following definitions apply. 52 ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824. 54 Object Identifier (OID): A globally unique identifier value consisting 55 of a sequence of integer values assigned through distributed 56 registration as specified by ISO/IEC 8824. 58 Transfer Encoding: A reversible transformation made on data so 8-bit or 59 binary data may be sent via a channel that only transmits 7-bit data. 61 2. S/MIME Packaging 63 2.1 The X.400 Message Structure 65 This section reviews the X.400 message format. An X.400 message has two 66 parts, the envelope and the content, as described in X.402 [X.400]: 68 Envelope -- An information object whose composition varies from one 69 transmittal step to another and that variously identifies the message's 70 originator and potential recipients, documents its previous conveyance 71 and directs its subsequent conveyance by the Message Transfer System 72 (MTS), and characterizes its content. 74 Content -- The content is the piece of information that the originating 75 User Agent wants to be delivered to one or more recipients. The MTS 76 neither examines nor modifies the content, except for conversion, during 77 its conveyance of the message. 79 One piece of information borne by the envelope identifies the type of 80 the content. The content type is an identifier (an ASN.1 OID or Integer) 81 that denotes the syntax and semantics of the content overall. This 82 identifier enables the MTS to determine the message's deliverability to 83 particular users, and enables User Agents and Message Stores to 84 interpret and process the content. 86 Some X.400 content types further refine the structure of content as a 87 set of heading elements and body parts. An example of this is the 88 Interpersonal Messaging System (IPMS). The IPMS content structure is 89 able to convey zero or more arbitrary body parts each identified by the 90 body part type. The body part type is an ASN.1 OID or Integer that 91 denotes the syntax and semantics of the body part in question. 93 2.2 Carrying S/MIME as X.400 Content 95 When transporting a CMS object in X.400, the preferred approach (except 96 as discussed in section 2.3 below) is to convey the object as X.400 97 message content. This section describes how S/MIME CMS objects are 98 conveyed as the content part of X.400 messages. This mechanism is 99 suitable for transport of CMS-protected messages regardless of the mail 100 content that has been encapsulated. 102 Implementations MUST include the CMS object in the content field of the 103 X.400 message. 105 If the CMS object is covered by an outer MIME wrapper, the content-type 106 field of the P1 envelope MUST be set to the following CMS-defined value: 108 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 109 rsadsi(113549) pkcs(1) pkcs7(7) 1 } 111 If the CMS object is not covered by an outer MIME wrapper, the 112 content-type field of the P1 envelope MUST be set to the following 113 CMS-defined value: 115 id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) 116 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 117 content-types(1) 6} 119 2.3 Carrying S/MIME as IPMS Body Parts 121 Under some circumstances S/MIME CMS objects MAY be conveyed within 122 select body parts of the content. Implementations generally SHOULD NOT 123 embed CMS objects within X.400 body parts because of the dependency on 124 the support provided by the content type. There is no guarantee that all 125 X.400 content types will necessarily include structured content, much 126 less body parts. Furthermore, the structure of different X.400 body 127 parts may vary to the extent that it is difficult to universally specify 128 the conveyance of CMS objects. Nevertheless, one notable exception is 129 necessary. 131 In instances when CMS objects are forwarded as part of a message 132 forwarding function, use of a body part is necessary. When forwarding a 133 CMS object in an IPMS or IPMS-compatible body part, implementations MUST 134 use the content-body-part as formally defined by [X.400], as shown below 135 for reference. 137 content-body-part {ExtendedContentType:content-type} 138 EXTENDED-BODY-PART-TYPE ::= { 139 PARAMETERS {ForwardedContentParameters IDENTIFIED BY 140 {id-ep-content -- concatenated with content-type -- }}, 141 DATA {Content IDENTIFIED BY 142 {id-et-content -- concatenated with content-type -- }} } 144 ForwardedContentParameters ::= SET { 145 delivery-time [0] MessageDeliveryTime OPTIONAL, 146 delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL, 147 mts-identifier [2] MessageDeliveryIdentifier OPTIONAL} 149 id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17} 151 The implementation MUST copy the CMS object to be forwarded into the 152 Content field of the content-body-part. The direct-reference field of 153 the body part MUST include the OID formed by the concatenation of the 154 id-ep-content value and the following CMS-defined value. 156 id-ct-contentInfo OBJECT IDENTIFIER ::= 157 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 158 pkcs-9(9) smime(16) content-types(1) 6} 160 The ForwardedContentParameters are optional and MAY be supported at the 161 discretion of the implementor. 163 2.4 Transfer Encoding 165 According to various S/MIME specifications for message wrapping, CMS 166 objects MAY optionally be wrapped in MIME to dynamically support 7-bit 167 transport. This outer wrapping is not required for X.400 transport, and 168 generally SHOULD NOT be applied in a homogeneous X.400 environment. 169 Heterogeneous mail systems or other factors MAY require the presence of 170 this outer MIME wrapper 172 3. Security Considerations 174 This entire document discusses the topic of conveying security protocol 175 structures. Additional security issues are identified in section 5 of 176 [MSG], section 6 of [ESS] and the Security Considerations section of 177 [CMS]. 179 A. References 181 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. 183 [MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", RFC 184 2633, June 1999. 186 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate 187 Requirement Levels", RFC 2119, March 1997. 189 [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 190 1.5", RFC 2315, March 1998. 192 [X.400] ITU-T X.400 Series of Recommendations, Information technology - 193 Message Handling Systems (MHS). X.400: System and Service Overview; 194 X.402: Overall Architecture; X.411: Message Transfer System: Abstract 195 Service Definition and Procedures; X.420: Interpersonal Messaging 196 System; 1996. 198 B. Differences between version -00 and -01 200 Many small corrections from Bill Ottaway. 202 C. Editors' Addresses 204 Paul Hoffman 205 Internet Mail Consortium 206 127 Segre Place 207 Santa Cruz, CA 95060 USA 208 phoffman@imc.org 210 Chris Bonatti 211 IECA, Inc. 212 bonattic@ieca.com