idnits 2.17.1 draft-ietf-smime-x400wrap-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 624 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 4 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 150: '...Sending and receiving agents MUST support SHA-1 [CMSALG]....' RFC 2119 keyword, line 154: '...Receiving agents MUST support id-dsa defined in [CMSALG]. The...' RFC 2119 keyword, line 155: '...rithm parameters MUST be absent (not e...' RFC 2119 keyword, line 156: '...agents MUST support rsaEncryption, defined in [CMSALG]....' RFC 2119 keyword, line 158: '...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.) -- 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 558 looks like a reference -- Missing reference section? 'MSG' on line 567 looks like a reference -- Missing reference section? 'MIXER' on line 584 looks like a reference -- Missing reference section? 'BODYMAP' on line 581 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 588 looks like a reference -- Missing reference section? 'CMSALG' on line 561 looks like a reference -- Missing reference section? 'ESS' on line 564 looks like a reference -- Missing reference section? 'SMTP' on line 591 looks like a reference -- Missing reference section? 'TRANSPORT' on line 570 looks like a reference -- Missing reference section? 'CERT31' on line 555 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 12 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-05.txt Chris Bonatti, IECA 3 November 1, 2002 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 the 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 carrying X.400 content, an S/MIME agent has to follow 52 specifications in this document, as well as the specifications listed in 53 [CMS]. This memo also defines new parameter values for the 54 application/pkcs7-mime MIME type that can be used to transport those 55 body parts. 57 Throughout this document, there are requirements and recommendations 58 made for how receiving agents handle incoming messages. There are 59 separate requirements and recommendations for how sending agents create 60 outgoing messages. In general, the best strategy is to "be liberal in 61 what you receive and conservative in what you send". Most of the 62 requirements are placed on the handling of incoming messages while the 63 recommendations are mostly on the creation of outgoing messages. 65 This document does not address transport of CMS-X.400 content. It is 66 assumed that CMS-X.400 content would be transported by Internet mail 67 systems, X.400, or other suitable transport. 69 This document describes applying security services to the content of 70 entire X.400 messages, which may or may not be IPMS messages. These 71 objects can be carried by several means, including SMTP-based mail and 72 X.400 mail. Note that cooperating S/MIME agents must support common 73 forms of message content in order to achieve interoperability. 75 If the CMS objects are sent as parts of an RFC 822 message, a standard 76 MIXER gateway [MIXER] will most likely choose to encapsulate the 77 message. This is not likely to be a format that is usable by an X.400 78 recipient. MIXER is specifically focused on translation between X.420 79 Interpersonal Messages and non-secure RFC822/MIME messages. The 80 discussion of security- related body parts in sections 7.3 and 7.4 of 81 [BODYMAP] is relevant to CMS messages. 83 Definition of gateway services to support relay of CMS object between 84 X.400 and SMTP environments is beyond the scope of this document. 86 1.2 Terminology 88 The key words "MUST", "SHALL", "REQUIRED", "SHOULD", "RECOMMENDED", and 89 "MAY" in this document are to be interpreted as described in RFC 2119 90 [MUSTSHOULD]. 92 1.3 Definitions 94 For the purposes of this document, the following definitions apply. 96 ASN.1: Abstract Syntax Notation One, as defined in ISO/IEC 8824. 98 BER: Basic Encoding Rules for ASN.1, as defined in ISO/IEC 8825-1. 100 Certificate: A type that binds an entity's distinguished name to a 101 public key with a digital signature. 103 DER: Distinguished Encoding Rules for ASN.1, as defined in ISO/IEC 104 8825-1. 106 7-bit data: Text data with lines less than 998 characters long, where 107 none of the characters have the 8th bit set, and there are no NULL 108 characters. and occur only as part of a end of line 109 delimiter. 111 8-bit data: Text data with lines less than 998 characters, and where 112 none of the characters are NULL characters. and occur only as 113 part of a end of line delimiter. 115 Binary data: Arbitrary data. 117 Transfer Encoding: A reversible transformation made on data so 8-bit or 118 binary data may be sent via a channel that only transmits 7-bit data. 120 Receiving agent: Software that interprets and processes S/MIME CMS 121 objects. 123 Sending agent: Software that creates S/MIME CMS objects. 125 S/MIME agent: User software that is a receiving agent, a sending agent, 126 or both. 128 1.4 Compatibility with Prior Practice of S/MIME 130 There are believed to be no existing X.400 implementations that support 131 S/MIME version 2. Further, signed interoperability between X.400 and 132 MIME systems that support S/MIME version 2 is not believed to be easily 133 achievable. Therefore backward compatibility with S/MIME version 2 is 134 not considered to be a requirement for this document. 136 It is a goal of this draft to, if possible, maintain backward 137 compatibility with existing X.400 implementations that employ S/MIME v3 138 wrappers. 140 2. CMS Options 142 CMS allows for a wide variety of options in content and algorithm 143 support. This section puts forth a number of support requirements and 144 recommendations in order to achieve a base level of interoperability 145 among all CMS-X.400 implementations. [CMS] provides additional details 146 regarding the use of the cryptographic algorithms. 148 2.1 DigestAlgorithmIdentifier 150 Sending and receiving agents MUST support SHA-1 [CMSALG]. 152 2.2 SignatureAlgorithmIdentifier 154 Receiving agents MUST support id-dsa defined in [CMSALG]. The 155 algorithm parameters MUST be absent (not encoded as NULL). Receiving 156 agents MUST support rsaEncryption, defined in [CMSALG]. 158 Sending agents MUST support either id-dsa or rsaEncryption. 160 2.3 KeyEncryptionAlgorithmIdentifier 162 Sending and receiving agents MUST support rsaEncryption, defined in 163 [CMSALG]. 165 Sending and receiving agents SHOULD support Diffie-Hellman defined in 166 [CMSALG]. 168 2.4 General Syntax 170 The general syntax of CMS objects consist of an instance of the 171 ContentInfo structure containing one of several defined CMS content 172 types. CMS defines multiple content types. Of these, only the SignedData 173 and EnvelopedData content types are used for CMS-X.400. 175 2.4.1 SignedData Content Type 177 Sending agents MUST use the signedData content type to apply a digital 178 signature to a message or, in a degenerate case where there is no 179 signature information, to convey certificates. 181 2.4.2 EnvelopedData Content Type 183 Senders MUST use the envelopedData content type to apply privacy 184 protection to a message. A sender needs to have access to a public key 185 for each intended message recipient to use this service. This content 186 type does not provide authentication. 188 2.5 Attribute SignerInfo Type 190 The SignerInfo type allows the inclusion of unsigned and signed 191 attributes to be included along with a signature. 193 Receiving agents MUST be able to handle zero or one instance of each of 194 the signed attributes listed here. Sending agents SHOULD generate one 195 instance of each of the following signed attributes in each CMS-X400 196 message: 197 - signingTime 198 - sMIMECapabilities 199 - sMIMEEncryptionKeyPreference 201 Requirements for processing of these attributes MUST be in accordance 202 with the S/MIME Message Specification [MSG]. Handling of the signingTime 203 attribute MUST comply with clause 2.5.1 of [MSG]. Handling of the 204 sMIMECapabilities attribute MUST comply with clause 2.5.2 of [MSG]. 205 Handling of the sMIMEEncryptionKeyPreference attribute MUST comply with 206 clause 2.5.3 of [MSG]. 208 Further, receiving agents SHOULD be able to handle zero or one instance 209 in the signed attributes of the signingCertificate attribute [ESS]. 211 Sending agents SHOULD generate one instance of the signingCertificate 212 signed attribute in each CMS-X400 message. 214 Additional attributes and values for these attributes may be defined in 215 the future. Receiving agents SHOULD handle attributes or values that it 216 does not recognize in a graceful manner. 218 Sending agents that include signed attributes that are not listed here 219 SHOULD display those attributes to the user, so that the user is aware 220 of all of the data being signed. 222 2.6 ContentEncryptionAlgorithmIdentifier 224 Sending and receiving agents MUST support encryption and decryption 225 with DES EDE3 CBC, hereinafter called "tripleDES" [CMSALG]. 227 3. Creating S/MIME Messages 229 This section describes the S/MIME message formats and how they can be 230 used to secure X.400 contents. The S/MIME messages are a combination of 231 X.400 contents and CMS objects (i.e., a ContentInfo structure containing 232 one of the CMS-defined content types). The X.400 content and other data, 233 such as certificates and algorithm identifiers, are given to CMS 234 processing facilities which produces a CMS object. This document also 235 describes how nested, secured S/MIME messages should be formatted when 236 encapsulating an X.400 content, and provides an example of how a 237 triple-wrapped S/MIME message over X.400 content should be created if 238 backwards compatibility with S/MIME version 2 is of no concern. 240 S/MIME provides one format for enveloped-only data, several formats for 241 signed-only data, and several formats for signed and enveloped data. The 242 different formats are required to accommodate several environments, in 243 particular for signed messages. Only one of these signed formats is 244 applicable to X.400. 246 Note that canonicalization is not required for X.400 content because it 247 is a binary rather than text encoding, and only the "embedded" content 248 version is used. These dramatically simplify the description of S/MIME 249 productions. 251 The reader of this section is expected to understand X.400 as described 252 in [X.400] and S/MIME as described in [CMS] and [ESS]. 254 3.1 The X.400 Message Structure 256 This section reviews the X.400 message format. An X.400 message has two 257 parts, the envelope and the content, as described in X.402 [X.400]: 259 Envelope -- An information object whose composition varies from one 260 transmittal step to another and that variously identifies the message's 261 originator and potential recipients, documents its previous conveyance 262 and directs its subsequent conveyance by the Message Transfer System 263 (MTS), and characterizes its content. 265 Content -- The content is the piece of information that the originating 266 User Agent wants to be delivered to one or more recipients. The MTS 267 neither examines nor modifies the content, except for conversion, during 268 its conveyance of the message. MTS conversion is not applicable to the 269 scenario of this draft because such conversion is incompatible with CMS 270 protection mechanisms. 272 One piece of information borne by the envelope identifies the type of 273 the content. The content type is an identifier (an ASN.1 OID or Integer) 274 that denotes the syntax and semantics of the content overall. This 275 identifier enables the MTS to determine the message's deliverability to 276 particular users, and enables User Agents and Message Stores to 277 interpret and process the content. 279 Another piece of information borne by the envelope identifies the types 280 of encoded information represented in the content. An encoded 281 information type (EIT) is an identifier (an ASN.1 Object Identifier or 282 Integer) that denotes the medium and format (e.g., IA5 text or Group 3 283 facsimile) of individual portions of the content. It further enables the 284 MTS to determine the message's deliverability to particular users, and 285 to identify opportunities for it to make the message deliverable by 286 converting a portion of the content from one EIT to another. 288 This document describes how S/MIME CMS is used to secure the content 289 part of X.400 messages. 291 3.2 Creating a Signed-only Message with X.400 Content 293 The SignedData format as described in the Cryptographic Message Syntax 294 [CMS] MUST be used for signing of X.400 contents. 296 The X.400 content to be protected MUST be placed in the SignedData 297 encapContentInfo eContent field. Note that this X.400 content SHOULD 298 maintain the encoding defined by the content type, but SHOULD NOT be 299 MIME wrapped. The object identifier for the content type of the 300 protected X.400 content MUST be placed in the SignedData 301 encapContentInfo eContentType field. 303 The signedData object is encapsulated by a ContentInfo SEQUENCE with a 304 contentType of id-signedData. 306 Note that if SMTP [SMTP] is used to transport the resulting signed-only 307 message then the optional MIME encoding SHOULD be used. If binary 308 transports such as X.400 are used then the optional MIME encoding SHOULD 309 NOT be used. 311 There are many reasons for this requirement. An outer MIME wrapper 312 should not be used in X.400. Further, there are places where X.400 313 systems will interact with SMTP/MIME systems where the outer MIME 314 wrapper might be necessary. Because this wrapping is outside the 315 security wrappers, whatever gateway system that is bridging the gap 316 between the two systems will be smart enough to apply or remove the 317 outer MIME wrapper as appropriate. 319 3.2.1 MIME Wrapping to Dynamically Support 7-bit Transport 321 The signedData object MAY optionally be wrapped in MIME. This allows 322 the system to support 7-bit transport when required. This outer MIME 323 wrapper MAY be dynamically added or removed throughout the delivery path 324 since it is out the signature and encryption wrappers. In this case the 325 application/pkcs7-mime type as defined in S/MIME Version 3 Message 326 Specification [MSG] SHOULD be used with the following parameters: 328 Content-Type: application/pkcs7-mime; smime-type=signed-x400 329 Content-Transfer-Encoding: base64 331 If the application/pkcs7-mime MIME type is used to support 7-bit 332 transport, the steps to create this format are: 334 Step 1. The X.400 content to be signed is ASN.1 encoded. 336 Step 2. The ASN.1 encoded X.400 content and other required data is 337 processed into a CMS object of type SignedData. The SignedData structure 338 is encapsulated by a ContentInfo SEQUENCE with a contentType of 339 id-signedData. 341 Step 3. The CMS object is inserted into an application/pkcs7-mime MIME 342 entity. 344 The smime-type parameter for messages using application/pkcs7-mime with 345 SignedData is "signed-x400" as defined in [TRANSPORT]. 347 3.3 Creating an Enveloped-only Message with X.400 Content 349 This section describes the format for enveloping an X.400 content 350 without signing it. It is important to note that sending enveloped but 351 not signed messages does not provide for data integrity. It is possible 352 to replace ciphertext in such a way that the processed message will 353 still be valid, but the meaning is altered. 355 The EnvelopedData format as described in [CMS] is used for 356 confidentiality of the X.400 contents. 358 The X.400 content to be protected MUST be placed in the EnvelopedData 359 encryptedContentInfo encryptedContent field. Note that this X.400 360 content SHOULD maintain the encoding defined by the content type, but 361 SHOULD NOT be MIME wrapped. The object identifier for content type of 362 the protected X.400 content MUST be placed in the EnvelopedData 363 encryptedContentInfo contentType field. 365 The envelopedData object is encapsulated by a ContentInfo SEQUENCE with 366 a contentType of id-envelopedData. 368 Note that if SMTP is used to transport the resulting enveloped-only 369 message then the optional MIME encoding SHOULD be used. If other binary 370 transport (e.g., X.400) is used then the optional MIME encoding SHOULD 371 NOT be used. 373 3.3.1 MIME Wrapping to Dynamically Support 7-bits Transport 375 The envelopedData object MAY optionally be wrapped in MIME. This allows 376 the system to support 7-bit transport when required. This outer MIME 377 wrapper MAY be dynamically added or removed throughout the delivery path 378 since it is out the signature and encryption wrappers. In this case, 379 the application/pkcs7-mime type as defined in S/MIME Version 3 Message 380 Specification [MSG] SHOULD be used with the following parameters: 382 Content-Type: application/pkcs7-mime; smime-type=enveloped-x400 383 Content-Transfer-Encoding: base64 385 If the application/pkcs7-mime MIME type is used to support 7-bit 386 transport, the steps to create this format are: 388 Step 1. The X.400 content to be enveloped is ASN.1 encoded. 390 Step 2. The ASN.1 encoded X.400 content and other required data is 391 processed into a CMS object of type EnvelopedData. In addition to 392 encrypting a copy of the content-encryption key for each recipient, a 393 copy of the content encryption key SHOULD be encrypted for the 394 originator and included in the EnvelopedData (see CMS Section 6). The 395 EnvelopedData structure is encapsulated by a ContentInfo SEQUENCE with a 396 contentType of id-envelopedData. 398 Step 3. The CMS object is inserted into an application/pkcs7-mime MIME 399 entity to allow for 7-bit transport. 401 If the application/pkcs7-mime MIME entity is used, the smime-type 402 parameter for enveloped-only messages is "enveloped-x400" as defined in 403 [TRANSPORT]. 405 3.4 Nested CMS Structures 407 To achieve signing and enveloping, any of the signed-only and 408 encrypted-only CMS objects may be nested. 410 When nesting is used, backwards compatibility with S/MIME version 2 411 requires that each layer of the nested message are identified with the 412 OID id-data, and when id-data is used a MIME wrapper is required. This 413 can potentially lead to an enormous amount of overhead and should be 414 avoided. Because S/MIME version 2 compatibility is of no concern, 415 implementations SHOULD directly encode the encapsulated object as the 416 eContent of the current structure. 418 MIME wrapping to support 7-bit transport is optional and need only be 419 used around the outermost CMS structure. In this case, the 420 application/pkcs7 content type MUST be used. 422 An S/MIME implementation MUST be able to receive and process arbitrarily 423 nested CMS structures within reasonable resource limits of the recipient 424 computer. 426 3.4.1 Creating a Triple Wrapped Message With an X.400 Content 428 The Enhanced Security Services for S/MIME [ESS] document provides 429 examples of how nested, secured S/MIME messages are formatted. ESS 430 provides an example of how a triple-wrapped S/MIME message is formatted 431 using application/pkcs7-mime for the signatures. 433 This section explains how an X.400 content may be conveyed within a 434 Triple Wrapped Message because S/MIME version 2 compatibility is of no 435 concern: 437 Step 1. Start with the X.400 content (called the "original content"). 438 The X.400 content MUST be ASN.1 encoded, but SHOULD NOT be MIME wrapped. 440 Step 2. Place the ASN.1 encoded X.400 content to be protected in the 441 SignedData encapContentInfo eContent field. Add any attributes 442 that are to be signed. 444 Step 3. Sign the result of step 2 (the original content). The SignedData 445 encapContentInfo eContentType MUST contain the object identifier of the 446 X.400 content. 448 Step 4. Encrypt the result of step 3 as a single block. The 449 EnvelopedData encryptedContentInfo contentType MUST be set to 450 id-signedData. This is called the "encrypted body". 452 Step 5. Using the same logic as in step 2 and 3 above, sign the result 453 of step 4 (the encrypted body) as a single block. The SignedData 454 encapContentInfo eContentType MUST be set to id-envelopedData. The outer 455 SignedData structure is encapsulated by a ContentInfo SEQUENCE with a 456 contentType of id-signedData. 458 Step 6. The resulting message is called the "outer signature", and is 459 also the triple wrapped message. 461 MIME wrapping to support 7-bit transport, is optional and MUST only be 462 used around the outermost CMS structure. In this case, the 463 application/pkcs7-mime content type MUST be used. The smime-type 464 in the case of adding a MIME wrapper MUST be consistent with 465 that appropriate to the innermost protection layer. 467 In some instances, an smime-type will be created that only reflects one 468 security service (such as certs-only, which is only for signed). 469 However, as new layers are wrapped, this smime-type SHOULD be propagated 470 upwards. Thus if a certs-only message were to be encrypted, or wrapped 471 in a new SignedData structure, the smime-type of certs-only should be 472 propagated up to the next MIME wrapper. In other words, the innermost 473 type is reflected outwards. 475 3.5 Carrying Plaintext X.400 Content in SMTP 477 While the objectives of this draft focus on protecting X.400 content 478 with CMS wrappers, it is a reality that users do not generally send 479 all message using security. It therefore stands to reason that a 480 means to carry non-secured X.400 content over the chosen transport 481 system must be seemlessly provided. While transporting X.400 content 482 in an X.400 system is trivial, carrying X.400 content in SMTP 483 requires additional definition. 485 Content-Type: application/x400-content; content-type = 486 1*DIGIT *( "." 1*DIGIT) 488 where the content-type parmeter value is either a single integer (for 489 a built-in content-type) or an OID in dotted notation (for an extended 490 content-type). 492 4. Use of Certificates 494 4.1 Certificate Enrollment 496 S/MIME v3 does not specify how to get a certificate from a certificate 497 authority, but instead mandates that every sending agent already has a 498 certificate. The PKIX Working Group has, at the time of this writing, 499 produced two separate standards for certificate enrollment: CMP (RFC 500 2510) and CMC (RFC 2792). 502 4.2 Certificate Processing 504 A receiving agent MUST provide some certificate retrieval mechanism in 505 order to gain access to certificates for recipients of digital 506 envelopes. This document does not cover how S/MIME agents handle 507 certificates, only what they do after a certificate has been validated 508 or rejected. S/MIME certification issues are covered in [CERT31]. 510 At a minimum, for initial S/MIME deployment, a user agent could 511 automatically generate a message to an intended recipient requesting 512 that recipient's certificate in a signed return message. Receiving and 513 sending agents SHOULD also provide a mechanism to allow a user to "store 514 and protect" certificates for correspondents in such a way so as to 515 guarantee their later retrieval. 517 4.3. Certificate Name Use for X.400 Content 519 End-entity certificates used in the context of this draft MAY contain 520 an X.400 address as described in [X.400]. The address must be in the 521 form of an "ORAddress". The X.400 address SHOULD be in the subjectAltName 522 extension, and SHOULD NOT be in the subject distinguished name. 524 Sending agents SHOULD make the originator address in the X.400 content 525 (e.g., the "originator" field in P22) match an X.400 address in the 526 signer's certificate. 528 Receiving agents MUST recognize X.400 addresses in the subjectAltName 529 field. 531 Receiving agents SHOULD check that the originator address in the X.400 532 content matches an X.400 address in the signer's certificate, if X.400 533 addresses are present in the certificate and an originator address is 534 available in the content. A receiving agent SHOULD provide some explicit 535 alternate processing of the message if this comparison fails, which may be 536 to display a message that shows the recipient the addresses in the 537 certificate or other certificate details. 539 The subject alternative name extension is used in S/MIME as the preferred 540 means to convey the X.400 address(es) that correspond to the entity for 541 this certificate. Any X.400 addresses present MUST be encoded using the 542 x400Address CHOICE of the GeneralName type. Since the SubjectAltName type 543 is a SEQUENCE OF GeneralName, multiple X.400 addresses MAY be present. 545 5. Security Considerations 547 This entire document discusses security. Additional security issues are 548 identified in section 5 of [MSG], section 6 of [ESS] and the Security 549 Considerations section of [CMS]. 551 A. References 553 A.1 Normative References 555 [CERT31] Ramsdell, B., Editor, "S/MIME Version 3 Certificate 556 Handling", Internet-Draft draft-ietf-smime-rfc2632bis. 558 [CMS] Housley, R., "Cryptographic Message Syntax", Internet-Draft 559 draft-ietf-smime-rfc2630bis. 561 [CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", Internet- 562 Draft draft-ietf-smime-cmsalg 564 [ESS] Hoffman, P., Editor "Enhanced Security Services for S/MIME", 565 RFC 2634, June 1999. 567 [MSG] Ramsdell, B., Editor "S/MIME Version 3 Message Specification", 568 Internet-Draft draft-ietf-smime-rfc2633bis. 570 [TRANSPORT] Hoffman, P. and Bonatti, C., "Transporting S/MIME Objects in 571 X.400", work in progress (will progress with this document). 573 [X.400] ITU-T X.400 Series of Recommendations, Information technology 574 - Message Handling Systems (MHS). X.400: System and Service Overview; 575 X.402: Overall Architecture; X.411: Message Transfer System: Abstract 576 Service Definition and Procedures; X.420: Interpersonal Messaging 577 System; 1996. 579 A.2 Non-normative References 581 [BODYMAP] Alvestrand, H., Editor, "Mapping between X.400 and 582 RFC-822/MIME Message Bodies", RFC 2157, January 1998. 584 [MIXER] Kille, S., Editor, "MIXER (Mime Internet X.400 Enhanced 585 Relay): Mapping between X.400 and RFC 822/MIME", RFC 2156, 586 January 1998. 588 [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate 589 Requirement Levels", BCP14, RFC 2119, March 1997. 591 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 592 April, 2001. 594 B. Editor's Address 596 Paul Hoffman 597 Internet Mail Consortium 598 127 Segre Place 599 Santa Cruz, CA 95060 USA 600 phoffman@imc.org 602 Chris Bonatti 603 IECA, Inc. 604 15309 Turkey Foot Road 605 Darnestown, MD 20878-3640 USA 606 bonattic@ieca.com 608 Anders Eggen 609 Forsvarets Forskningsinstitutt 610 Postboks 25 611 2027 Kjeller, Norway 612 anders.eggen@ffi.no