idnits 2.17.1 draft-ietf-smime-x400transport-06.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 500 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 147: '...Implementations MUST include the CMS o...' RFC 2119 keyword, line 151: '... 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, 2003) is 7475 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 443 looks like a reference -- Missing reference section? 'MIXER' on line 466 looks like a reference -- Missing reference section? 'BODYMAP' on line 463 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 470 looks like a reference -- Missing reference section? '0' on line 186 looks like a reference -- Missing reference section? '1' on line 187 looks like a reference -- Missing reference section? '2' on line 188 looks like a reference -- Missing reference section? 'MSG' on line 452 looks like a reference -- Missing reference section? 'ESS' on line 449 looks like a reference -- Missing reference section? 'CERT31' on line 440 looks like a reference -- Missing reference section? 'X400WRAP' on line 346 looks like a reference -- Missing reference section? 'COMPRESS' on line 446 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-06.txt Chris Bonatti, IECA 4 May 1, 2003 5 Expires November 1, 2003 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 CMS object in X.400, the preferred approach (except 141 as discussed in section 2.3 below) is to convey the object as X.400 142 message content. This section describes how S/MIME CMS objects are 143 conveyed as the content part of X.400 messages. This mechanism is 144 suitable for transport of CMS-protected messages regardless of the mail 145 content that has been encapsulated. 147 Implementations MUST include the CMS object in the content field of the 148 X.400 message. 150 If the CMS object is covered by an outer MIME wrapper, the content-type 151 field of the P1 envelope MUST be set to the following CMS-defined value: 153 id-data OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) 154 rsadsi(113549) pkcs(1) pkcs7(7) 1 } 156 If the CMS object is not covered by an outer MIME wrapper, the 157 content-type field of the P1 envelope MUST be set to the following 158 CMS-defined value: 160 id-ct-contentInfo OBJECT IDENTIFIER ::= { iso(1) member-body(2) 161 us(840) rsadsi(113549) pkcs(1) pkcs-9(9) smime(16) 162 content-types(1) 6} 164 2.3 Carrying S/MIME as IPMS Body Parts 166 Under some circumstances S/MIME CMS-protected messages can be conveyed 167 within select body parts of the content. Implementations generally 168 SHOULD NOT embed CMS objects within X.400 body parts, but should instead 169 convey them as content as described in section 2.2. Nevertheless, one 170 notable exception is necessary for the case of forwarding. 172 In instances when CMS objects are forwarded as part of a message 173 forwarding function, use of a body part is necessary. When forwarding a 174 CMS object in an IPMS or IPMS-compatible body part, implementations MUST 175 use the content-body-part as formally defined by [X.400], as shown below 176 for reference. 178 content-body-part {ExtendedContentType:content-type} 179 EXTENDED-BODY-PART-TYPE ::= { 180 PARAMETERS {ForwardedContentParameters IDENTIFIED BY 181 {id-ep-content -- concatenated with content-type -- }}, 182 DATA {Content IDENTIFIED BY 183 {id-et-content -- concatenated with content-type -- }} } 185 ForwardedContentParameters ::= SET { 186 delivery-time [0] MessageDeliveryTime OPTIONAL, 187 delivery-envelope [1] OtherMessageDeliveryFields OPTIONAL, 188 mts-identifier [2] MessageDeliveryIdentifier OPTIONAL} 190 id-ep-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) ep(11) 17} 192 id-et-content ::= {joint-iso-itu-t(2) mhs(6) ipms(1) et(4) 17} 194 The implementation MUST copy the CMS object to be forwarded into the 195 Content field of the content-body-part. The direct-reference field of 196 the body part MUST include the OID formed by the concatenation of the 197 id-ep-content value and the following CMS-defined value. 199 id-ct-contentInfo OBJECT IDENTIFIER ::= 200 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 201 pkcs-9(9) smime(16) content-types(1) 6} 203 For example, to forward any CMS object the DATA component of the body 204 part would be identified by { 2 6 1 4 17 1 2 840 113549 1 9 16 1 6 }. 206 The ForwardedContentParameters are optional and MAY be supported at the 207 discretion of the implementor. The OID value id-et-content MAY also be 208 included in the original-encoded-information-types field of the X.400 209 message envelope at the discretion of the sending S/MIME agent. 211 In this instance, the content-type field of the P1 envelope MUST be set 212 to the value associate with the forwarding content (e.g., integer 22 for 213 IPMS). 215 2.4 Transfer Encoding 217 According to various S/MIME specifications for message wrapping, CMS 218 objects MAY optionally be wrapped in MIME to dynamically support 7-bit 219 transport. This outer wrapping is not required for X.400 transport, and 220 generally SHOULD NOT be applied in a homogeneous X.400 environment. 221 Heterogeneous mail systems or other factors MAY require the presence of 222 this outer MIME wrapper 224 2.5 Encoded Information Type Indication 226 In [MSG], the application/pkcs7-mime content type and optional 227 "smime-type" parameter are used to convey details about the security 228 applied (signed or enveloped) along with information about the contained 229 content. This may aid receiving S/MIME implementations in correctly 230 processing the secured content. Additional values of smime-type are 231 defined in [ESS]. In an X.400 transport environment, MIME typing is 232 not available. Therefore the equivalent semantic is conveyed using the 233 Encoded Information Types (EITs). The EITs are conveyed in the 234 original-encoded-information-types field of the X.400 message envelope. 235 This memo defines the following smime-types. 237 +-----------------------------------------------------+ 238 | | 239 | smime-type EIT Value (OID) | 240 | CMS protection type Inner Content | 241 | | 242 +-----------------------------------------------------+ 243 | | 244 | enveloped-data id-eit-envelopedData | 245 | EnvelopedData Data | 246 | | 247 | signed-data id-eit-signedData | 248 | SignedData Data | 249 | | 250 | cert-management id-eit-certManagement | 251 | SignedData empty (zero-length content) | 252 | | 253 | signed-receipt id-eit-signedReceipt | 254 | SignedData Receipt | 255 | | 256 | enveloped-x400 id-eit-envelopedx400 | 257 | EnvelopedData X.400 content | 258 | | 259 | signed-x400 id-eit-signedx400 | 260 | SignedData X.400 content | 261 | | 262 | compressed-data id-eit-compressedData | 263 | CompressedData RFC 3274 compression wrapper | 264 | | 265 +-----------------------------------------------------+ 267 Sending agents SHOULD include the appropriate S/MIME EIT OID value. 268 Receiving agents SHOULD recognize S/MIME OID values in the EITs field, 269 and process the message appropriately according to local procedures. 271 In order that consistency can be obtained in future S/MIME EIT 272 assignments, the following guidelines should be followed when assigning 273 new EIT values. Values assigned for S/MIME EITs should correspond to 274 assigned smime-type values on a one-to-one basis. The restrictions of 275 section 3.2.2 of [MSG] therefore apply. S/MIME EIT values may coexist 276 with other EIT values intended to further qualify the makeup of the 277 protected content. 279 2.5.1 Enveloped Data 281 The enveloped data EIT indicates that the X.400 content field contains a 282 MIME type that has been protected by the CMS enveloped-data content type 283 in accordance with [MSG]. The resulting enveloped data CMS content is 284 conveyed in accordance with section 2.2. This EIT should be indicated by 285 the following OID value: 287 id-eit-envelopedData OBJECT IDENTIFIER ::= 288 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 289 pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedData(1) } 291 2.5.2 Signed Data 293 The signed data EIT indicates that the X.400 content field contains a 294 MIME type that has been protected by the CMS signed-data content type in 295 accordance with [MSG]. The resulting signed data CMS content is conveyed 296 in accordance with section 2.2. This EIT should be indicated by the 297 following OID value: 299 id-eit-signedData OBJECT IDENTIFIER ::= 300 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 301 pkcs-9(9) smime(16) id-eit(10) id-eit-signedData(2) } 303 2.5.3 Certificate Management 305 The certificate management message is used to transport certificates 306 and/or CRLs, such as in response to a registration request. This is 307 described in [CERT31]. The certificate management message consists of a 308 single instance of CMS content of type signed-data. The encapContentInfo 309 eContent field MUST be absent and signerInfos field MUST be empty. The 310 resulting certificate management CMS content is conveyed in accordance 311 with section 2.2. This EIT should be indicated by the following OID 312 value: 314 id-eit-certManagement OBJECT IDENTIFIER ::= 315 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 316 pkcs-9(9) smime(16) id-eit(10) id-eit-certManagement(3) } 318 2.5.4 Signed Receipt 320 The signed receipt EIT indicates that the X.400 content field contains a 321 Receipt content that has been protected by the CMS signed-data content 322 type in accordance with [ESS]. The resulting CMS signed-data content is 323 conveyed in accordance with section 2.2. This EIT should be indicated by 324 the following OID value: 326 id-eit-signedReceipt OBJECT IDENTIFIER ::= 327 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 328 pkcs-9(9) smime(16) id-eit(10) id-eit-signedReceipt(4) } 330 2.5.5 Enveloped X.400 332 The enveloped X.400 EIT indicates that the X.400 content field contains 333 X.400 content that has been protected by the CMS enveloped-data content 334 type in accordance with [X400WRAP]. The resulting enveloped X.400 CMS 335 content is conveyed in accordance with section 2.2. This EIT should be 336 indicated by the following OID value: 338 id-eit-envelopedX400 OBJECT IDENTIFIER ::= 339 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 340 pkcs-9(9) smime(16) id-eit(10) id-eit-envelopedX400(5) } 342 2.5.6 Signed X.400 344 The signed X.400 EIT indicates that the X.400 content field contains 345 X.400 content that has been protected by the CMS signed-data content 346 type in accordance with [X400WRAP]. The resulting signed X.400 CMS 347 content is conveyed in accordance with section 2.2. This EIT should be 348 indicated by the following OID value: 350 id-eit-signedX400 OBJECT IDENTIFIER ::= 351 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 352 pkcs-9(9) smime(16) id-eit(10) id-eit-signedX400(6) } 354 2.5.7 Compressed Data 356 The compressed data EIT indicates that the X.400 content field contains 357 a another type that has been compressed by the compressed-data content 358 type in accordance with [COMPRESS]. The resulting CMS content is 359 conveyed in accordance with section 2.2. This EIT should be indicated by 360 the following OID value: 362 id-eit-compressedData OBJECT IDENTIFIER ::= 363 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) 364 pkcs-9(9) smime(16) id-eit(10) id-eit-compressedData(7) } 366 2.6 Interaction with X.400 Elements of Service 368 Care should be taken in the selection of X.400 services to be used in 369 conjunction with CMS objects. Services affecting conversion of the 370 content, expansion of Distribution Lists (DLs), and message redirection 371 can interact badly with services provided by the "EnvelopedData" and 372 "SignedData" CMS content types. 374 2.6.1 MTS Conversion Services 376 MTS conversion is not applicable to the scenario of this draft because 377 such conversion is incompatible with CMS protection mechanisms. X.400 378 systems that implement conversion services should generally be unable to 379 attempt conversion of CMS content types because those type do not 380 conform to X.420 structure rules. Nevertheless, when transporting CMS 381 objects within an X.400 environment, the Conversion Prohibition service 382 SHOULD be selected. 384 2.6.2 Message Redirection Services 386 X.400 message redirection services can have an indirect impact on the 387 application of the CMS "EnvelopedData" content type. Several different 388 forms of redirection are possible in X.400, including: 390 - Originator Requested Alternate Recipient (ORAR) 391 - Alternate Recipient Assignment 392 - Redirection of Incoming Messages 394 In addition, any auto-forwarding services that are not security-aware 395 may share the same problem. An auto-forwarding implementation that 396 removes the EnvelopedData and reapplies it for the forwarded recipient 397 is not affected by this problem. The normal case is that the private key 398 is not available when the human user is not present, thus decryption is 399 not possible. However, if the private key is present, forwarding can be 400 used instead. 402 When the "EnvelopedData" content type is used to protect message 403 contents, an instance of RecipientInfo is needed for each recipient and 404 alternate recipient in order to ensure the desired access to the 405 message. A RecipeintInfo for the originator is a good practice just in 406 case the MTS returns the whole message. 408 In the event that ORAR is used, the originator is aware of the identity 409 of the alternate recipient and SHOULD include a corresponding 410 RecipientInfo element. For other forms of redirection (including 411 non-security-aware auto-forwarding) the alternate recipient must either 412 have access to the intended recipient's keys (not recommended) or must 413 relay the message to the intended recipient by other means. 415 2.6.3 DL Expansion 417 X.400 DLs can have an indirect impact on the application of the CMS 418 "EnvelopedData" content type. When the "EnvelopedData" content type 419 is used to protect message contents, an instance of RecipientInfo is 420 needed for each recipient in order to ensure the desired access to the 421 message. Messages to a DL would typically include only a single 422 RecipientInfo associated with the DL. Unlike Mail Lists (MLs) described 423 in [ESS], however, X.400 DLs are not generally security-aware and do not 424 regenerate RecipientInfo elements for the DL members. It is recommended 425 that a security-aware ML conforming to [ESS] be used in preference to 426 X.400 DLs. When transporting CMS objects within an X.400 environment, 427 the DL Expansion Prohibited service SHOULD be selected. 429 3. Security Considerations 431 This entire document discusses the topic of conveying security protocol 432 structures. Additional security issues are identified in section 5 of 433 [MSG], section 6 of [ESS] and the Security Considerations section of 434 [CMS]. 436 A. References 438 A.1 Normative References 440 [CERT31] Ramsdell, B., Editor, "S/MIME Version 3 Certificate 441 Handling", Internet-Draft draft-ietf-smime-rfc2632bis. 443 [CMS] Housley, R., "Cryptographic Message Syntax", Internet-Draft 444 draft-ietf-smime-rfc2630bis. 446 [COMPRESS] Gutmann, P., Editor, "Compressed Data Content Type for 447 Cryptographic Message Syntax (CMS)", RFC 3274, June 2002. 449 [ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME", 450 RFC 2634, June 1999. 452 [MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", 453 Internet-Draft draft-ietf-smime-rfc2633bis. 455 [X.400] ITU-T X.400 Series of Recommendations, Information technology - 456 Message Handling Systems (MHS). X.400: System and Service Overview; 457 X.402: Overall Architecture; X.411: Message Transfer System: Abstract 458 Service Definition and Procedures; X.420: Interpersonal Messaging 459 System; 1996. 461 A.2 Non-normative References 463 [BODYMAP] Alvestrand, H., Editor, "Mapping between X.400 and 464 RFC-822/MIME Message Bodies", RFC 2157, January 1998. 466 [MIXER] Kille, S., Editor, "MIXER (Mime Internet X.400 Enhanced 467 Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, 468 January 1998. 470 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate 471 Requirement Levels", RFC 2119, March 1997. 473 B. Editors' Addresses 475 Paul Hoffman 476 Internet Mail Consortium 477 127 Segre Place 478 Santa Cruz, CA 95060 USA 479 phoffman@imc.org 481 Chris Bonatti 482 IECA, Inc. 483 15309 Turkey Foot Road 484 Darnestown, MD 20878-3640 USA 485 bonattic@ieca.com 487 draft-ietf-smime-x400transport-06.txt expires November 1, 2003.