idnits 2.17.1 draft-dusse-smime-cert-05.txt: -(351): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(469): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == There are 2 instances of lines with non-ascii characters in the document. == 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 802 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Abstract section. ** 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 170 instances of too long lines in the document, the longest one being 3 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 82: '...draft, the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 108: '...Receiving agents MUST support for the ...' RFC 2119 keyword, line 110: '...messages, the CRL format defined in [KEYM] MUST be used....' RFC 2119 keyword, line 112: '...All agents MUST validate CRLs and chec...' RFC 2119 keyword, line 113: '...available, in accordance with [KEYM]. All agents SHOULD check the...' (67 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. -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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? 'SMIME-MSG' on line 701 looks like a reference -- Missing reference section? 'PKCS-1' on line 689 looks like a reference -- Missing reference section? 'PKCS-7' on line 692 looks like a reference -- Missing reference section? 'PKCS-10' on line 695 looks like a reference -- Missing reference section? 'KEYM' on line 682 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 686 looks like a reference -- Missing reference section? 'RFC-822' on line 698 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Steve Dusse, 2 draft-dusse-smime-cert-05.txt RSA Data Security 3 November 08, 1997 Paul Hoffman, 4 Expires in six months Internet Mail Consortium 5 Blake Ramsdell, 6 Worldtalk 7 Jeff Weinstein, 8 Netscape 10 S/MIME Certificate Handling 12 Status of this memo 14 This document is an Internet-Draft. Internet-Drafts are working documents 15 of the Internet Engineering Task Force (IETF), its areas, and its working 16 groups. Note that other groups may also distribute working documents as 17 Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months and 20 may be updated, replaced, or obsoleted by other documents at any time. It 21 is inappropriate to use Internet-Drafts as reference material or to cite 22 them other than as "work in progress." 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au 27 (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West 28 Coast). 30 1. Overview 32 S/MIME (Secure/Multipurpose Internet Mail Extensions), described in 33 [SMIME-MSG], provides a method to send and receive secure MIME messages. In 34 order to validate the keys of a message sent to it, an S/MIME agent needs 35 to certify that the key is valid. This draft describes the mechanisms 36 S/MIME uses to create and validate keys using certificates. 38 This specification is compatible with PKCS #7 in that it uses the data 39 types defined by PKCS #7. It also inherits all the varieties of 40 architectures for certificate-based key management supported by PKCS #7. 41 Note that the method S/MIME messages make certificate requests is defined 42 in [SMIME-MSG]. 44 In order to handle S/MIME certificates, an agent has to follow 45 specifications in this draft, as well as some of the specifications listed 46 in the following documents: 47 - "PKCS #1: RSA Encryption", [PKCS-1]. 48 - "PKCS #7: Cryptographic Message Syntax", [PKCS-7] 49 - "PKCS #10: Certification Request Syntax", [PKCS-10]. 51 1.1 Definitions 53 For the purposes of this draft, the following definitions apply. 55 ASN.1: Abstract Syntax Notation One, as defined in CCITT X.680-689. 57 BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.690. 59 Certificate: A type that binds an entity's distinguished name to a public 60 key with a digital signature. This type is defined in CCITT X.509 [X.509]. 61 This type also contains the distinguished name of the certificate issuer 62 (the signer), an issuer-specific serial number, the issuer's signature 63 algorithm identifier, and a validity period. 65 Certificate Revocation List (CRL): A type that contains information about 66 certificates whose validity an issuer has prematurely revoked. The 67 information consists of an issuer name, the time of issue, the next 68 scheduled time of issue, and a list of certificate serial numbers and their 69 associated revocation times. The CRL is signed by the issuer. The type 70 intended by this specification is the one defined in [KEYM]. 72 DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT X.690. 74 1.2 Compatibility with Prior Practice of S/MIME 76 Appendix C contains important information about how S/MIME agents following 77 this specification should act in order to have the greatest 78 interoperability with earlier implementations of S/MIME. 80 1.3 Terminology 82 Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD NOT are 83 used in capital letters. This conforms to the definitions in [MUSTSHOULD]. 84 [MUSTSHOULD] defines the use of these key words to help make the intent of 85 standards track documents as clear as possible. The same key words are used 86 in this document to help implementors achieve interoperability. 88 1.4 Discussion of This Draft 90 This draft is being discussed on the "ietf-smime" mailing list. 91 To subscribe, send a message to: 92 ietf-smime-request@imc.org 93 with the single word 94 subscribe 95 in the body of the message. There is a Web site for the mailing list 96 at . 98 2. PKCS #7 Options 100 The PKCS #7 message format allows for a wide variety of options in content 101 and algorithm support. This section puts forth a number of support 102 requirements and recommendations in order to achieve a base level of 103 interoperability among all S/MIME implementations. Most of the PKCS #7 104 format for S/MIME messages is defined in [SMIME-MSG]. 106 2.1 CertificateRevocationLists 108 Receiving agents MUST support for the Certificate Revocation List (CRL) 109 format defined in [KEYM]. If sending agents include CRLs in outgoing 110 messages, the CRL format defined in [KEYM] MUST be used. 112 All agents MUST validate CRLs and check certificates against CRLs, if 113 available, in accordance with [KEYM]. All agents SHOULD check the 114 nextUpdate field in the CRL against the current time. If the current time 115 is later than the nextUpdate time, the action that the agent takes is a 116 local decision. For instance, it could warn a human user, it could 117 retrieve a new CRL if able, and so on. 119 Receiving agents MUST recognize CRLs in received S/MIME messages. 121 Clients MUST use revocation information included as a CRL in an S/MIME 122 message when verifying the signature and certificate path validity in that 123 message. Clients SHOULD store CRLs received in messages for use in 124 processing later messages. 126 Clients MUST handle multiple valid Certificate Authority (CA) certificates 127 containing the same subject name and the same public keys but with 128 overlapping validity intervals. 130 2.2 ExtendedCertificateOrCertificate 132 Receiving agents MUST support X.509 v1 and X.509 v3 certificates. See 133 [KEYM] for details about the profile for certificate formats. End entity 134 certificates MUST include an Internet mail address, as described in section 135 3.1. 137 2.2.1 Historical Note About PKCS #7 Certificates 139 The PKCS #7 message format supports a choice of certificate two formats for 140 public key content types: X.509 and PKCS #6 Extended Certificates. The PKCS 141 #6 format is not in widespread use. In addition, proposed revisions of 142 X.509 certificates address much of the same functionality and flexibility 143 as was intended in the PKCS #6. Thus, sending and receiving agents MUST NOT 144 use PKCS #6 extended certificates. 146 2.3 ExtendedCertificateAndCertificates 148 Receiving agents MUST be able to handle an arbitrary number of certificates 149 of arbitrary relationship to the message sender and to each other in 150 arbitrary order. In many cases, the certificates included in a signed 151 message may represent a chain of certification from the sender to a 152 particular root. There may be, however, situations where the certificates 153 in a signed message may be unrelated and included for convenience. 155 Sending agents SHOULD include any certificates for the user's public key(s) 156 and associated issuer certificates. This increases the likelihood that the 157 intended recipient can establish trust in the originator's public key(s). 158 This is especially important when sending a message to recipients that may 159 not have access to the sender's public key through any other means or when 160 sending a signed message to a new recipient. The inclusion of certificates 161 in outgoing messages can be omitted if S/MIME objects are sent within a 162 group of correspondents that has established access to each other's 163 certificates by some other means such as a shared directory or manual 164 certificate distribution. Receiving S/MIME agents SHOULD be able to handle 165 messages without certificates using a database or directory lookup scheme. 167 A sending agent SHOULD include at least one chain of certificates up to, 168 but not including, a Certificate Authority (CA) that it believes that the 169 recipient may trust as authoritative. A receiving agent SHOULD be able to 170 handle an arbitrarily large number of certificates and chains. 172 Clients MAY send CA certificates, that is, certificates that are 173 self-signed and can be considered the "root" of other chains. Note that 174 receiving agents SHOULD NOT simply trust any self-signed certificates as 175 valid CAs, but SHOULD use some other mechanism to determine if this is a CA 176 that should be trusted. 178 Receiving agents MUST support chaining based on the distinguished name 179 fields. Other methods of building certificate chains may be supported but 180 are not currently recommended. 182 3. Distinguished Names in Certificates 184 3.1 Using Distinguished Names for Internet Mail 186 The format of an X.509 certificate includes fields for the subject name and 187 issuer name. The subject name identifies the owner of a particular public 188 key/private key pair while the issuer name is meant to identify the entity 189 that "certified" the subject (that is, who signed the subject's 190 certificate). The subject name and issuer name are defined by X.509 as 191 Distinguished Names. 193 Distinguished Names are defined by a CCITT standard X.501 [X.501]. A 194 Distinguished Name is broken into one or more Relative Distinguished Names. 195 Each Relative Distinguished Name is comprised of one or more 196 Attribute-Value Assertions. Each Attribute-Value Assertion consists of a 197 Attribute Identifier and its corresponding value information, such as 198 CountryName=US. Distinguished Names were intended to identify entities in 199 the X.500 directory tree [X.500]. Each Relative Distinguished Name can be 200 thought of as a node in the tree which is described by some collection of 201 Attribute-Value Assertions. The entire Distinguished Name is some 202 collection of nodes in the tree that traverse a path from the root of the 203 tree to some end node which represents a particular entity. 205 The goal of the directory was to provide an infrastructure to uniquely name 206 every communications entity everywhere. However, adoption of a global X.500 207 directory infrastructure has been slower than expected. Consequently, there 208 is no requirement for X.500 directory service provision in the S/MIME 209 environment, although such provision would almost undoubtedly be of great 210 value in facilitating key management for S/MIME. 212 The use of Distinguished Names in accordance with the X.500 directory is 213 not very widespread. By contrast, Internet mail addresses, as described in 214 RFC 822 [RFC-822], are used almost exclusively in the Internet environment 215 to identify originators and recipients of messages. However, Internet mail 216 addresses bear no resemblance to X.500 Distinguished Names (except, 217 perhaps, that they are both hierarchical in nature). Some method is needed 218 to map Internet mail addresses to entities that hold public keys. Some 219 people have suggested that the X.509 certificate format should be abandoned 220 in favor of other binding mechanisms. Instead, S/MIME keeps the X.509 221 certificate and Distinguished Name mechanisms while tailoring the content 222 of the naming information to suit the Internet mail environment. 224 End-entity certificates MUST contain an Internet mail address as described 225 in [RFC-822]. The address must be an "addr-spec" as defined in Section 6.1 226 of that specification. 228 Receiving agents MUST recognize email addresses in the subjectAltName 229 field. Receiving agents MUST recognize email addresses in the Distinguished 230 Name field. 232 Sending agents SHOULD make the address in the From header in a mail message 233 match an Internet mail address in the signer's certificate. Receiving 234 agents MUST check that the address in the From header of a mail message 235 matches an Internet mail address in the signer's certificate. A receiving 236 agent MUST provide some explicit alternate processing of the message if 237 this comparison fails, which may be to reject the message. 239 3.2 Required Name Attributes 241 Receiving agents MUST support parsing of zero, one, or more instances of 242 each of the following set of name attributes within the Distinguished Names 243 in certificates. 245 Sending agents MUST include the Internet mail address during Distinguished 246 Name creation. Guidelines for the inclusion, omission, and ordering of the 247 remaining name attributes during the creation of a distinguished name will 248 most likely be dictated by the policies associated with the certification 249 service which will certify the corresponding name and public key. 251 CountryName 252 StateOrProvinceName 253 Locality 254 CommonName 255 Title 256 Organization 257 OrganizationalUnit 258 StreetAddress 259 PostalCode 260 PhoneNumber 261 EmailAddress 263 All attributes other than EmailAddress are described in X.520 [X.520]. 264 EmailAddress is an IA5String that can have multiple attribute values. 266 4. Certificate Processing 268 A receiving agent needs to provide some certificate retrieval mechanism in 269 order to gain access to certificates for recipients of digital envelopes. 270 There are many ways to implement certificate retrieval mechanisms. X.500 271 directory service is an excellent example of a certificate retrieval-only 272 mechanism that is compatible with classic X.500 Distinguished Names. The 273 PKIX Working Group is investigating other mechanisms. Another method under 274 consideration by the IETF is to provide certificate retrieval services as 275 part of the existing Domain Name System (DNS). Until such mechanisms are 276 widely used, their utility may be limited by the small number of 277 correspondent's certificates that can be retrieved. At a minimum, for 278 initial S/MIME deployment, a user agent could automatically generate a 279 message to an intended recipient requesting that recipient's certificate in 280 a signed return message. 282 Receiving and sending agents SHOULD also provide a mechanism to allow a 283 user to "store and protect" certificates for correspondents in such a way 284 so as to guarantee their later retrieval. In many environments, it may be 285 desirable to link the certificate retrieval/storage mechanisms together in 286 some sort of certificate database. In its simplest form, a certificate 287 database would be local to a particular user and would function in a 288 similar way as a "address book" that stores a user's frequent 289 correspondents. In this way, the certificate retrieval mechanism would be 290 limited to the certificates that a user has stored (presumably from 291 incoming messages). A comprehensive certificate retrieval/storage solution 292 may combine two or more mechanisms to allow the greatest flexibility and 293 utility to the user. For instance, a secure Internet mail agent may resort 294 to checking a centralized certificate retrieval mechanism for a certificate 295 if it can not be found in a user's local certificate storage/retrieval 296 database. 298 Receiving and sending agents SHOULD provide a mechanism for the import and 299 export of certificates, using a PKCS #7 certs-only message. This allows for 300 import and export of full certificate chains as opposed to just a single 301 certificate. This is described in [SMIME-MSG]. 303 4.1 Certificate Revocation Lists 305 A receiving agent SHOULD have access to some certificate-revocation list 306 (CRL) retrieval mechanism in order to gain access to certificate-revocation 307 information when validating certificate chains. A receiving or sending 308 agent SHOULD also provide a mechanism to allow a user to store incoming 309 certificate-revocation information for correspondents in such a way so as 310 to guarantee its later retrieval. However, it is always better to get the 311 latest information from the CA than to get information stored away from 312 incoming messages. 314 Receiving and sending agents SHOULD retrieve and utilize CRL information 315 every time a certificate is verified as part of a certificate chain 316 validation even if the certificate was already verified in the past. 317 However, in many instances (such as off-line verification) access to the 318 latest CRL information may be difficult or impossible. The use of CRL 319 information, therefore, may be dictated by the value of the information 320 that is protected. The value of the CRL information in a particular context 321 is beyond the scope of this draft but may be governed by the policies 322 associated with particular certificate hierarchies. 324 4.2 Certificate Chain Validation 326 In creating a user agent for secure messaging, certificate, CRL, and 327 certificate chain validation SHOULD be highly automated while still acting 328 in the best interests of the user. Certificate, CRL, and chain validation 329 MUST be performed when validating a correspondent's public key. This is 330 necessary when a) verifying a signature from a correspondent and, b) 331 creating a digital envelope with the correspondent as the intended 332 recipient. 334 Certificates and CRLs are made available to the chain validation procedure 335 in two ways: a) incoming messages, and b) certificate and CRL retrieval 336 mechanisms. Certificates and CRLs in incoming messages are not required to 337 be in any particular order nor are they required to be in any way related 338 to the sender or recipient of the message (although in most cases they will 339 be related to the sender). Incoming certificates and CRLs SHOULD be cached 340 for use in chain validation and optionally stored for later use. This 341 temporary certificate and CRL cache SHOULD be used to augment any other 342 certificate and CRL retrieval mechanisms for chain validation on incoming 343 signed messages. 345 4.3 Certificate and CRL Signing Algorithms 347 Certificates and Certificate-Revocation Lists (CRLs) are signed by the 348 certificate issuer. A receiving agent MUST be capable of verifying the 349 signatures on certificates andCRLs made with md5WithRSAEncryption and 350 sha-1WithRSAEncryption signature algorithms with key sizes from 512 bits to 351 2048 bits described in [SMIME-MSG].� A receiving agent SHOULD be capable of 352 verifying the signatures on certificates and CRLs made with the 353 md2WithRSAEncryption signature algorithm with key sizes from 512 bits to 354 2048 bits. 356 4.4 X.509 Version 3 Certificate Extensions 358 The X.509 v3 standard describes an extensible framework in which the basic 359 certificate information can be extended and how such extensions can be used 360 to control the process of issuing and validating certificates. The PKIX 361 Working Group has ongoing efforts to identify and create extensions which 362 have value in particular certification environments. As such, there is 363 still a fair amount of profiling work to be done before there is widespread 364 agreement on which v3 extensions will be used. Further, there are active 365 efforts underway to issue X.509 v3 certificates for business purposes. This 366 draft identifies the minumum required set of certificate extensions which 367 have the greatest value in the S/MIME environment. The basicConstraints, 368 and keyUsage extensions are defined in [X.509]. 370 Sending and receiving agents MUST correctly handle the v3 Basic Constraints 371 Certificate Extension, the Key Usage Certificate Extension, authorityKeyID, 372 subjectKeyID, and the subjectAltNames when they appear in end-user 373 certificates. Some mechanism SHOULD exist to handle the defined v3 374 certificate extensions when they appear in intermediate or CA certificates. 376 Certificates issued for the S/MIME environment SHOULD NOT contain any 377 critical extensions other than those listed here. These extensions SHOULD 378 be marked as non-critical unless the proper handling of the extension is 379 deemed critical to the correct interpretation of the associated 380 certificate. Other extensions may be included, but those extensions SHOULD 381 NOT be marked as critical. 383 4.4.1 Basic Constraints Certificate Extension 385 The basic constraints extension serves to delimit the role and position of 386 an issuing authority or end-user certificate plays in a chain of 387 certificates. 389 For example, certificates issued to CAs and subordinate CAs contain a basic 390 constraint extension that identifies them as issuing authority 391 certificates. End-user subscriber certificates contain an extension that 392 constrains the certificate from being an issuing authority certificate. 394 Certificates SHOULD contain a basicContstraints extension. 396 4.4.2 Key Usage Certificate Extension 398 The key usage extension serves to limit the technical purposes for which a 399 public key listed in a valid certificate may be used. Issuing authority 400 certificates may contain a key usage extension that restricts the key to 401 signing certificates, certificate revocation lists and other data. 403 For example, a certification authority may create subordinate issuer 404 certificates which contain a keyUsage extension which specifies that the 405 corresponding public key can be used to sign end user certs and sign CRLs. 407 5. Generating Keys and Certification Requests 409 5.1 Binding Names and Keys 411 An S/MIME agent or some related administrative utility or function MUST be 412 capable of generating a certification request given a user's public key and 413 associated name information. In most cases, the user's public key/private 414 key pair will be generated simultaneously. However, there are cases where 415 the keying information may be generated by an external process (such as 416 when a key pair is generated on a cryptographic token or by a "key 417 recovery" service). 419 There SHOULD NOT be multiple valid (that is, non-expired and non-revoked) 420 certificates for the same key pair bound to different Distinguished Names. 421 Otherwise, a security flaw exists where an attacker can substitute one 422 valid certificate for another in such a way that can not be detected by a 423 message recipient. If a users wishes to change their name (or create an 424 alternate name), the user agent SHOULD generate a new key pair. If the user 425 wishes to reuse an existing key pair with a new or alternate name, the user 426 SHOULD first have any valid certificates for the existing public key 427 revoked. 429 In general, it is possible for a user to request certification for the same 430 name and different public key from the same or different certification 431 authorities. This is acceptable both for end-entity and issuer 432 certificates and can be useful in supporting a change of issuer keys in a 433 smooth fashion. 435 CAs that re-use their own name with distinct keys MUST include the 436 AuthorityKeyIdentifier extension in certificates that they issue, and MUST 437 have the SubjectKeyIdentifier extension in their own certificate. CAs 438 SHOULD use these extensions uniformly. 440 Clients SHOULD handle multiple valid CA certificates that certify different 441 public keys but contain the same subject name (in this case, that CA's 442 name). 444 When selecting an appropriate issuer's certificate to use to verify a given 445 certificate, clients SHOULD process the AuthorityKeyIdentifier and 446 SubjectKeyIdentifier extensions. 448 5.2 Using PKCS #10 for Certification Requests 450 PKCS #10 is a flexible and extensible message format for representing the 451 results of cryptographic operations on some data. The choice of naming 452 information is largely dictated by the policies and procedures associated 453 with the intended certification service. 455 In addition to key and naming information, the PKCS #10 format supports the 456 inclusion of optional attributes, signed by the entity requesting 457 certification. This allows for information to be conveyed in a 458 certification request which may be useful to the request process, but not 459 necessarily part of the Distinguished Name being certified. 461 Receiving agents MUST support the identification of an RSA key with the rsa 462 defined in X.509 and the rsaEncryption OID. Certification authorities MUST 463 support sha-1WithRSAEncryption and md5WithRSAEncryption and SHOULD support 464 MD2WithRSAEncryption for verification of signatures on certificate requests 465 as described in [SMIME-MSG]. 467 For the creation and submission of certification-requests, RSA keys SHOULD 468 be identified with the rsaEncryption OID and signed with the 469 sha-1WithRSAEncryption signature algorithm.� Certification-requests MUST 470 NOT be signed with the md2WithRSAEncryption signature algorithm. 472 Certification requests MUST include a valid Internet mail address, either 473 as part of the certificate (as described in 3.2) or as part of the PKCS #10 474 attribute list. Certification authorities MUST check that the address in 475 the "From:" header matches either of these addresses. CAs SHOULD allow the 476 CA operator to configure processing of messages whose addresses do not 477 match. 479 Certification authorities SHOULD support parsing of zero or one instance of 480 each of the following set of certification-request attributes on incoming 481 messages. Attributes that a particular implementation does not support may 482 generate a warning message to the requestor, or may be silently ignored. 483 Inclusion of the following attributes during the creation and submission of 484 a certification-request will most likely be dictated by the policies 485 associated with the certification service which will certify the 486 corresponding name and public key. 488 postalAddress 489 challengePassword 490 unstructuredAddress 492 postalAddress is described in [X.520]. 494 5.2.1 Challenge Password 496 The challenge-password attribute type specifies a password by which an 497 entity may request certificate revocation. The interpretation of the 498 password is intended to be specified by the issuer of the certificate; no 499 particular interpretation is required. The challenge-password attribute 500 type is intended for PKCS #10 certification requests. 502 Challenge-password attribute values have ASN.1 type ChallengePassword: 504 ChallengePassword ::= CHOICE { 505 PrintableString, T61String } 507 A challenge-password attribute must have a single attribute value. 509 It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL STRING), 510 ChallengePassword will become a CHOICE type: 512 ChallengePassword ::= CHOICE { 513 PrintableString, T61String, UNIVERSAL STRING } 515 5.2.2 Unstructured Address 517 The unstructured-address attribute type specifies the address or addresses 518 of the subject of a certificate as an unstructured ASCII or T.61 string. 519 The interpretation of the addresses is intended to be specified by the 520 issuer of the certificate; no particular interpretation is required. A 521 likely interpretation is as an alternative to the X.520 postalAddress 522 attribute type. The unstructured-address attribute type is intended for 523 PKCS #10 certification requests. 525 Unstructured-address attribute values have ASN.1 type UnstructuredAddress: 527 UnstructuredAddress ::= CHOICE { 528 PrintableString, T61String } 530 An unstructured-address attribute can have multiple attribute values. 532 Note: T.61's newline character (hexadecimal code 0d) is recommended as a 533 line separator in multi-line addresses. 535 It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL STRING), 536 UnstructuredAddress will become a CHOICE type: 538 UnstructuredAddress ::= CHOICE { 539 PrintableString, T61String, UNIVERSAL STRING } 541 5.3 Fulfilling a Certification Request 543 Certification authorities SHOULD use the sha-1WithRSAEncryption 544 signature algorithms when signing certificates. 546 5.4 Using PKCS #7 for Fulfilled Certificate Response 548 [PKCS-7] supports a degenerate case of the SignedData content type where 549 there are no signers on the content (and hence, the content value is 550 "irrelevant"). This degenerate case is used to convey certificate and CRL 551 information. Certification authorities MUST use this format for returning 552 certificate information resulting from the successful fulfillment of a 553 certification request. At a minimum, the fulfilled certificate response 554 MUST include the actual subject certificate (corresponding to the 555 information in the certification request). The response SHOULD include 556 other certificates which link the issuer to higher level certification 557 authorities and corresponding certificate-revocation lists. Unrelated 558 certificates and revocation information is also acceptable. 560 Receiving agents MUST parse this degenerate PKCS #7 message type and handle 561 the certificates and CRLs according to the requirements and recommendations 562 in Section 4. 564 6. Security Considerations 566 All of the security issues faced by any cryptographic application must be 567 faced by a S/MIME agent. Among these issues are protecting the user's 568 private key, preventing various attacks, and helping the user avoid 569 mistakes such as inadvertently encrypting a message for the wrong 570 recipient. The entire list of security considerations is beyond the scope 571 of this document, but some significant concerns are listed here. 573 When processing certificates, there are many situations where the 574 processing might fail. Because the processing may be done by a user agent, 575 a security gateway, or other program, there is no single way to handle such 576 failures. Just because the methods to handle the failures has not been 577 listed, however, the reader should not assume that they are not important. 578 The opposite is true: if a certificate is not provably valid and associated 579 with the message, the processing software should take immediate and 580 noticable steps to inform the end user about it. 582 Some of the many places where signature and certificate checking might fail 583 include: 584 - no Internet mail addresses in a certificate match the sender of a message 585 - no certificate chain leads to a trusted CA 586 - no ability to check the CRL for a certificate 587 - an invalid CRL was received 588 - the CRL being checked is expired 589 - the certificate is expired 590 - the certificate has been revoked 591 There are certainly other instances where a certificate may be invalid, and 592 it is the responsibility of the processing software to check them all 593 thoroughly, and to decide what to do if the check fails. 595 A. Object Identifiers and Syntax 597 Sections A.1 through A.4 are adopted from [SMIME-MSG]. 599 A.5 Name Attributes 601 emailAddress OBJECT IDENTIFIER ::= 603 {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1} 605 CountryName OBJECT IDENTIFIER ::= 606 {joint-iso-ccitt(2) ds(5) attributeType(4) 6} 608 StateOrProvinceName OBJECT IDENTIFIER ::= 609 {joint-iso-ccitt(2) ds(5) attributeType(4) 8} 611 locality OBJECT IDENTIFIER ::= 612 {joint-iso-ccitt(2) ds(5) attributeType(4) 7} 614 CommonName OBJECT IDENTIFIER ::= 615 {joint-iso-ccitt(2) ds(5) attributeType(4) 3} 617 Title OBJECT IDENTIFIER ::= 618 {joint-iso-ccitt(2) ds(5) attributeType(4) 12} 620 Organization OBJECT IDENTIFIER ::= 621 {joint-iso-ccitt(2) ds(5) attributeType(4) 10} 623 OrganizationalUnit OBJECT IDENTIFIER ::= 624 {joint-iso-ccitt(2) ds(5) attributeType(4) 11} 626 StreetAddress OBJECT IDENTIFIER ::= 627 {joint-iso-ccitt(2) ds(5) attributeType(4) 9} 629 Postal Code OBJECT IDENTIFIER ::= 630 {joint-iso-ccitt(2) ds(5) attributeType(4) 17} 632 Phone Number OBJECT IDENTIFIER ::= 633 {joint-iso-ccitt(2) ds(5) attributeType(4) 20} 635 A.6 Certification Request Attributes 637 postalAddress OBJECT IDENTIFIER ::= 638 {joint-iso-ccitt(2) ds(5) attributeType(4) 16} 640 challengePassword OBJECT IDENTIFIER ::= 641 {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 7} 643 unstructuredAddress OBJECT IDENTIFIER ::= 644 {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 8} 646 A.7 X.509 V3 Certificate Extensions 648 basicConstraints OBJECT IDENTIFIER ::= 650 {joint-iso-ccitt(2) ds(5) 29 19 } 652 The ASN.1 definition of basicConstraints certificate extension is: 654 basicConstraints basicConstraints EXTENSION ::= { 655 SYNTAX BasicConstraintsSyntax 656 IDENTIFIED BY { id-ce 19 } } 658 BasicConstraintsSyntax ::= SEQUENCE { 659 cA BOOLEAN DEFAULT FALSE, 660 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 662 keyUsage OBJECT IDENTIFIER ::= 663 {joint-iso-ccitt(2) ds(5) 29 15 } 665 The ASN.1 definition of keyUsage certificate extension is: 667 keyUsage EXTENSION ::= { 668 SYNTAX KeyUsage 669 IDENTIFIED BY { id-ce 15 }} 671 KeyUsage ::= BIT STRING { 672 digitalSignature (0), 673 nonRepudiation (1), 674 keyEncipherment (2), 675 dataEncipherment (3), 676 keyAgreement (4), 677 keyCertSign (5), 678 cRLSign (6)} 680 B. References 682 [KEYM] PKIX Part 1. At the time of this writing, PKIX is in Internet Draft 683 stage, but it is expected that there will be standards-track RFCs at some 684 point in the future. 686 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement Levels", 687 RFC 2119 689 [PKCS-1], "PKCS #1: RSA Encryption", draft has been submitted for RFC 690 status 692 [PKCS-7], "PKCS #7: Cryptographic Message Syntax", draft has been submitted 693 for RFC status 695 [PKCS-10], "PKCS #10: Certification Request Syntax", draft has been 696 submitted for RFC status 698 [RFC-822], "Standard For The Format Of ARPA Internet Text Messages", RFC 699 822. 701 [SMIME-MSG] "S/MIME Message Specification", Internet Draft 702 draft-dusse-smime-msg-xx. 704 [X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997, 705 Information technology - Open Systems Interconnection - The Directory: 706 Overview of concepts, models and services 708 [X.501] ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1997, 709 Information technology - Open Systems Interconnection - The Directory: 710 Models 712 [X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997, 713 Information technology - Open Systems Interconnection - The Directory: 714 Authentication framework 716 [X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997, 717 Information technology - Open Systems Interconnection - The Directory: 718 Selected attribute types. 720 C. Compatibility with Prior Practice in S/MIME 722 S/MIME was originally developed by RSA Data Security, Inc. Many developers 723 implemented S/MIME agents before this document was published. All S/MIME 724 receiving agents SHOULD make every attempt to interoperate with these 725 earlier implementations of S/MIME. 727 D. Revision History 729 The following changes were made between the -04 and -05 revisions of this 730 draft: 732 There was general agreement that this draft should reflect reality of 733 S/MIME v2 implementations and not what "should be", which is left to S/MIME 734 v3. The changes listed here are to bring this draft back to what is being 735 deployed today. 737 Changed the end of 2.3 to only require DN chaining. 739 Changed the MUST to SHOULD for MD2 hashing in 4.3 and 5.2. 741 Made the "certificates" in 2.2 "end entity" certificates. 743 Removed certificatePolicies from 4.4. 745 In 5.1, changed "Clients MUST handle multiple valid CA certificates" to 746 "Clients SHOULD...". 748 In 5.2, changed the MUST to SHOULD for the certification-request 749 attributes. 751 In 3.2, changed the SHOULD to MUS for including the email address during DN 752 creation. Added text in 5.2 to support this. 754 E. Acknowledgements 756 Significant contributions to the content of this draft were made by many 757 people, including David Solo, Anil Gangolli, Jeff Thompson, and Lisa Repka. 759 F. Authors' addresses 761 Steve Dusse 762 RSA Data Security, Inc. 763 100 Marine Parkway, #500 764 Redwood City, CA 94065 USA 765 (415) 595-8782 766 spock@rsa.com 768 Paul Hoffman 769 Internet Mail Consortium 770 127 Segre Place 771 Santa Cruz, CA 95060 772 (408) 426-9827 773 phoffman@imc.org 775 Blake Ramsdell 776 Worldtalk 777 13122 NE 20th St., Suite C 778 Bellevue, WA 98005 779 (425) 882-8861 780 blaker@deming.com 782 Jeff Weinstein 783 Netscape Communications Corporation 784 501 East Middlefield Road 785 Mountain View, CA 94043 786 (415) 254-1900 787 jsw@netscape.com