idnits 2.17.1 draft-ietf-smime-x400transport-05.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 475 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 120: '...Implementations MUST include the CMS o...' RFC 2119 keyword, line 124: '... the P1 envelope MUST be set to the fo...' RFC 2119 keyword, line 130: '... the P1 envelope MUST be set to the fo...' RFC 2119 keyword, line 146: '...Implementations MUST include the CMS o...' RFC 2119 keyword, line 150: '... the P1 envelope MUST be set to the fo...' (17 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 (November 1, 2002) is 7819 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 427 looks like a reference -- Missing reference section? 'MIXER' on line 447 looks like a reference -- Missing reference section? 'BODYMAP' on line 444 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 451 looks like a reference -- Missing reference section? '0' on line 185 looks like a reference -- Missing reference section? '1' on line 186 looks like a reference -- Missing reference section? '2' on line 187 looks like a reference -- Missing reference section? 'MSG' on line 433 looks like a reference -- Missing reference section? 'ESS' on line 430 looks like a reference -- Missing reference section? 'CERT31' on line 424 looks like a reference -- Missing reference section? 'X400WRAP' on line 342 looks like a reference Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 13 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-05.txt Chris Bonatti, IECA 3 November 1, 2002 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 This document describes a mechanism for using CMS objects as the message 43 content of X.400 messages in a native X.400 environment. This means 44 that gateways or other functions that expect to deal with IPMS, such as 45 those specified in [MIXER] and [BODYMAP], cannot do anything with these 46 messages. Note that cooperating S/MIME agents must support common forms 47 of message content in order to achieve interoperability. 49 Definition of gateway services to support relay of CMS object between 50 X.400 and SMTP environments is beyond the scope of this document. 52 1.1 Terminology 54 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and 55 "MAY" in this document are to be interpreted as described in RFC 2119 56 [MUSTSHOULD]. 58 1.2 Definitions 60 For the purposes of this document, the following definitions apply. 62 ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824. 64 Object Identifier (OID): A globally unique identifier value consisting 65 of a sequence of integer values assigned through distributed 66 registration as specified by ISO/IEC 8824. 68 Transfer Encoding: A reversible transformation made on data so 8-bit or 69 binary data may be sent via a channel that only transmits 7-bit data. 71 1.3 Compatibility with Existing S/MIME Implementations 73 It is a goal of this draft to, if possible, maintain backward 74 compatibility with existing X.400 implementations that employ S/MIME v3 75 wrappers. 77 2. S/MIME Packaging 79 2.1 The X.400 Message Structure 81 This section reviews the X.400 message format. An X.400 message has two 82 parts, the envelope and the content, as described in X.402 [X.400]: 84 Envelope -- An information object whose composition varies from one 85 transmittal step to another and that variously identifies the message's 86 originator and potential recipients, documents its previous conveyance 87 and directs its subsequent conveyance by the Message Transfer System 88 (MTS), and characterizes its content. 90 Content -- The content is the piece of information that the originating 91 User Agent wants to be delivered to one or more recipients. The MTS 92 neither examines nor modifies the content, except for conversion, during 93 its conveyance of the message. MTS conversion is not applicable to the 94 scenario of this draft because such conversion is incompatible with CMS 95 protection mechanisms. 97 One piece of information borne by the envelope identifies the type of 98 the content. The content type is an identifier (an ASN.1 OID or Integer) 99 that denotes the syntax and semantics of the content overall. This 100 identifier enables the MTS to determine the message's deliverability to 101 particular users, and enables User Agents and Message Stores to 102 interpret and process the content. 104 Some X.400 content types further refine the structure of content as a 105 set of heading elements and body parts. An example of this is the 106 Interpersonal Messaging System (IPMS). The IPMS content structure is 107 able to convey zero or more arbitrary body parts each identified by the 108 body part type. The body part type is an ASN.1 OID or Integer that 109 denotes the syntax and semantics of the body part in question. 111 2.2 Carrying S/MIME as X.400 Content 113 When transporting a CMS-protected message in X.400, the preferred 114 approach (except as discussed in section 2.3 below) is to convey the 115 object as X.400 message content. This section describes how S/MIME CMS 116 objects are conveyed as the content part of X.400 messages. This 117 mechanism is suitable for transport of CMS-protected messages regardless 118 of the mail content that has been encapsulated. 120 Implementations MUST include the CMS object in the content field of the 121 X.400 message. 123 If the CMS object is covered by an outer MIME wrapper, the content-type 124 field of the P1 envelope MUST be set to the following CMS-defined value: 126 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 127 rsadsi(113549) pkcs(1) pkcs7(7) 1 } 129 If the CMS object is not covered by an outer MIME wrapper, the 130 content-type field of the P1 envelope MUST be set to the following 131 CMS-defined value: 133 id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) 134 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 135 content-types(1) 6} 137 2.2.1 Carrying Plaintext MIME objects as X.400 Content 139 When transporting a CMS object in X.400, the preferred approach (except 140 as discussed in section 2.3 below) is to convey the object as X.400 141 message content. This section describes how S/MIME CMS objects are 142 conveyed as the content part of X.400 messages. This mechanism is 143 suitable for transport of CMS-protected messages regardless of the mail 144 content that has been encapsulated. 146 Implementations MUST include the CMS object in the content field of the 147 X.400 message. 149 If the CMS object is covered by an outer MIME wrapper, the content-type 150 field of the P1 envelope MUST be set to the following CMS-defined value: 152 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 153 rsadsi(113549) pkcs(1) pkcs7(7) 1 } 155 If the CMS object is not covered by an outer MIME wrapper, the 156 content-type field of the P1 envelope MUST be set to the following 157 CMS-defined value: 159 id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) 160 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 161 content-types(1) 6} 163 2.3 Carrying S/MIME as IPMS Body Parts 165 Under some circumstances S/MIME CMS-protected messages can be conveyed 166 within select body parts of the content. Implementations generally 167 SHOULD NOT embed CMS objects within X.400 body parts, but should instead 168 convey them as content as described in section 2.2. Nevertheless, one 169 notable exception is necessary for the case of forwarding. 171 In instances when CMS objects are forwarded as part of a message 172 forwarding function, use of a body part is necessary. When forwarding a 173 CMS object in an IPMS or IPMS-compatible body part, implementations MUST 174 use the content-body-part as formally defined by [X.400], as shown below 175 for reference. 177 content-body-part {ExtendedContentType:content-type} 178 EXTENDED-BODY-PART-TYPE ::= { 179 PARAMETERS {ForwardedContentParameters IDENTIFIED BY 180 {id-ep-content -- concatenated with content-type -- }}, 181 DATA {Content IDENTIFIED BY 182 {id-et-content -- concatenated with content-type -- }} } 184 ForwardedContentParameters ::= SET { 185 delivery-time [0] MessageDeliveryTime OPTIONAL, 186 delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL, 187 mts-identifier [2] MessageDeliveryIdentifier OPTIONAL} 189 id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17} 191 id-et-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) et(4) 17} 193 The implementation MUST copy the CMS object to be forwarded into the 194 Content field of the content-body-part. The direct-reference field of 195 the body part MUST include the OID formed by the concatenation of the 196 id-ep-content value and the following CMS-defined value. 198 id-ct-contentInfo OBJECT IDENTIFIER ::= 199 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 200 pkcs-9(9) smime(16) content-types(1) 6} 202 For example, to forward any CMS object the DATA component of the body 203 part would be identified by { 2 6 1 4 17 1 2 840 113549 1 9 16 1 6 }. 205 The ForwardedContentParameters are optional and MAY be supported at the 206 discretion of the implementor. The OID value id-et-content MAY also be 207 included in the original-encoded-information-types field of the X.400 208 message envelope at the discretion of the sending S/MIME agent. 210 In this instance, the content-type field of the P1 envelope MUST be set 211 to the value associate with the forwarding content (e.g., integer 22 for 212 IPMS). 214 2.4 Transfer Encoding 216 According to various S/MIME specifications for message wrapping, CMS 217 objects MAY optionally be wrapped in MIME to dynamically support 7-bit 218 transport. This outer wrapping is not required for X.400 transport, and 219 generally SHOULD NOT be applied in a homogeneous X.400 environment. 220 Heterogeneous mail systems or other factors MAY require the presence of 221 this outer MIME wrapper 223 2.5 Encoded Information Type Indication 225 In [MSG], the application/pkcs7-mime content type and optional 226 "smime-type" parameter are used to convey details about the security 227 applied (signed or enveloped) along with information about the contained 228 content. This may aid receiving S/MIME implementations in correctly 229 processing the secured content. Additional values of smime-type are 230 defined in [ESS]. In an X.400 transport environment, MIME typing is 231 not available. Therefore the equivalent semantic is conveyed using the 232 Encoded Information Types (EITs). The EITs are conveyed in the 233 original-encoded-information-types field of the X.400 message envelope. 234 This memo defines the following smime-types. 236 +-----------------------------------------------------+ 237 | | 238 | smime-type EIT Value (OID) | 239 | CMS protection type Inner Content | 240 | | 241 +-----------------------------------------------------+ 242 | | 243 | enveloped-data id-eit-envelopedData | 244 | EnvelopedData Data | 245 | | 246 | signed-data id-eit-signedData | 247 | SignedData Data | 248 | | 249 | cert-management id-eit-certManagement | 250 | SignedData empty (zero-length content) | 251 | | 252 | signed-receipt id-eit-signedReceipt | 253 | SignedData Receipt | 254 | | 255 | enveloped-x400 id-eit-envelopedx400 | 256 | EnvelopedData X.400 content | 257 | | 258 | signed-x400 id-eit-signedx400 | 259 | SignedData X.400 content | 260 | | 261 +-----------------------------------------------------+ 263 Sending agents SHOULD include the appropriate S/MIME EIT OID value. 264 Receiving agents SHOULD recognize S/MIME OID values in the EITs field, 265 and process the message appropriately according to local procedures. 267 In order that consistency can be obtained in future S/MIME EIT 268 assignments, the following guidelines should be followed when assigning 269 new EIT values. Values assigned for S/MIME EITs should correspond to 270 assigned smime-type values on a one-to-one basis. The restrictions of 271 section 3.2.2 of [MSG] therefore apply. S/MIME EIT values may coexist 272 with other EIT values intended to further qualify the makeup of the 273 protected content. 275 2.5.1 Enveloped Data 277 The enveloped data EIT indicates that the X.400 content field contains a 278 MIME type that has been protected by the CMS enveloped-data content type 279 in accordance with [MSG]. The resulting enveloped data CMS content is 280 conveyed in accordance with section 2.2. This EIT should be indicated by 281 the following OID value: 283 id-eit-envelopedData 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-envelopedData(1) } 287 2.5.2 Signed Data 289 The signed data EIT indicates that the X.400 content field contains a 290 MIME type that has been protected by the CMS signed-data content type in 291 accordance with [MSG]. The resulting signed data CMS content is conveyed 292 in accordance with section 2.2. This EIT should be indicated by the 293 following OID value: 295 id-eit-signedData OBJECT IDENTIFIER ::= 296 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 297 pkcs-9(9) smime(16) id-eit(10) id-eit-signedData(2) } 299 2.5.3 Certificate Management 301 The certificate management message is used to transport certificates 302 and/or CRLs, such as in response to a registration request. This is 303 described in [CERT31]. The certificate management message consists of a 304 single instance of CMS content of type signed-data. The encapContentInfo 305 eContent field MUST be absent and signerInfos field MUST be empty. The 306 resulting certificate management CMS content is conveyed in accordance 307 with section 2.2. This EIT should be indicated by the following OID 308 value: 310 id-eit-certManagement 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-certManagement(3) } 314 2.5.4 Signed Receipt 316 The signed receipt EIT indicates that the X.400 content field contains a 317 Receipt content that has been protected by the CMS signed-data content 318 type in accordance with [ESS]. The resulting CMS signed-data content is 319 conveyed in accordance with section 2.2. This EIT should be indicated by 320 the following OID value: 322 id-eit-signedReceipt 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-signedReceipt(4) } 326 2.5.5 Enveloped X.400 328 The enveloped X.400 EIT indicates that the X.400 content field contains 329 X.400 content that has been protected by the CMS enveloped-data content 330 type in accordance with [X400WRAP]. The resulting enveloped 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-envelopedX400 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-envelopedX400(5) } 338 2.5.6 Signed X.400 340 The signed X.400 EIT indicates that the X.400 content field contains 341 X.400 content that has been protected by the CMS signed-data content 342 type in accordance with [X400WRAP]. The resulting signed X.400 CMS 343 content is conveyed in accordance with section 2.2. This EIT should be 344 indicated by the following OID value: 346 id-eit-signedX400 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-signedX400(6) } 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 type 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 RecipeintInfo 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 entire document discusses the topic of conveying security protocol 416 structures. Additional security issues are identified in section 5 of 417 [MSG], section 6 of [ESS] and the Security Considerations section of 418 [CMS]. 420 A. References 422 A.1 Normative References 424 [CERT31] Ramsdell, B., Editor, "S/MIME Version 3 Certificate 425 Handling", Internet-Draft draft-ietf-smime-rfc2632bis. 427 [CMS] Housley, R., "Cryptographic Message Syntax", Internet-Draft 428 draft-ietf-smime-rfc2630bis. 430 [ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME", 431 RFC 2634, June 1999. 433 [MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", 434 Internet-Draft draft-ietf-smime-rfc2633bis. 436 [X.400] ITU-T X.400 Series of Recommendations, Information technology - 437 Message Handling Systems (MHS). X.400: System and Service Overview; 438 X.402: Overall Architecture; X.411: Message Transfer System: Abstract 439 Service Definition and Procedures; X.420: Interpersonal Messaging 440 System; 1996. 442 A.2 Non-normative References 444 [BODYMAP] Alvestrand, H., Editor, "Mapping between X.400 and 445 RFC-822/MIME Message Bodies", RFC 2157, January 1998. 447 [MIXER] Kille, S., Editor, "MIXER (Mime Internet X.400 Enhanced 448 Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, 449 January 1998. 451 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate 452 Requirement Levels", RFC 2119, March 1997. 454 B. Editors' Addresses 456 Paul Hoffman 457 Internet Mail Consortium 458 127 Segre Place 459 Santa Cruz, CA 95060 USA 460 phoffman@imc.org 462 Chris Bonatti 463 IECA, Inc. 464 15309 Turkey Foot Road 465 Darnestown, MD 20878-3640 USA 466 bonattic@ieca.com