idnits 2.17.1 draft-ietf-smime-x400transport-03.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == 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 419 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 104: '...Implementations MUST include the CMS o...' RFC 2119 keyword, line 108: '... the P1 envelope MUST be set to the fo...' RFC 2119 keyword, line 114: '... the P1 envelope MUST be set to the fo...' RFC 2119 keyword, line 124: '.... Implementations generally SHOULD NOT...' RFC 2119 keyword, line 135: '...atible body part, implementations MUST...' (14 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 (July 19, 2001) is 8288 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 383 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 388 looks like a reference -- Missing reference section? '0' on line 147 looks like a reference -- Missing reference section? '1' on line 148 looks like a reference -- Missing reference section? '2' on line 149 looks like a reference -- Missing reference section? 'MSG' on line 385 looks like a reference -- Missing reference section? 'ESS' on line 375 looks like a reference -- Missing reference section? 'X400WRAP' on line 300 looks like a reference -- Missing reference section? 'CERT3' on line 380 looks like a reference -- Missing reference section? 'PKCS-7' on line 391 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 12 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-03.txt Chris Bonatti, IECA 3 July 19, 2001 4 Expires in six months 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. MTS conversion is not applicable to the 78 scenario of this draft because such conversion is incompatible with CMS 79 protection mechanisms. 81 One piece of information borne by the envelope identifies the type of 82 the content. The content type is an identifier (an ASN.1 OID or Integer) 83 that denotes the syntax and semantics of the content overall. This 84 identifier enables the MTS to determine the message's deliverability to 85 particular users, and enables User Agents and Message Stores to 86 interpret and process the content. 88 Some X.400 content types further refine the structure of content as a 89 set of heading elements and body parts. An example of this is the 90 Interpersonal Messaging System (IPMS). The IPMS content structure is 91 able to convey zero or more arbitrary body parts each identified by the 92 body part type. The body part type is an ASN.1 OID or Integer that 93 denotes the syntax and semantics of the body part in question. 95 2.2 Carrying S/MIME as X.400 Content 97 When transporting a CMS object in X.400, the preferred approach (except 98 as discussed in section 2.3 below) is to convey the object as X.400 99 message content. This section describes how S/MIME CMS objects are 100 conveyed as the content part of X.400 messages. This mechanism is 101 suitable for transport of CMS-protected messages regardless of the mail 102 content that has been encapsulated. 104 Implementations MUST include the CMS object in the content field of the 105 X.400 message. 107 If the CMS object is covered by an outer MIME wrapper, the content-type 108 field of the P1 envelope MUST be set to the following CMS-defined value: 110 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 111 rsadsi(113549) pkcs(1) pkcs7(7) 1 } 113 If the CMS object is not covered by an outer MIME wrapper, the 114 content-type field of the P1 envelope MUST be set to the following 115 CMS-defined value: 117 id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) 118 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 119 content-types(1) 6} 121 2.3 Carrying S/MIME as IPMS Body Parts 123 Under some circumstances S/MIME CMS objects can be conveyed within 124 select body parts of the content. Implementations generally SHOULD NOT 125 embed CMS objects within X.400 body parts because of the dependency on 126 the support provided by the content type. There is no guarantee that all 127 X.400 content types will necessarily include structured content, much 128 less body parts. Furthermore, the structure of different X.400 body 129 parts may vary to the extent that it is difficult to universally specify 130 the conveyance of CMS objects. Nevertheless, one notable exception is 131 necessary. 133 In instances when CMS objects are forwarded as part of a message 134 forwarding function, use of a body part is necessary. When forwarding a 135 CMS object in an IPMS or IPMS-compatible body part, implementations MUST 136 use the content-body-part as formally defined by [X.400], as shown below 137 for reference. 139 content-body-part {ExtendedContentType:content-type} 140 EXTENDED-BODY-PART-TYPE ::= { 141 PARAMETERS {ForwardedContentParameters IDENTIFIED BY 142 {id-ep-content -- concatenated with content-type -- }}, 143 DATA {Content IDENTIFIED BY 144 {id-et-content -- concatenated with content-type -- }} } 146 ForwardedContentParameters ::= SET { 147 delivery-time [0] MessageDeliveryTime OPTIONAL, 148 delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL, 149 mts-identifier [2] MessageDeliveryIdentifier OPTIONAL} 151 id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17} 153 id-et-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) et(4) 17} 155 The implementation MUST copy the CMS object to be forwarded into the 156 Content field of the content-body-part. The direct-reference field of 157 the body part MUST include the OID formed by the concatenation of the 158 id-ep-content value and the following CMS-defined value. 160 id-ct-contentInfo OBJECT IDENTIFIER ::= 161 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 162 pkcs-9(9) smime(16) content-types(1) 6} 164 For example, to forward any CMS object the DATA component of the body 165 part would be identified by { 2 6 1 4 17 1 2 840 113549 1 9 16 1 6 }. 167 The ForwardedContentParameters are optional and MAY be supported at the 168 discretion of the implementor. The OID value id-et-content MAY also be 169 included in the original-encoded-information-types field of the X.400 170 message envelope at the discretion of the sending S/MIME agent. 172 2.4 Transfer Encoding 174 According to various S/MIME specifications for message wrapping, CMS 175 objects MAY optionally be wrapped in MIME to dynamically support 7-bit 176 transport. This outer wrapping is not required for X.400 transport, and 177 generally SHOULD NOT be applied in a homogeneous X.400 environment. 178 Heterogeneous mail systems or other factors MAY require the presence of 179 this outer MIME wrapper 181 2.5 Encoded Information Type Indication 183 In [MSG], the application/pkcs7-mime content type and optional 184 "smime-type" parameter are used to convey details about the security 185 applied (signed or enveloped) along with information about the contained 186 content. This may aid receiving S/MIME implementations in correctly 187 processing the secured content. Additional values of smime-type are 188 defined in [ESS] and [X400WRAP]. In an X.400 transport environment, MIME 189 typing is not available. Therefore the equivalent semantic is conveyed 190 using the Encoded Information Types (EITs). The EITs are conveyed in 191 the original-encoded-information-types field of the X.400 message 192 envelope. This memo defines the following smime-types. 194 +-----------------------------------------------------+ 195 | | 196 | smime-type EIT Value (OID) | 197 | CMS protection type Inner Content | 198 | | 199 +-----------------------------------------------------+ 200 | | 201 | enveloped-data id-eit-envelopedData | 202 | EnvelopedData Data | 203 | | 204 | signed-data id-eit-signedData | 205 | SignedData Data | 206 | | 207 | cert-management id-eit-certManagement | 208 | SignedData empty (zero-length content) | 209 | | 210 | signed-receipt id-eit-signedReceipt | 211 | SignedData Receipt | 212 | | 213 | enveloped-x400 id-eit-envelopedx400 | 214 | EnvelopedData X.400 content | 215 | | 216 | signed-x400 id-eit-signedx400 | 217 | SignedData X.400 content | 218 | | 219 +-----------------------------------------------------+ 221 Sending agents SHOULD include the appropriate S/MIME EIT OID value. 222 Receiving agents SHOULD recognize S/MIME OID values in the EITs field, 223 and process the message appropriately according to local procedures. 225 In order that consistency can be obtained in future S/MIME EIT 226 assignments, the following guidelines should be followed when assigning 227 new EIT values. Values assigned for S/MIME EITs should correspond to 228 assigned smime-type values on a one-to-one basis. The restrictions of 229 section 3.2.2 of [MSG] therefore apply. S/MIME EIT values may coexist 230 with other EIT values intended to further qualify the makeup of the 231 protected content. 233 2.5.1 Enveloped Data 235 The enveloped data EIT indicates that the X.400 content field contains a 236 MIME type that has been protected by the CMS enveloped-data content type 237 in accordance with [MSG]. The resulting enveloped data CMS content is 238 conveyed in accordance with section 2.2. This EIT should be indicated by 239 the following OID value: 241 id-eit-envelopedData OBJECT IDENTIFIER ::= 242 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 243 pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedData(1) } 245 2.5.2 Signed Data 247 The signed data EIT indicates that the X.400 content field contains a 248 MIME type that has been protected by the CMS signed-data content type in 249 accordance with [MSG]. The resulting signed data CMS content is conveyed 250 in accordance with section 2.2. This EIT should be indicated by the 251 following OID value: 253 id-eit-signedData OBJECT IDENTIFIER ::= 254 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 255 pkcs-9(9) smime(16) id-eit(10) id-eit-signedData(2) } 257 2.5.3 Certificate Management 259 The certificate management message is used to transport certificates 260 and/or CRLs, such as in response to a registration request. This is 261 described in [CERT3]. The certificate management message consists of a 262 single instance of CMS content of type signed-data. The encapContentInfo 263 eContent field MUST be absent and signerInfos field MUST be empty. The 264 resulting certificate management CMS content is conveyed in accordance 265 with section 2.2. This EIT should be indicated by the following OID 266 value: 268 id-eit-certManagement OBJECT IDENTIFIER ::= 269 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 270 pkcs-9(9) smime(16) id-eit(10) id-eit-certManagement(3) } 272 2.5.4 Signed Receipt 274 The signed receipt EIT indicates that the X.400 content field contains a 275 Receipt content that has been protected by the CMS signed-data content 276 type in accordance with [ESS]. The resulting CMS signed-data content is 277 conveyed in accordance with section 2.2. This EIT should be indicated by 278 the following OID value: 280 id-eit-signedReceipt OBJECT IDENTIFIER ::= 281 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 282 pkcs-9(9) smime(16) id-eit(10) id-eit-signedReceipt(4) } 284 2.5.5 Enveloped X.400 286 The enveloped X.400 EIT indicates that the X.400 content field contains 287 X.400 content that has been protected by the CMS enveloped-data content 288 type in accordance with [X400WRAP]. The resulting enveloped X.400 CMS 289 content is conveyed in accordance with section 2.2. This EIT should be 290 indicated by the following OID value: 292 id-eit-envelopedX400 OBJECT IDENTIFIER ::= 293 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 294 pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedX400(5) } 296 2.5.6 Signed X.400 298 The signed X.400 EIT indicates that the X.400 content field contains 299 X.400 content that has been protected by the CMS signed-data content 300 type in accordance with [X400WRAP]. The resulting signed X.400 CMS 301 content is conveyed in accordance with section 2.2. This EIT should be 302 indicated by the following OID value: 304 id-eit-signedX400 OBJECT IDENTIFIER ::= 305 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 306 pkcs-9(9) smime(16) id-eit(10) id-eit-signedX400(6) } 308 2.6 Interaction with X.400 Elements of Service 310 Care should be taken in the selection of X.400 services to be used in 311 conjunction with CMS objects. Services affecting conversion of the 312 content, expansion of Distribution Lists (DLs), and message redirection 313 can interact badly with services provided by the "EnvelopedData" and 314 "SignedData" CMS content types. 316 2.6.1 MTS Conversion Services 318 MTS conversion is not applicable to the scenario of this draft because 319 such conversion is incompatible with CMS protection mechanisms. X.400 320 systems that implement conversion services should generally be unable to 321 attempt conversion of CMS content types because those type do not 322 conform to X.420 structure rules. Nevertheless, when transporting CMS 323 objects within an X.400 environment, the Conversion Prohibition service 324 SHOULD be selected. 326 2.6.2 Message Redirection Services 328 X.400 message redirection services can have an indirect impact on the 329 application of the CMS "EnvelopedData" content type. Several different 330 forms of redirection are possible in X.400, including: 332 - Originator Requested Alternate Recipient (ORAR) 333 - Alternate Recipient Assignment 334 - Redirection of Incoming Messages 336 In addition, any auto-forwarding services that are not security-aware 337 may share the same problem. An auto-forwarding implementation that 338 removes the EnvelopedData and reapplies it for the forwarded recipient 339 is not affected by this problem. The normal case is that the private key 340 is not available when the human user is not present, thus decryption is 341 not possible. However, if the private key is present, forwarding can be 342 used instead. 344 When the "EnvelopedData" content type is used to protect message 345 contents, an instance of RecipientInfo is needed for each recipient and 346 alternate recipient in order to ensure the desired access to the 347 message. A RecipeintInfo for the originator is a good practice just in 348 case the MTS returns the whole message. 350 In the event that ORAR is used, the originator is aware of the identity 351 of the alternate recipient and SHOULD include a corresponding 352 RecipientInfo element. For other forms of redirection (including 353 non-security-aware auto-forwarding) the alternate recipient must either 354 have access to the intended recipient's keys (not recommended) or must 355 relay the message to the intended recipient by other means. 357 2.6.3 DL Expansion 359 X.400 DLs can have an indirect impact on the application of the CMS 360 "EnvelopedData" content type. When the "EnvelopedData" content type 361 is used to protect message contents, an instance of RecipientInfo is 362 needed for each recipient in order to ensure the desired access to the 363 message. Messages to a DL would typically include only a single 364 RecipientInfo associated with the DL. Unlike Mail Lists (MLs) described 365 in [ESS], however, X.400 DLs are not generally security-aware and do not 366 regenerate RecipientInfo elements for the DL members. It is recommended 367 that a security-aware ML conforming to [ESS] be used in preference to 368 X.400 DLs. When transporting CMS objects within an X.400 environment, 369 the DL Expansion Prohibited service SHOULD be selected. 371 3. Security Considerations 373 This entire document discusses the topic of conveying security protocol 374 structures. Additional security issues are identified in section 5 of 375 [MSG], section 6 of [ESS] and the Security Considerations section of 376 [CMS]. 378 A. References 380 [CERT3] Ramsdell, B., Editor, "S/MIME Version 3 Certificate 381 Handling", RFC 2632, June 1999. 383 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 1999. 385 [MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", RFC 386 2633, June 1999. 388 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate 389 Requirement Levels", RFC 2119, March 1997. 391 [PKCS-7] Kaliski, B., "PKCS #7: Cryptographic Message Syntax Version 392 1.5", RFC 2315, March 1998. 394 [X.400] ITU-T X.400 Series of Recommendations, Information technology - 395 Message Handling Systems (MHS). X.400: System and Service Overview; 396 X.402: Overall Architecture; X.411: Message Transfer System: Abstract 397 Service Definition and Procedures; X.420: Interpersonal Messaging 398 System; 1996. 400 B. Editors' Addresses 402 Paul Hoffman 403 Internet Mail Consortium 404 127 Segre Place 405 Santa Cruz, CA 95060 USA 406 phoffman@imc.org 408 Chris Bonatti 409 IECA, Inc. 410 15309 Turkey Foot Road 411 Darnestown, MD 20878-3640 USA 412 bonattic@ieca.com