idnits 2.17.1 draft-ietf-smime-x400transport-09.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 483 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 121: '...Implementations MUST include the CMS o...' RFC 2119 keyword, line 125: '... the P1 envelope MUST be set to the fo...' RFC 2119 keyword, line 131: '... the P1 envelope MUST be set to the fo...' RFC 2119 keyword, line 142: '... the P1 envelope MUST be set to the fo...' RFC 2119 keyword, line 158: '...atible body part, implementations MUST...' (15 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 (February 8, 2004) is 7383 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 426 looks like a reference -- Missing reference section? 'MIXER' on line 449 looks like a reference -- Missing reference section? 'BODYMAP' on line 446 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 453 looks like a reference -- Missing reference section? '0' on line 170 looks like a reference -- Missing reference section? '1' on line 171 looks like a reference -- Missing reference section? '2' on line 172 looks like a reference -- Missing reference section? 'MSG' on line 435 looks like a reference -- Missing reference section? 'ESS' on line 432 looks like a reference -- Missing reference section? 'CERT31' on line 423 looks like a reference -- Missing reference section? 'X400WRAP' on line 330 looks like a reference -- Missing reference section? 'COMPRESS' on line 429 looks like a reference Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 14 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 S/MIME Working Group 2 Internet Draft Paul Hoffman, IMC 3 draft-ietf-smime-x400transport-09.txt Chris Bonatti, IECA 4 August 8, 2003 5 Expires February 8, 2004 7 Transporting S/MIME Objects in X.400 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with all 12 provisions of Section 10 of RFC2026. 14 Internet-Drafts are working documents of the Internet Engineering Task 15 Force (IETF), its areas, and its working groups. Note that other groups 16 may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference material 21 or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 This document describes protocol options for conveying CMS-protected 32 objects associated with S/MIME version 3 over an X.400 message transfer 33 system. 35 1. Introduction 37 The techniques described in the Cryptographic Message Syntax [CMS] 38 specification and message specifications can reasonably be transported 39 via a variety of electronic mail systems. This specification defines 40 the options and values necessary to enable interoperable transport of 41 S/MIME messages over an X.400 system. 43 This document describes a mechanism for using CMS objects as the message 44 content of X.400 messages in a native X.400 environment. This means 45 that gateways or other functions that expect to deal with IPMS, such as 46 those specified in [MIXER] and [BODYMAP], cannot do anything with these 47 messages. Note that cooperating S/MIME agents must support common forms 48 of message content in order to achieve interoperability. 50 Definition of gateway services to support relay of CMS object between 51 X.400 and SMTP environments is beyond the scope of this document. 53 1.1 Terminology 55 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and 56 "MAY" in this document are to be interpreted as described in RFC 2119 57 [MUSTSHOULD]. 59 1.2 Definitions 61 For the purposes of this document, the following definitions apply. 63 ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824. 65 Object Identifier (OID): A globally unique identifier value consisting 66 of a sequence of integer values assigned through distributed 67 registration as specified by ISO/IEC 8824. 69 Transfer Encoding: A reversible transformation made on data so 8-bit or 70 binary data may be sent via a channel that only transmits 7-bit data. 72 1.3 Compatibility with Existing S/MIME Implementations 74 It is a goal of this draft to, if possible, maintain backward 75 compatibility with existing X.400 implementations that employ S/MIME v3 76 wrappers. 78 2. S/MIME Packaging 80 2.1 The X.400 Message Structure 82 This section reviews the X.400 message format. An X.400 message has two 83 parts, the envelope and the content, as described in X.402 [X.400]: 85 Envelope -- An information object whose composition varies from one 86 transmittal step to another and that variously identifies the message's 87 originator and potential recipients, documents its previous conveyance 88 and directs its subsequent conveyance by the Message Transfer System 89 (MTS), and characterizes its content. 91 Content -- The content is the piece of information that the originating 92 User Agent wants to be delivered to one or more recipients. The MTS 93 neither examines nor modifies the content, except for conversion, during 94 its conveyance of the message. MTS conversion is not applicable to the 95 scenario of this draft because such conversion is incompatible with CMS 96 protection mechanisms. 98 One piece of information borne by the envelope identifies the type of 99 the content. The content type is an identifier (an ASN.1 OID or Integer) 100 that denotes the syntax and semantics of the content overall. This 101 identifier enables the MTS to determine the message's deliverability to 102 particular users, and enables User Agents and Message Stores to 103 interpret and process the content. 105 Some X.400 content types further refine the structure of content as a 106 set of heading elements and body parts. An example of this is the 107 Interpersonal Messaging System (IPMS). The IPMS content structure is 108 able to convey zero or more arbitrary body parts each identified by the 109 body part type. The body part type is an ASN.1 OID or Integer that 110 denotes the syntax and semantics of the body part in question. 112 2.2 Carrying S/MIME as X.400 Content 114 When transporting a CMS-protected message in X.400, the preferred 115 approach (except as discussed in section 2.3 below) is to convey the 116 object as X.400 message content. This section describes how S/MIME CMS 117 objects are conveyed as the content part of X.400 messages. This 118 mechanism is suitable for transport of CMS-protected messages regardless 119 of the mail content that has been encapsulated. 121 Implementations MUST include the CMS object in the content field of the 122 X.400 message. 124 If the CMS object is covered by an outer MIME wrapper, the content-type 125 field of the P1 envelope MUST be set to the following CMS-defined value: 127 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 128 rsadsi(113549) pkcs(1) pkcs7(7) 1 } 130 If the CMS object is not covered by an outer MIME wrapper, the 131 content-type field of the P1 envelope MUST be set to the following 132 CMS-defined value: 134 id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) 135 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 136 content-types(1) 6} 138 2.2.1 Carrying Plaintext MIME objects as X.400 Content 140 When transporting a plaintext MIME object in X.400, the preferred 141 approach is to convey the object as X.400 message content. The content- 142 type field of the P1 envelope MUST be set to the following CMS-defined 143 value: 145 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 146 rsadsi(113549) pkcs(1) pkcs7(7) 1 } 148 2.3 Carrying S/MIME as IPMS Body Parts 150 Under some circumstances S/MIME CMS-protected messages can be conveyed 151 within select body parts of the content. Implementations generally 152 SHOULD NOT embed CMS objects within X.400 body parts, but should instead 153 convey them as content as described in section 2.2. Nevertheless, one 154 notable exception is necessary for the case of forwarding. 156 In instances when CMS objects are forwarded as part of a message 157 forwarding function, use of a body part is necessary. When forwarding a 158 CMS object in an IPMS or IPMS-compatible body part, implementations MUST 159 use the content-body-part as formally defined by [X.400], as shown below 160 for reference. 162 content-body-part {ExtendedContentType:content-type} 163 EXTENDED-BODY-PART-TYPE ::= { 164 PARAMETERS {ForwardedContentParameters IDENTIFIED BY 165 {id-ep-content -- concatenated with content-type -- }}, 166 DATA {Content IDENTIFIED BY 167 {id-et-content -- concatenated with content-type -- }} } 169 ForwardedContentParameters ::= SET { 170 delivery-time [0] MessageDeliveryTime OPTIONAL, 171 delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL, 172 mts-identifier [2] MessageDeliveryIdentifier OPTIONAL} 174 id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17} 176 id-et-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) et(4) 17} 178 The implementation MUST copy the CMS object to be forwarded into the 179 Content field of the content-body-part. The direct-reference field of 180 the body part MUST include the OID formed by the concatenation of the 181 id-et-content value and the following CMS-defined value. 183 id-ct-contentInfo OBJECT IDENTIFIER ::= 184 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 185 pkcs-9(9) smime(16) content-types(1) 6} 187 For example, to forward any CMS object the DATA component of the body 188 part would be identified by { 2 6 1 4 17 1 2 840 113549 1 9 16 1 6 }. 190 The ForwardedContentParameters are optional and MAY be supported at the 191 discretion of the implementor. The OID value id-et-content MAY also be 192 included in the original-encoded-information-types field of the X.400 193 message envelope at the discretion of the sending S/MIME agent. 195 In this instance, the content-type field of the P1 envelope MUST be set 196 to the value associate with the forwarding content (e.g., integer 22 for 197 IPMS). 199 2.4 Transfer Encoding 201 According to various S/MIME specifications for message wrapping, CMS 202 objects MAY optionally be wrapped in MIME to dynamically support 7-bit 203 transport. This outer wrapping is not required for X.400 transport, and 204 generally SHOULD NOT be applied in a homogeneous X.400 environment. 205 Heterogeneous mail systems or other factors MAY require the presence of 206 this outer MIME wrapper 208 2.5 Encoded Information Type Indication 210 In [MSG], the application/pkcs7-mime content type and optional 211 "smime-type" parameter are used to convey details about the security 212 applied (signed or enveloped) along with information about the contained 213 content. This may aid receiving S/MIME implementations in correctly 214 processing the secured content. Additional values of smime-type are 215 defined in [ESS]. In an X.400 transport environment, MIME typing is 216 not available. Therefore the equivalent semantic is conveyed using the 217 Encoded Information Types (EITs). The EITs are conveyed in the 218 original-encoded-information-types field of the X.400 message envelope. 219 This memo defines the following smime-types. 221 +-----------------------------------------------------+ 222 | | 223 | smime-type EIT Value (OID) | 224 | CMS protection type Inner Content | 225 | | 226 +-----------------------------------------------------+ 227 | | 228 | enveloped-data id-eit-envelopedData | 229 | EnvelopedData Data | 230 | | 231 | signed-data id-eit-signedData | 232 | SignedData Data | 233 | | 234 | certs-only id-eit-certsOnly | 235 | SignedData empty (zero-length content) | 236 | | 237 | signed-receipt id-eit-signedReceipt | 238 | SignedData Receipt | 239 | | 240 | enveloped-x400 id-eit-envelopedx400 | 241 | EnvelopedData X.400 content | 242 | | 243 | signed-x400 id-eit-signedx400 | 244 | SignedData X.400 content | 245 | | 246 | compressed-data id-eit-compressedData | 247 | CompressedData RFC 3274 compression wrapper | 248 | | 249 +-----------------------------------------------------+ 251 Sending agents SHOULD include the appropriate S/MIME EIT OID value. 252 Receiving agents SHOULD recognize S/MIME OID values in the EITs field, 253 and process the message appropriately according to local procedures. 255 In order that consistency can be obtained in future S/MIME EIT 256 assignments, the following guidelines should be followed when assigning 257 new EIT values. Values assigned for S/MIME EITs should correspond to 258 assigned smime-type values on a one-to-one basis. The restrictions of 259 section 3.2.2 of [MSG] therefore apply. S/MIME EIT values may coexist 260 with other EIT values intended to further qualify the makeup of the 261 protected content. 263 2.5.1 Enveloped Data 265 The enveloped data EIT indicates that the X.400 content field contains a 266 MIME type that has been protected by the CMS enveloped-data content type 267 in accordance with [MSG]. The resulting enveloped data CMS content is 268 conveyed in accordance with section 2.2. This EIT should be indicated by 269 the following OID value: 271 id-eit-envelopedData OBJECT IDENTIFIER ::= 272 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 273 pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedData(1) } 275 2.5.2 Signed Data 277 The signed data EIT indicates that the X.400 content field contains a 278 MIME type that has been protected by the CMS signed-data content type in 279 accordance with [MSG]. The resulting signed data CMS content is conveyed 280 in accordance with section 2.2. This EIT should be indicated by the 281 following OID value: 283 id-eit-signedData OBJECT IDENTIFIER ::= 284 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 285 pkcs-9(9) smime(16) id-eit(10) id-eit-signedData(2) } 287 2.5.3 Certs Only 289 The certs-only message is used to transport certificates 290 and/or CRLs, such as in response to a registration request. This is 291 described in [CERT31]. The certs-only message consists of a 292 single instance of CMS content of type signed-data. The encapContentInfo 293 eContent field MUST be absent and signerInfos field MUST be empty. The 294 resulting certs-only CMS content is conveyed in accordance 295 with section 2.2. This EIT should be indicated by the following OID 296 value: 298 id-eit-certsOnly OBJECT IDENTIFIER ::= 299 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 300 pkcs-9(9) smime(16) id-eit(10) id-eit-certsOnly(3) } 302 2.5.4 Signed Receipt 304 The signed receipt EIT indicates that the X.400 content field contains a 305 Receipt content that has been protected by the CMS signed-data content 306 type in accordance with [ESS]. The resulting CMS signed-data content is 307 conveyed in accordance with section 2.2. This EIT should be indicated by 308 the following OID value: 310 id-eit-signedReceipt OBJECT IDENTIFIER ::= 311 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 312 pkcs-9(9) smime(16) id-eit(10) id-eit-signedReceipt(4) } 314 2.5.5 Enveloped X.400 316 The enveloped X.400 EIT indicates that the X.400 content field contains 317 X.400 content that has been protected by the CMS enveloped-data content 318 type in accordance with [X400WRAP]. The resulting enveloped X.400 CMS 319 content is conveyed in accordance with section 2.2. This EIT should be 320 indicated by the following OID value: 322 id-eit-envelopedX400 OBJECT IDENTIFIER ::= 323 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 324 pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedX400(5) } 326 2.5.6 Signed X.400 328 The signed X.400 EIT indicates that the X.400 content field contains 329 X.400 content that has been protected by the CMS signed-data content 330 type in accordance with [X400WRAP]. The resulting signed X.400 CMS 331 content is conveyed in accordance with section 2.2. This EIT should be 332 indicated by the following OID value: 334 id-eit-signedX400 OBJECT IDENTIFIER ::= 335 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 336 pkcs-9(9) smime(16) id-eit(10) id-eit-signedX400(6) } 338 2.5.7 Compressed Data 340 The compressed data EIT indicates that the X.400 content field contains 341 a another type that has been compressed by the compressed-data content 342 type in accordance with [COMPRESS]. The resulting CMS content is 343 conveyed in accordance with section 2.2. This EIT should be indicated by 344 the following OID value: 346 id-eit-compressedData OBJECT IDENTIFIER ::= 347 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 348 pkcs-9(9) smime(16) id-eit(10) id-eit-compressedData(7) } 350 2.6 Interaction with X.400 Elements of Service 352 Care should be taken in the selection of X.400 services to be used in 353 conjunction with CMS objects. Services affecting conversion of the 354 content, expansion of Distribution Lists (DLs), and message redirection 355 can interact badly with services provided by the "EnvelopedData" and 356 "SignedData" CMS content types. 358 2.6.1 MTS Conversion Services 360 MTS conversion is not applicable to the scenario of this draft because 361 such conversion is incompatible with CMS protection mechanisms. X.400 362 systems that implement conversion services should generally be unable to 363 attempt conversion of CMS content types because those types do not 364 conform to X.420 structure rules. Nevertheless, when transporting CMS 365 objects within an X.400 environment, the Conversion Prohibition service 366 SHOULD be selected. 368 2.6.2 Message Redirection Services 370 X.400 message redirection services can have an indirect impact on the 371 application of the CMS "EnvelopedData" content type. Several different 372 forms of redirection are possible in X.400, including: 374 - Originator Requested Alternate Recipient (ORAR) 375 - Alternate Recipient Assignment 376 - Redirection of Incoming Messages 378 In addition, any auto-forwarding services that are not security-aware 379 may share the same problem. An auto-forwarding implementation that 380 removes the EnvelopedData and reapplies it for the forwarded recipient 381 is not affected by this problem. The normal case is that the private key 382 is not available when the human user is not present, thus decryption is 383 not possible. However, if the private key is present, forwarding can be 384 used instead. 386 When the "EnvelopedData" content type is used to protect message 387 contents, an instance of RecipientInfo is needed for each recipient and 388 alternate recipient in order to ensure the desired access to the 389 message. A RecipientInfo for the originator is a good practice just in 390 case the MTS returns the whole message. 392 In the event that ORAR is used, the originator is aware of the identity 393 of the alternate recipient and SHOULD include a corresponding 394 RecipientInfo element. For other forms of redirection (including 395 non-security-aware auto-forwarding) the alternate recipient must either 396 have access to the intended recipient's keys (not recommended) or must 397 relay the message to the intended recipient by other means. 399 2.6.3 DL Expansion 401 X.400 DLs can have an indirect impact on the application of the CMS 402 "EnvelopedData" content type. When the "EnvelopedData" content type 403 is used to protect message contents, an instance of RecipientInfo is 404 needed for each recipient in order to ensure the desired access to the 405 message. Messages to a DL would typically include only a single 406 RecipientInfo associated with the DL. Unlike Mail Lists (MLs) described 407 in [ESS], however, X.400 DLs are not generally security-aware and do not 408 regenerate RecipientInfo elements for the DL members. It is recommended 409 that a security-aware ML conforming to [ESS] be used in preference to 410 X.400 DLs. When transporting CMS objects within an X.400 environment, 411 the DL Expansion Prohibited service SHOULD be selected. 413 3. Security Considerations 415 This specification introduces no new security concerns to the CMS or 416 S/MIME models. Security issues are identified in section 5 of [MSG], 417 section 6 of [ESS] and the Security Considerations section of [CMS]. 419 A. References 421 A.1 Normative References 423 [CERT31] Ramsdell, B., Editor, "S/MIME Version 3 Certificate 424 Handling", Internet-Draft draft-ietf-smime-rfc2632bis. 426 [CMS] Housley, R., "Cryptographic Message Syntax", Internet-Draft 427 draft-ietf-smime-rfc2630bis. 429 [COMPRESS] Gutmann, P., Editor, "Compressed Data Content Type for 430 Cryptographic Message Syntax (CMS)", RFC 3274, June 2002. 432 [ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME", 433 RFC 2634, June 1999. 435 [MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", 436 Internet-Draft draft-ietf-smime-rfc2633bis. 438 [X.400] ITU-T X.400 Series of Recommendations, Information technology - 439 Message Handling Systems (MHS). X.400: System and Service Overview; 440 X.402: Overall Architecture; X.411: Message Transfer System: Abstract 441 Service Definition and Procedures; X.420: Interpersonal Messaging 442 System; 1996. 444 A.2 Non-normative References 446 [BODYMAP] Alvestrand, H., Editor, "Mapping between X.400 and 447 RFC-822/MIME Message Bodies", RFC 2157, January 1998. 449 [MIXER] Kille, S., Editor, "MIXER (Mime Internet X.400 Enhanced 450 Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, 451 January 1998. 453 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate 454 Requirement Levels", RFC 2119, March 1997. 456 B. Editors' Addresses 458 Paul Hoffman 459 Internet Mail Consortium 460 127 Segre Place 461 Santa Cruz, CA 95060 USA 462 phoffman@imc.org 464 Chris Bonatti 465 IECA, Inc. 466 15309 Turkey Foot Road 467 Darnestown, MD 20878-3640 USA 468 bonattic@ieca.com 470 draft-ietf-smime-x400transport-09.txt expires February 8, 2004.