idnits 2.17.1 draft-ietf-smime-x400wrap-00.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 516 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.) ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. ** 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 128: '...Sending and receiving agents MUST support SHA-1 [SHA1]....' RFC 2119 keyword, line 132: '...Sending and receiving agents MUST support id-dsa defined in [DSS]. The...' RFC 2119 keyword, line 133: '...rithm parameters MUST be absent (not e...' RFC 2119 keyword, line 135: '...Receiving agents MAY support rsaEncryption, defined in [PKCS-1]....' RFC 2119 keyword, line 137: '...Sending agents MAY support rsaEncrypti...' (40 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.) -- Couldn't find a document date in the document -- date freshness check skipped. 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 459 looks like a reference -- Missing reference section? 'MSG' on line 470 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 473 looks like a reference -- Missing reference section? 'SHA1' on line 479 looks like a reference -- Missing reference section? 'DSS' on line 465 looks like a reference -- Missing reference section? 'PKCS-1' on line 476 looks like a reference -- Missing reference section? 'DH' on line 462 looks like a reference -- Missing reference section? 'ESS' on line 467 looks like a reference -- Missing reference section? 'CERT3' on line 456 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 11 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-x400wrap-00.txt Chris Bonatti, IECA 3 November 2, 2000 Anders Eggen, FFI 4 Expires in six months 6 Securing X.400 Content with S/MIME 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 a protocol for adding cryptographic signature 31 and encryption services to X.400 content. 33 1. Introduction 35 The techniques described in Cryptographic Message Syntax [CMS] 36 specification are general enough to support many different content 37 types. The [CMS] specification thus provides many options for providing 38 different security mechanisms. In order to ensure interoperability of 39 systems within the X.400 community, it is necessary to specify the use 40 of CMS features to protect X.400 content (called "CMS-X.400" in this 41 document). 43 1.1 Specification Overview 45 This document is intended to be similar to the S/MIME Version 3 Message 46 Specification [MSG] except that it is tailored to the requirements of 47 X.400 content rather than Multipurpose Internet Mail Extensions (MIME). 49 This document defines how to create an X.400 content type that has been 50 cryptographically enhanced according to [CMS]. In order to create S/MIME 51 messages, an S/MIME agent has to follow specifications in this document, 52 as well as the specifications listed in [CMS]. This memo also defines 53 new parameter values for the application/pkcs7-mime MIME type that can 54 be used to transport those body parts. 56 Throughout this document, there are requirements and recommendations 57 made for how receiving agents handle incoming messages. There are 58 separate requirements and recommendations for how sending agents create 59 outgoing messages. In general, the best strategy is to "be liberal in 60 what you receive and conservative in what you send". Most of the 61 requirements are placed on the handling of incoming messages while the 62 recommendations are mostly on the creation of outgoing messages. 64 This document does not address transport of CMS-X.400 content. It is 65 assumed that CMS-X.400 content would be transported by Internet mail 66 systems, X.400, or other suitable transport. 68 1.2 Terminology 70 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and 71 "MAY" in this document are to be interpreted as described in RFC 2119 72 [MUSTSHOULD]. 74 1.3 Definitions 76 For the purposes of this document, the following definitions apply. 78 ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824. 80 BER: Basic Encoding Rules for ASN.1, as defined in ISO/IEC 8825-1. 82 Certificate: A type that binds an entity's distinguished name to a 83 public key with a digital signature. 85 DER: Distinguished Encoding Rules for ASN.1, as defined in ISO/IEC 86 8825-x. 88 7-bit data: Text data with lines less than 998 characters long, where 89 none of the characters have the 8th bit set, and there are no NULL 90 characters. and occur only as part of a end of line 91 delimiter. 93 8-bit data: Text data with lines less than 998 characters, and where 94 none of the characters are NULL characters. and occur only as 95 part of a end of line delimiter. 97 Binary data: Arbitrary data. 99 Transfer Encoding: A reversible transformation made on data so 8-bit or 100 binary data may be sent via a channel that only transmits 7-bit data. 102 Receiving agent: software that interprets and processes S/MIME CMS 103 objects 105 Sending agent: software that creates S/MIME CMS objects. 107 S/MIME agent: user software that is a receiving agent, a sending agent, 108 or both. 110 1.4 Compatibility with Prior Practice of S/MIME 112 There are believed to be no existing X.400 implementations that support 113 S/MIME version 2. Further, signed interoperability between X.400 and 114 MIME systems that support S/MIME version 2 is not believed to be easily 115 achievable. Therefore backward compatibility with S/MIME version 2 is 116 not considered to be a requirement for this document. 118 2. CMS Options 120 CMS allows for a wide variety of options in content and algorithm 121 support. This section puts forth a number of support requirements and 122 recommendations in order to achieve a base level of interoperability 123 among all CMS-X.400 implementations. [CMS] provides additional details 124 regarding the use of the cryptographic algorithms. 126 2.1 DigestAlgorithmIdentifier 128 Sending and receiving agents MUST support SHA-1 [SHA1]. 130 2.2 SignatureAlgorithmIdentifier 132 Sending and receiving agents MUST support id-dsa defined in [DSS]. The 133 algorithm parameters MUST be absent (not encoded as NULL). 135 Receiving agents MAY support rsaEncryption, defined in [PKCS-1]. 137 Sending agents MAY support rsaEncryption. Outgoing messages are signed 138 with a user's private key. The size of the private key is determined 139 during key generation. 141 2.3 KeyEncryptionAlgorithmIdentifier 143 Sending and receiving agents MUST support Diffie-Hellman defined in 144 [DH]. 146 Receiving agents MAY support rsaEncryption. Incoming encrypted messages 147 contain symmetric keys which are to be decrypted with a user's private 148 key. The size of the private key is determined during key generation. 150 Sending agents MAY support rsaEncryption. 152 2.4 General Syntax 154 The general syntax of CMS objects consist of an instance of ContentInfo 155 structure containing one of several defined CMS content types. CMS 156 defines multiple content types. Of these, only the SignedData and 157 EnvelopedData content types are used for CMS-X.400. 159 2.4.1 SignedData Content Type 161 Sending agents MUST use the signedData content type to apply a digital 162 signature to a message or, in a degenerate case where there is no 163 signature information, to convey certificates. 165 2.4.2 EnvelopedData Content Type 167 This content type is used to apply privacy protection to a message. A 168 sender needs to have access to a public key for each intended message 169 recipient to use this service. This content type does not provide 170 authentication. 172 2.5 Attribute SignerInfo Type 174 The SignerInfo type allows the inclusion of unsigned and signed 175 attributes to be included along with a signature. 177 Receiving agents MUST be able to handle zero or one instance of each of 178 the signed attributes listed here. Sending agents SHOULD generate one 179 instance of each of the following signed attributes in each CMS/X400 180 message: 181 - signingTime 182 - sMIMECapabilities 183 - sMIMEEncryptionKeyPreference 185 Requirements for processing of these attributes MUST be in accordance 186 with the S/MIME Message Specification [MSG]. Handling of the signingTime 187 attribute MUST comply with clause 2.5.1 of [MSG]. Handling of the 188 sMIMECapabilities attribute MUST comply with clause 2.5.2 of [MSG]. 189 Handling of the sMIMEEncryptionKeyPreference attribute MUST comply with 190 clause 2.5.3 of [MSG]. 192 Further, receiving agents SHOULD be able to handle zero or one instance 193 in the signed attributes of the signingCertificate attribute. 195 Sending agents SHOULD generate one instance of the signingCertificate 196 signed attribute in each CMS/X400 message. 198 Additional attributes and values for these attributes may be defined in 199 the future. Receiving agents SHOULD handle attributes or values that it 200 does not recognize in a graceful manner. 202 Sending agents that include signed attributes that are not listed here 203 SHOULD display those attributes to the user, so that the user is aware 204 of all of the data being signed. 206 3. Creating S/MIME Messages 208 This section describes the S/MIME message formats and how they can be 209 used to secure X.400 contents. The S/MIME messages are then a 210 combination of X.400 contents and CMS objects (i.e., a ContentInfo 211 structure containing one of the CMS-defined content types). The X.400 212 content and other data, such as certificates and algorithm identifiers, 213 are given to CMS processing facilities which produces a CMS object. This 214 document also describes how nested, secured S/MIME messages should be 215 formatted when encapsulating an X.400 content, and provides an example 216 of how a triple-wrapped S/MIME message over X.400 content should be 217 created if backwards compatibility with S/MIME version 2 is of no 218 concern. 220 S/MIME provides one format for enveloped-only data, several formats for 221 signed-only data, and several formats for signed and enveloped data. 222 Several formats are required to accommodate several environments, in 223 particular for signed messages. Only one of these signed formats is 224 applicable to X.400. 226 Note that canonicalization is not required for X.400 content, and a 227 "detached signature" form is not possible. These dramatically simplify 228 the description of S/MIME productions. 230 The reader of this section is expected to understand X.400 as described 231 in [X.400] and S/MIME as described in [CMS] and [ESS]. 233 3.1 The X.400 Message Structure 235 This section reviews the X.400 message format. An X.400 message has two 236 parts, the envelope and the content, as described in X.402 [X.400]: 238 Envelope -- An information object whose composition varies from one 239 transmittal step to another and that variously identifies the message's 240 originator and potential recipients, documents its previous conveyance 241 and directs its subsequent conveyance by the Message Transfer System 242 (MTS), and characterizes its content. 244 Content -- The content is the piece of information that the originating 245 User Agent which is delivered to one or more recipients. The MTS neither 246 examines nor modifies the content, except for conversion, during its 247 conveyance of the message. 249 One piece of information borne by the envelope identifies the type of 250 the content. The content type is an identifier (an ASN.1 OID or Integer) 251 that denotes the syntax and semantics of the content overall. This 252 identifier enables the MTS to determine the message's deliverability to 253 particular users, and enables User Agents and Message Stores to 254 interpret and process the content. 256 Another piece of information borne by the envelope identifies the types 257 of encoded information represented in the content. An encoded 258 information type (EIT) is an identifier (an ASN.1 Object Identifier or 259 Integer) that denotes the medium and format (e.g., IA5 text or Group 3 260 facsimile) of individual portions of the content. It further enables the 261 MTS to determine the message's deliverability to particular users, and 262 to identify opportunities for it to make the message deliverable by 263 converting a portion of the content from one EIT to another. 265 This document describes how S/MIME CMS is used to secure the content 266 part of X.400 messages. 268 3.2 Creating a Signed-only Message with X.400 Content 270 The signedData format as described in the Cryptographic Message Syntax 271 [CMS] MUST be used for signing of X.400 contents. 273 The protected X.400 content MUST then be placed in the eContent field of 274 the signedData element. Note that this X.400 content SHOULD be ASN.1 275 encoded, but SHOULD NOT be MIME wrapped. The object identifier for 276 content type of the protected X.400 content MUST be placed in the 277 eContentType field of the signedData element. The resulting signedData 278 object MAY optionally be wrapped in a MIME encoding. 280 The signedData structure is encapsulated by a ContentInfo SEQUENCE with 281 a contentType of id-signedData. 283 Note that if SMTP is used to transport the resulting signed-only message 284 then the optional MIME encoding SHOULD be used. If other 8-bit transport 285 (e.g., X.400) is used then the optional MIME encoding SHOULD NOT be 286 used. 288 3.2.1 MIME Wrapping to Dynamically Support 7-bit Transport 290 The signedData object MAY optionally be wrapped in MIME to dynamically 291 support 7-bit transport. In this case the application/pkcs7-mime type as 292 defined in S/MIME Version 3 Message Specification [MSG] SHOULD be used 293 with the following parameters: 295 Content-Type: application/pkcs7-mime; smime-type=signed-data 296 Content-Transfer-Encoding: base64 298 If the application/pkcs7-mime MIME type is used to support 7 bit 299 transport, the steps to create this format are: 301 Step 1. The X.400 content to be signed is ASN.1 encoded. 303 Step 2. The ASN.1 encoded X.400 content and other required data is 304 processed into a CMS object of type signedData. 306 Step 3. The CMS object is inserted into an application/pkcs7-mime MIME 307 entity. 309 The smime-type parameter for messages using application/pkcs7-mime with 310 SignedData is "signed-x400". 312 3.3 Creating an Enveloped-only Message with X.400 Content 314 This section describes the format for enveloping an X.400 content 315 without signing it. It is important to note that sending enveloped but 316 not signed messages does not provide for data integrity. It is possible 317 to replace ciphertext in such a way that the processed message will 318 still be valid, but the meaning may be altered. 320 The envelopedData format as described in [CMS] may be used for privacy of 321 the X.400 contents. 323 The protected X.400 content MUST be placed in the eContent field of the 324 envelopedData element. Note that this X.400 content should be ASN.1 325 encoded, but should not be MIME wrapped. The object identifier for 326 content type of the protected X.400 content MUST be placed in the 327 eContentType field of the envelopedData element. The resulting 328 envelopedData object MAY optionally be wrapped in a MIME encoding. 330 The envelopedData structure is encapsulated by a ContentInfo SEQUENCE 331 with a contentType of id-envelopedData. 333 Note that if SMTP is used to transport the resulting enveloped-only 334 message then the optional MIME encoding SHOULD be used. If other 8-bit 335 transport (e.g., X.400) is used then the optional MIME encoding SHOULD 336 NOT be used. 338 3.3.1 MIME Wrapping to Dynamically Support 7-bits Transport 340 The envelopedData object MAY optionally be wrapped in MIME to 341 dynamically support 7-bit transport. In this case the 342 application/pkcs7-mime type as defined in S/MIME Version 3 Message 343 Specification [MSG] SHOULD be used with the following parameters: 345 Content-Type: application/pkcs7-mime; smime-type=enveloped-data 346 Content-Transfer-Encoding: base64 348 If the application/pkcs7-mime MIME type is used to support 7 bit 349 transport, the steps to create this format are: 351 Step 1. The X.400 content to be enveloped is ASN.1 encoded. 353 Step 2. The ASN.1 encoded X.400 content and other required data is 354 processed into a CMS object of type envelopedData. In addition to 355 encrypting a copy of the content-encryption key for each recipient, a 356 copy of the content encryption key SHOULD be encrypted for the 357 originator and included in the envelopedData (see CMS Section 6). 359 Step 3. Optionally the CMS object may be inserted into an 360 application/pkcs7-mime MIME entity to allow for 7-bit transport. 362 If the application/pkcs7-mime MIME entity is used, the smime-type 363 parameter for enveloped-only messages is "enveloped-x400". 365 3.4 Nested CMS Structures 367 To achieve signing and enveloping, any of the signed-only and 368 encrypted-only CMS objects may be nested. 370 When nesting is used, backwards compatibility with S/MIME version 2 371 requires that each layer of the nested message are identified with the 372 OID id-data, and when is-data is used a MIME wrapper is required. This 373 can potentially lead to an enormous amount of overhead and should be 374 avoided. If S/MIME version 2 compatibility is of no concern, 375 implementations should use id-ct-contentInfo to circumvent the MIME 376 wrappers. 378 MIME wrapping to support 7-bit transport, is optional and need only be 379 used around the outermost CMS structure. In this case, the 380 application/pkcs7 content type MUST be used. 382 An S/MIME implementation MUST be able to receive and process arbitrarily 383 nested CMS structures within reasonable resource limits of the recipient 384 computer. 386 3.4.1 Creating a Triple Wrapped Message With an X.400 Content 388 The Enhanced Security Services for S/MIME [ESS] document provides 389 examples of how nested, secured S/MIME messages are formatted. ESS 390 provides an example of how a triple-wrapped S/MIME message is formatted 391 using application/pkcs7-mime for the signatures. 393 This section explains how an X.400 content may be conveyed within a 394 Triple Wrapped Message if S/MIME version 2 compatibility is of no 395 concern: 397 1. Start with the X.400 content (called the "original content"). The 398 X.400 content MUST be ASN.1 encoded, but SHOULD NOT be MIME wrapped. 400 2. Place the protected ASN.1 encoded X.400 content in the eContent field 401 of the signedData element. Add any attributes to be signed. 403 3. Sign the result of step 2 (the original content). The SignedData 404 encapContentInfo eContentType MUST contain the object identifier of the 405 X.400 content. The SignedData structure is encapsulated by a ContentInfo 406 SEQUENCE with a contentType of id-signedData. 408 4. Encrypt the result of step 3 as a single block. The EnvelopedData 409 encryptedContentInfo contentType MUST be set to id-ct-contentInfo. This 410 is called the "encrypted body". The EnvelopedData structure is 411 encapsulated by a ContentInfo SEQUENCE with a contentType of 412 id-envelopedData. 414 5. Using the same logic as in step 2 and 3 above, sign the result of 415 step 5 (the encrypted body) as a single block. The SignedData structure 416 is encapsulated by a ContentInfo SEQUENCE with a contentType of 417 id-signedData. 419 6. The resulting message is called the "outer signature", and is also 420 the triple wrapped message. 422 MIME wrapping to support 7 bit transport, is optional and MUST only be 423 used around the outermost CMS structure. In this case, the 424 application/pkcs7-mime content type MUST be used. 426 3.6 Certificate Enrollment 428 S/MIME v3 does not specify how to get a certificate from a certificate 429 authority, but instead mandates that every sending agent already has a 430 certificate. The PKIX Working Group of the IETF has, at the time of this 431 writing, produced two separate standards for certificate enrollment. 433 4. Certificate Processing 435 A receiving agent MUST provide some certificate retrieval mechanism in 436 order to gain access to certificates for recipients of digital 437 envelopes. This document does not cover how S/MIME agents handle 438 certificates, only what they do after a certificate has been validated 439 or rejected. S/MIME certification issues are covered in [CERT3]. 441 At a minimum, for initial S/MIME deployment, a user agent could 442 automatically generate a message to an intended recipient requesting 443 that recipient's certificate in a signed return message. Receiving and 444 sending agents SHOULD also provide a mechanism to allow a user to "store 445 and protect" certificates for correspondents in such a way so as to 446 guarantee their later retrieval. 448 5. Security Considerations 450 This entire document discusses security. Additional security issues are 451 identified in section 5 of [MSG], section 6 of [ESS] and the Security 452 Considerations section of [CMS]. 454 A. References 456 [CERT3] Ramsdell, B., Editor, "S/MIME Version 3 Certificate 457 Handling", RFC 2632, June 1999. 459 [CMS] Housley, R., "Cryptographic Message Syntax", RFC 2630, June 460 1999. 462 [DH] Rescorla, E., "Diffie-Hellman Key Agreement Method", RFC 2631, 463 June 1999. 465 [DSS] NIST FIPS PUB 186, "Digital Signature Standard", 18 May 1994. 467 [ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME", 468 RFC 2634, June 1999. 470 [MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", 471 RFC 2633, June 1999. 473 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate 474 Requirement Levels", BCP14, RFC 2119, March 1997. 476 [PKCS-1] Kaliski, B., "PKCS #1: RSA Encryption Version 2.0", RFC 477 2437, October 1998. 479 [SHA1] NIST FIPS PUB 180-1, "Secure Hash Standard," National 480 Institute of Standards and Technology, U.S. Department of Commerce, 31 481 May 1994. 483 [X.400] ITU-T X.400 Series of Recommendations, Information technology 484 - Message Handling Systems (MHS). X.400: System and Service Overview; 485 X.402: Overall Architecture; X.411: Message Transfer System: Abstract 486 Service Definition and Procedures; X.420: Interpersonal Messaging 487 System; 1996. 489 B. Editor's Address 491 Paul Hoffman 492 Internet Mail Consortium 493 127 Segre Place 494 Santa Cruz, CA 95060 USA 495 phoffman@imc.org 497 Chris Bonatti 498 IECA, Inc. 499 bonattic@ieca.com 501 Anders Eggen 502 Forsvarets Forskningsinstitutt 503 Postboks 25 504 2027 Kjeller, Norway 505 anders.eggen@ffi.no