idnits 2.17.1 draft-ietf-smime-x400wrap-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 638 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 are 5 instances of too long lines in the document, the longest one being 2 characters 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 151: '...Sending and receiving agents MUST support SHA-1 [CMSALG]....' RFC 2119 keyword, line 155: '...Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG]. The...' RFC 2119 keyword, line 156: '...rithm parameters MUST be absent (not e...' RFC 2119 keyword, line 157: '...agents MUST support rsaEncryption, defined in [CMSALG]....' RFC 2119 keyword, line 159: '...Sending agents MUST support either id-...' (55 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 14, 2004) is 7348 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 563 looks like a reference -- Missing reference section? 'MSG' on line 575 looks like a reference -- Missing reference section? 'MIXER' on line 592 looks like a reference -- Missing reference section? 'BODYMAP' on line 589 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 596 looks like a reference -- Missing reference section? 'CMSALG' on line 569 looks like a reference -- Missing reference section? 'ESS' on line 572 looks like a reference -- Missing reference section? 'CMSAES' on line 566 looks like a reference -- Missing reference section? 'SMTP' on line 599 looks like a reference -- Missing reference section? 'TRANSPORT' on line 578 looks like a reference -- Missing reference section? 'CERT31' on line 560 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 S/MIME Working Group 2 Internet Draft Paul Hoffman, IMC 3 draft-ietf-smime-x400wrap-09.txt Chris Bonatti, IECA 4 August 14, 2003 Anders Eggen, FFI 5 Expires February 14, 2004 7 Securing X.400 Content with S/MIME 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 a protocol for adding cryptographic signature 32 and encryption services to X.400 content. 34 1. Introduction 36 The techniques described in the Cryptographic Message Syntax [CMS] 37 specification are general enough to support many different content 38 types. The [CMS] specification thus provides many options for providing 39 different security mechanisms. In order to ensure interoperability of 40 systems within the X.400 community, it is necessary to specify the use 41 of CMS features to protect X.400 content (called "CMS-X.400" in this 42 document). 44 1.1 Specification Overview 46 This document is intended to be similar to the S/MIME Version 3 Message 47 Specification [MSG] except that it is tailored to the requirements of 48 X.400 content rather than Multipurpose Internet Mail Extensions (MIME). 50 This document defines how to create an X.400 content type that has been 51 cryptographically enhanced according to [CMS]. In order to create S/MIME 52 messages carrying X.400 content, an S/MIME agent has to follow 53 specifications in this document, as well as the specifications listed in 54 [CMS]. This memo also defines new parameter values for the 55 application/pkcs7-mime MIME type that can be used to transport those 56 body parts. 58 Throughout this document, there are requirements and recommendations 59 made for how receiving agents handle incoming messages. There are 60 separate requirements and recommendations for how sending agents create 61 outgoing messages. In general, the best strategy is to "be liberal in 62 what you receive and conservative in what you send". Most of the 63 requirements are placed on the handling of incoming messages while the 64 recommendations are mostly on the creation of outgoing messages. 66 This document does not address transport of CMS-X.400 content. It is 67 assumed that CMS-X.400 content would be transported by Internet mail 68 systems, X.400, or other suitable transport. 70 This document describes applying security services to the content of 71 entire X.400 messages, which may or may not be IPMS messages. These 72 objects can be carried by several means, including SMTP-based mail and 73 X.400 mail. Note that cooperating S/MIME agents must support common 74 forms of message content in order to achieve interoperability. 76 If the CMS objects are sent as parts of an RFC 822 message, a standard 77 MIXER gateway [MIXER] will most likely choose to encapsulate the 78 message. This is not likely to be a format that is usable by an X.400 79 recipient. MIXER is specifically focused on translation between X.420 80 Interpersonal Messages and non-secure RFC822/MIME messages. The 81 discussion of security- related body parts in sections 7.3 and 7.4 of 82 [BODYMAP] is relevant to CMS messages. 84 Definition of gateway services to support relay of CMS object between 85 X.400 and SMTP environments is beyond the scope of this document. 87 1.2 Terminology 89 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and 90 "MAY" in this document are to be interpreted as described in RFC 2119 91 [MUSTSHOULD]. 93 1.3 Definitions 95 For the purposes of this document, the following definitions apply. 97 ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824. 99 BER: Basic Encoding Rules for ASN.1, as defined in ISO/IEC 8825-1. 101 Certificate: A type that binds an entity's distinguished name to a 102 public key with a digital signature. 104 DER: Distinguished Encoding Rules for ASN.1, as defined in ISO/IEC 105 8825-1. 107 7-bit data: Text data with lines less than 998 characters long, where 108 none of the characters have the 8th bit set, and there are no NULL 109 characters. and occur only as part of a end of line 110 delimiter. 112 8-bit data: Text data with lines less than 998 characters, and where 113 none of the characters are NULL characters. and occur only as 114 part of a end of line delimiter. 116 Binary data: Arbitrary data. 118 Transfer Encoding: A reversible transformation made on data so 8-bit or 119 binary data may be sent via a channel that only transmits 7-bit data. 121 Receiving agent: Software that interprets and processes S/MIME CMS 122 objects. 124 Sending agent: Software that creates S/MIME CMS objects. 126 S/MIME agent: User software that is a receiving agent, a sending agent, 127 or both. 129 1.4 Compatibility with Prior Practice of S/MIME 131 There are believed to be no existing X.400 implementations that support 132 S/MIME version 2. Further, signed interoperability between X.400 and 133 MIME systems that support S/MIME version 2 is not believed to be easily 134 achievable. Therefore backward compatibility with S/MIME version 2 is 135 not considered to be a requirement for this document. 137 It is a goal of this draft to, if possible, maintain backward 138 compatibility with existing X.400 implementations that employ S/MIME v3 139 wrappers. 141 2. CMS Options 143 CMS allows for a wide variety of options in content and algorithm 144 support. This section puts forth a number of support requirements and 145 recommendations in order to achieve a base level of interoperability 146 among all CMS-X.400 implementations. [CMS] provides additional details 147 regarding the use of the cryptographic algorithms. 149 2.1 DigestAlgorithmIdentifier 151 Sending and receiving agents MUST support SHA-1 [CMSALG]. 153 2.2 SignatureAlgorithmIdentifier 155 Receiving agents MUST support id-dsa-with-sha1 defined in [CMSALG]. The 156 algorithm parameters MUST be absent (not encoded as NULL). Receiving 157 agents MUST support rsaEncryption, defined in [CMSALG]. 159 Sending agents MUST support either id-dsa-with-sha1 or rsaEncryption. 161 2.3 KeyEncryptionAlgorithmIdentifier 163 Sending and receiving agents MUST support rsaEncryption, defined in 164 [CMSALG]. 166 Sending and receiving agents SHOULD support Diffie-Hellman defined in 167 [CMSALG]. 169 2.4 General Syntax 171 The general syntax of CMS objects consist of an instance of the 172 ContentInfo structure containing one of several defined CMS content 173 types. CMS defines multiple content types. Of these, only the SignedData 174 and EnvelopedData content types are used for CMS-X.400. 176 2.4.1 SignedData Content Type 178 Sending agents MUST use the signedData content type to apply a digital 179 signature to a message or, in a degenerate case where there is no 180 signature information, to convey certificates. 182 2.4.2 EnvelopedData Content Type 184 Senders MUST use the envelopedData content type to apply privacy 185 protection to a message. A sender needs to have access to a public key 186 for each intended message recipient to use this service. This content 187 type does not provide authentication. 189 2.5 Attribute SignerInfo Type 191 The SignerInfo type allows the inclusion of unsigned and signed 192 attributes to be included along with a signature. 194 Receiving agents MUST be able to handle zero or one instance of each of 195 the signed attributes listed here. Sending agents SHOULD generate one 196 instance of each of the following signed attributes in each CMS-X400 197 message: 198 - signingTime 199 - sMIMECapabilities 200 - sMIMEEncryptionKeyPreference 202 Requirements for processing of these attributes MUST be in accordance 203 with the S/MIME Message Specification [MSG]. Handling of the signingTime 204 attribute MUST comply with clause 2.5.1 of [MSG]. Handling of the 205 sMIMECapabilities attribute MUST comply with clause 2.5.2 of [MSG]. 206 Handling of the sMIMEEncryptionKeyPreference attribute MUST comply with 207 clause 2.5.3 of [MSG]. 209 Further, receiving agents SHOULD be able to handle zero or one instance 210 in the signed attributes of the signingCertificate attribute [ESS]. 212 Sending agents SHOULD generate one instance of the signingCertificate 213 signed attribute in each CMS-X400 message. 215 Additional attributes and values for these attributes may be defined in 216 the future. Receiving agents SHOULD handle attributes or values that it 217 does not recognize in a graceful manner. 219 Sending agents that include signed attributes that are not listed here 220 SHOULD display those attributes to the user, so that the user is aware 221 of all of the data being signed. 223 2.6 ContentEncryptionAlgorithmIdentifier 225 Sending and receiving agents MUST support encryption and decryption 226 with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. Sending 227 and receiving agents SHOULD support encryption and decryption with AES 228 [CMSAES] at a key size of 128, 192 and 256 bits. 230 3. Creating S/MIME Messages 232 This section describes the S/MIME message formats and how they can be 233 used to secure X.400 contents. The S/MIME messages are a combination of 234 X.400 contents and CMS objects (i.e., a ContentInfo structure containing 235 one of the CMS-defined content types). The X.400 content and other data, 236 such as certificates and algorithm identifiers, are given to CMS 237 processing facilities which produces a CMS object. This document also 238 describes how nested, secured S/MIME messages should be formatted when 239 encapsulating an X.400 content, and provides an example of how a 240 triple-wrapped S/MIME message over X.400 content should be created if 241 backwards compatibility with S/MIME version 2 is of no concern. 243 S/MIME provides one format for enveloped-only data, several formats for 244 signed-only data, and several formats for signed and enveloped data. The 245 different formats are required to accommodate several environments, in 246 particular for signed messages. Only one of these signed formats is 247 applicable to X.400. 249 Note that canonicalization is not required for X.400 content because it 250 is a binary rather than text encoding, and only the "embedded" content 251 version is used. These dramatically simplify the description of S/MIME 252 productions. 254 The reader of this section is expected to understand X.400 as described 255 in [X.400] and S/MIME as described in [CMS] and [ESS]. 257 3.1 The X.400 Message Structure 259 This section reviews the X.400 message format. An X.400 message has two 260 parts, the envelope and the content, as described in X.402 [X.400]: 262 Envelope -- An information object whose composition varies from one 263 transmittal step to another and that variously identifies the message's 264 originator and potential recipients, documents its previous conveyance 265 and directs its subsequent conveyance by the Message Transfer System 266 (MTS), and characterizes its content. 268 Content -- The content is the piece of information that the originating 269 User Agent wants to be delivered to one or more recipients. The MTS 270 neither examines nor modifies the content, except for conversion, during 271 its conveyance of the message. MTS conversion is not applicable to the 272 scenario of this draft because such conversion is incompatible with CMS 273 protection mechanisms. 275 One piece of information borne by the envelope identifies the type of 276 the content. The content type is an identifier (an ASN.1 OID or Integer) 277 that denotes the syntax and semantics of the content overall. This 278 identifier enables the MTS to determine the message's deliverability to 279 particular users, and enables User Agents and Message Stores to 280 interpret and process the content. 282 Another piece of information borne by the envelope identifies the types 283 of encoded information represented in the content. An encoded 284 information type (EIT) is an identifier (an ASN.1 Object Identifier or 285 Integer) that denotes the medium and format (e.g., IA5 text or Group 3 286 facsimile) of individual portions of the content. It further enables the 287 MTS to determine the message's deliverability to particular users, and 288 to identify opportunities for it to make the message deliverable by 289 converting a portion of the content from one EIT to another. 291 This document describes how S/MIME CMS is used to secure the content 292 part of X.400 messages. 294 3.2 Creating a Signed-only Message with X.400 Content 296 The SignedData format as described in the Cryptographic Message Syntax 297 [CMS] MUST be used for signing of X.400 contents. 299 The X.400 content to be protected MUST be placed in the SignedData 300 encapContentInfo eContent field. Note that this X.400 content SHOULD 301 maintain the encoding defined by the content type, but SHOULD NOT be 302 MIME wrapped. The object identifier for the content type of the 303 protected X.400 content MUST be placed in the SignedData 304 encapContentInfo eContentType field. 306 The signedData object is encapsulated by a ContentInfo SEQUENCE with a 307 contentType of id-signedData. 309 Note that if SMTP [SMTP] is used to transport the resulting signed-only 310 message then the optional MIME encoding SHOULD be used. If binary 311 transports such as X.400 are used then the optional MIME encoding SHOULD 312 NOT be used. 314 There are many reasons for this requirement. An outer MIME wrapper 315 should not be used in X.400. Further, there are places where X.400 316 systems will interact with SMTP/MIME systems where the outer MIME 317 wrapper might be necessary. Because this wrapping is outside the 318 security wrappers, any gateway system that might bridge the gap 319 between the two systems will be smart enough to apply or remove the 320 outer MIME wrapper as appropriate. 322 3.2.1 MIME Wrapping to Dynamically Support 7-bit Transport 324 The signedData object MAY optionally be wrapped in MIME. This allows 325 the system to support 7-bit transport when required. This outer MIME 326 wrapper MAY be dynamically added or removed throughout the delivery path 327 since it is outside the signature and encryption wrappers. In this 328 case the application/pkcs7-mime type as defined in S/MIME Version 3 329 Message Specification [MSG] SHOULD be used with the following 330 parameters: 332 Content-Type: application/pkcs7-mime; smime-type=signed-x400 333 Content-Transfer-Encoding: base64 335 If the application/pkcs7-mime MIME type is used to support 7-bit 336 transport, the steps to create this format are: 338 Step 1. The X.400 content to be signed is ASN.1 encoded. 340 Step 2. The ASN.1 encoded X.400 content and other required data is 341 processed into a CMS object of type SignedData. The SignedData structure 342 is encapsulated by a ContentInfo SEQUENCE with a contentType of 343 id-signedData. 345 Step 3. The CMS object is inserted into an application/pkcs7-mime MIME 346 entity. 348 The smime-type parameter for messages using application/pkcs7-mime with 349 SignedData is "signed-x400" as defined in [TRANSPORT]. 351 3.3 Creating an Enveloped-only Message with X.400 Content 353 This section describes the format for enveloping an X.400 content 354 without signing it. It is important to note that sending enveloped but 355 not signed messages does not provide for data integrity. It is possible 356 to replace ciphertext in such a way that the processed message will 357 still be valid, but the meaning is altered. 359 The EnvelopedData format as described in [CMS] is used for 360 confidentiality of the X.400 contents. 362 The X.400 content to be protected MUST be placed in the EnvelopedData 363 encryptedContentInfo encryptedContent field. Note that this X.400 364 content SHOULD maintain the encoding defined by the content type, but 365 SHOULD NOT be MIME wrapped. The object identifier for content type of 366 the protected X.400 content MUST be placed in the EnvelopedData 367 encryptedContentInfo contentType field. 369 The envelopedData object is encapsulated by a ContentInfo SEQUENCE with 370 a contentType of id-envelopedData. 372 Note that if SMTP is used to transport the resulting enveloped-only 373 message then the optional MIME encoding SHOULD be used. If other 374 transport (e.g., X.400) that is optimized for binary content is used 375 then the optional MIME encoding SHOULD NOT be used. 377 3.3.1 MIME Wrapping to Dynamically Support 7-bits Transport 379 The envelopedData object MAY optionally be wrapped in MIME. This allows 380 the system to support 7-bit transport when required. This outer MIME 381 wrapper MAY be dynamically added or removed throughout the delivery path 382 since it is outside the signature and encryption wrappers. In this 383 case, the application/pkcs7-mime type as defined in S/MIME Version 3 384 Message Specification [MSG] SHOULD be used with the following 385 parameters: 387 Content-Type: application/pkcs7-mime; smime-type=enveloped-x400 388 Content-Transfer-Encoding: base64 390 If the application/pkcs7-mime MIME type is used to support 7-bit 391 transport, the steps to create this format are: 393 Step 1. The X.400 content to be enveloped is ASN.1 encoded. 395 Step 2. The ASN.1 encoded X.400 content and other required data is 396 processed into a CMS object of type EnvelopedData. In addition to 397 encrypting a copy of the content-encryption key for each recipient, a 398 copy of the content encryption key SHOULD be encrypted for the 399 originator and included in the EnvelopedData (see CMS Section 6). The 400 EnvelopedData structure is encapsulated by a ContentInfo SEQUENCE with a 401 contentType of id-envelopedData. 403 Step 3. The CMS object is inserted into an application/pkcs7-mime MIME 404 entity to allow for 7-bit transport. 406 If the application/pkcs7-mime MIME entity is used, the smime-type 407 parameter for enveloped-only messages is "enveloped-x400" as defined in 408 [TRANSPORT]. 410 3.4 Nested CMS Structures 412 To achieve signing and enveloping, any of the signed-only and 413 encrypted-only CMS objects may be nested. 415 When nesting is used, backwards compatibility with S/MIME version 2 416 requires that each layer of the nested message are identified with the 417 OID id-data, and when id-data is used a MIME wrapper is required. This 418 can potentially lead to an enormous amount of overhead and should be 419 avoided. Because S/MIME version 2 compatibility is of no concern, 420 implementations SHOULD directly encode the encapsulated object as the 421 eContent of the current structure. 423 MIME wrapping to support 7-bit transport is optional and need only be 424 used around the outermost CMS structure. In this case, the 425 application/pkcs7 content type MUST be used. 427 An S/MIME implementation MUST be able to receive and process arbitrarily 428 nested CMS structures within reasonable resource limits of the recipient 429 computer. 431 3.4.1 Creating a Triple Wrapped Message With an X.400 Content 433 The Enhanced Security Services for S/MIME [ESS] document provides 434 examples of how nested, secured S/MIME messages are formatted. ESS 435 provides an example of how a triple-wrapped S/MIME message is formatted 436 using application/pkcs7-mime for the signatures. 438 This section explains how an X.400 content may be conveyed within a 439 Triple Wrapped Message because S/MIME version 2 compatibility is of no 440 concern: 442 Step 1. Start with the X.400 content (called the "original content"). 443 The X.400 content MUST be ASN.1 encoded, but SHOULD NOT be MIME wrapped. 445 Step 2. Place the ASN.1 encoded X.400 content to be protected in the 446 SignedData encapContentInfo eContent field. Add any attributes 447 that are to be signed. 449 Step 3. Sign the result of step 2 (the original content). The SignedData 450 encapContentInfo eContentType MUST contain the object identifier of the 451 X.400 content. 453 Step 4. Encrypt the result of step 3 as a single block. The 454 EnvelopedData encryptedContentInfo contentType MUST be set to 455 id-signedData. This is called the "encrypted body". 457 Step 5. Using the same logic as in step 2 and 3 above, sign the result 458 of step 4 (the encrypted body) as a single block. The SignedData 459 encapContentInfo eContentType MUST be set to id-envelopedData. The outer 460 SignedData structure is encapsulated by a ContentInfo SEQUENCE with a 461 contentType of id-signedData. 463 Step 6. The resulting message is called the "outer signature", and is 464 also the triple wrapped message. 466 MIME wrapping to support 7-bit transport is optional and MUST only be 467 used around the outermost CMS structure. In this case, the 468 application/pkcs7-mime content type MUST be used. The smime-type 469 in the case of adding a MIME wrapper MUST be consistent with 470 that appropriate to the innermost protection layer. 472 In some instances, an smime-type will be created that only reflects one 473 security service (such as certs-only, which applies only to signed- 474 only messages). However, as new layers are wrapped, this smime-type 475 SHOULD be propagated upwards. Thus if a certs-only message were to be 476 encrypted, or wrapped in a new SignedData structure, the smime-type of 477 certs-only should be propagated up to the next MIME wrapper. In other 478 words, the innermost type is reflected outwards. 480 3.5 Carrying Plaintext X.400 Content in SMTP 482 While the objectives of this draft focus on protecting X.400 content 483 with CMS wrappers, it is a reality that users do not generally send 484 all message using security. It therefore stands to reason that a 485 means to carry non-secured X.400 content over the chosen transport 486 system must be seemlessly provided. While transporting X.400 content 487 in an X.400 system is trivial, carrying X.400 content in SMTP 488 requires additional definition. 490 Content-Type: application/x400-content; content-type = 491 1*DIGIT *( "." 1*DIGIT) 493 where the content-type parmeter value is either a single integer (for 494 a built-in content-type) or an OID in dotted notation (for an extended 495 content-type). 497 4. Use of Certificates 499 4.1 Certificate Enrollment 501 S/MIME v3 does not specify how to get a certificate from a certificate 502 authority, but instead mandates that every sending agent already has a 503 certificate. The PKIX Working Group has, at the time of this writing, 504 produced two separate standards for certificate enrollment: CMP (RFC 505 2510) and CMC (RFC 2792). 507 4.2 Certificate Processing 509 A receiving agent MUST provide some certificate retrieval mechanism in 510 order to gain access to certificates for recipients of digital 511 envelopes. This document does not cover how S/MIME agents handle 512 certificates, only what they do after a certificate has been validated 513 or rejected. S/MIME certification issues are covered in [CERT31]. 515 At a minimum, for initial S/MIME deployment, a user agent could 516 automatically generate a message to an intended recipient requesting 517 that recipient's certificate in a signed return message. Receiving and 518 sending agents SHOULD also provide a mechanism to allow a user to "store 519 and protect" certificates for correspondents in such a way so as to 520 guarantee their later retrieval. 522 4.3. Certificate Name Use for X.400 Content 524 End-entity certificates used in the context of this draft MAY contain 525 an X.400 address as described in [X.400]. The address must be in the 526 form of an "ORAddress". The X.400 address SHOULD be in the subjectAltName 527 extension, and SHOULD NOT be in the subject distinguished name. 529 Sending agents SHOULD make the originator address in the X.400 content 530 (e.g., the "originator" field in P22) match an X.400 address in the 531 signer's certificate. 533 Receiving agents MUST recognize X.400 addresses in the subjectAltName 534 field. 536 Receiving agents SHOULD check that the originator address in the X.400 537 content matches an X.400 address in the signer's certificate, if X.400 538 addresses are present in the certificate and an originator address is 539 available in the content. A receiving agent SHOULD provide some explicit 540 alternate processing of the message if this comparison fails, which may be 541 to display a message that shows the recipient the addresses in the 542 certificate or other certificate details. 544 The subject alternative name extension is used in S/MIME as the preferred 545 means to convey the X.400 address(es) that correspond to the entity for 546 this certificate. Any X.400 addresses present MUST be encoded using the 547 x400Address CHOICE of the GeneralName type. Since the SubjectAltName type 548 is a SEQUENCE OF GeneralName, multiple X.400 addresses MAY be present. 550 5. Security Considerations 552 This specification introduces no new security concerns to the CMS or 553 S/MIME models. Security issues are identified in section 5 of [MSG], 554 section 6 of [ESS] and the Security Considerations section of [CMS]. 556 A. References 558 A.1 Normative References 560 [CERT31] Ramsdell, B., Editor, "S/MIME Version 3 Certificate 561 Handling", Internet-Draft draft-ietf-smime-rfc2632bis. 563 [CMS] Housley, R., "Cryptographic Message Syntax", Internet-Draft 564 draft-ietf-smime-rfc2630bis. 566 [CMSAES] J. Schaad, "Use of the AES Encryption Algorithm in CMS", 567 Internet Draft draft-ietf-smime-aes-alg. 569 [CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", Internet- 570 Draft draft-ietf-smime-cmsalg 572 [ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME", 573 RFC 2634, June 1999. 575 [MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", 576 Internet-Draft draft-ietf-smime-rfc2633bis. 578 [TRANSPORT] Hoffman, P. and Bonatti, C., "Transporting S/MIME Objects in 579 X.400", work in progress (will progress with this document). 581 [X.400] ITU-T X.400 Series of Recommendations, Information technology 582 - Message Handling Systems (MHS). X.400: System and Service Overview; 583 X.402: Overall Architecture; X.411: Message Transfer System: Abstract 584 Service Definition and Procedures; X.420: Interpersonal Messaging 585 System; 1996. 587 A.2 Non-normative References 589 [BODYMAP] Alvestrand, H., Editor, "Mapping between X.400 and 590 RFC-822/MIME Message Bodies", RFC 2157, January 1998. 592 [MIXER] Kille, S., Editor, "MIXER (Mime Internet X.400 Enhanced 593 Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, 594 January 1998. 596 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP14, RFC 2119, March 1997. 599 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 600 April, 2001. 602 B. Editor's Address 604 Paul Hoffman 605 Internet Mail Consortium 606 127 Segre Place 607 Santa Cruz, CA 95060 USA 608 phoffman@imc.org 610 Chris Bonatti 611 IECA, Inc. 612 15309 Turkey Foot Road 613 Darnestown, MD 20878-3640 USA 614 bonattic@ieca.com 616 Anders Eggen 617 Forsvarets Forskningsinstitutt 618 Postboks 25 619 2027 Kjeller, Norway 620 anders.eggen@ffi.no 622 draft-ietf-smime-x400wrap-09.txt expires February 14, 2004.