idnits 2.17.1 draft-ietf-smime-cert-00.txt: 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-25) 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 833 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.) ** 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 81: '...draft, the terms MUST, MUST NOT, SHOUL...' RFC 2119 keyword, line 108: '...Receiving agents MUST support for the ...' RFC 2119 keyword, line 110: '...outgoing 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...' (61 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 20, 1997) is 9653 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? 'SMIME-MSG' on line 758 looks like a reference -- Missing reference section? 'CMS' on line 760 looks like a reference -- Missing reference section? 'PKCS-1' on line 719 looks like a reference -- Missing reference section? 'PKCS-10' on line 722 looks like a reference -- Missing reference section? 'KEYM' on line 712 looks like a reference -- Missing reference section? 'MUSTSHOULD' on line 716 looks like a reference -- Missing reference section? 'RFC-822' on line 725 looks like a reference -- Missing reference section? 'CERTV2' on line 768 looks like a reference -- Missing reference section? 'PKCS-7' on line 759 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Editor: Blake Ramsdell, 2 draft-ietf-smime-cert-00.txt Worldtalk 3 November 20, 1997 4 Expires in six months 6 S/MIME Version 3 Certificate Handling 8 Status of this memo 10 This document is an Internet-Draft. Internet-Drafts are working 11 documents of the Internet Engineering Task Force (IETF), its areas, 12 and its working groups. Note that other groups may also distribute 13 working documents as Internet-Drafts. 15 Internet-Drafts are draft documents valid for a maximum of six months 16 and may be updated, replaced, or obsoleted by other documents at any 17 time. It is inappropriate to use Internet-Drafts as reference material 18 or to cite them other than as "work in progress." 20 To learn the current status of any Internet-Draft, please check the 21 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 22 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 23 munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or 24 ftp.isi.edu (US West Coast). 26 1. Overview 28 S/MIME (Secure/Multipurpose Internet Mail Extensions), described in 29 [SMIME-MSG], provides a method to send and receive secure MIME 30 messages. In order to validate the keys of a message sent to it, an 31 S/MIME agent needs to certify that the key is valid. This draft 32 describes the mechanisms S/MIME uses to create and validate keys using 33 certificates. 35 This specification is compatible with the Cryptographic Message Syntax 36 [CMS] in that it uses the data types defined by CMS. It also inherits 37 all the varieties of architectures for certificate-based key 38 management supported by CMS. Note that the method S/MIME messages make 39 certificate requests is defined in [SMIME-MSG]. 41 In order to handle S/MIME certificates, an agent has to follow 42 specifications in this draft, as well as some of the specifications 43 listed in the following documents: 44 - ''PKCS #1: RSA Encryption'', [PKCS-1]. 45 - ''Cryptographic Message Syntax'', [CMS]. 46 - ''PKCS #10: Certification Request Syntax'', [PKCS-10]. 48 1.1 Definitions 50 For the purposes of this draft, the following definitions apply. 52 ASN.1: Abstract Syntax Notation One, as defined in CCITT X.680-689. 54 BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.690. 56 Certificate: A type that binds an entity's distinguished name to a 57 public key with a digital signature. This type is defined in CCITT 58 X.509 [X.509]. This type also contains the distinguished name of the 59 certificate issuer (the signer), an issuer-specific serial number, the 60 issuer's signature algorithm identifier, and a validity period. 62 Certificate Revocation List (CRL): A type that contains information 63 about certificates whose validity an issuer has prematurely revoked. 64 The information consists of an issuer name, the time of issue, the 65 next scheduled time of issue, and a list of certificate serial numbers 66 and their associated revocation times. The CRL is signed by the 67 issuer. The type intended by this specification is the one defined in 68 [KEYM]. 70 DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT 71 X.690. 73 1.2 Compatibility with Prior Practice of S/MIME 75 Appendix C contains important information about how S/MIME agents 76 following this specification should act in order to have the greatest 77 interoperability with earlier implementations of S/MIME. 79 1.3 Terminology 81 Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD 82 NOT are used in capital letters. This conforms to the definitions in 83 [MUSTSHOULD]. [MUSTSHOULD] defines the use of these key words to help 84 make the intent of standards track documents as clear as possible. The 85 same key words are used in this document to help implementors achieve 86 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. CMS Options 100 The CMS 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 CMS 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 109 (CRL) format defined in [KEYM]. If sending agents include CRLs in 110 outgoing 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 115 time is later than the nextUpdate time, the action that the agent 116 takes is a local decision. For instance, it could warn a human user, 117 it could 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 123 that message. Clients SHOULD store CRLs received in messages for use 124 in processing later messages. 126 Clients MUST handle multiple valid Certificate Authority (CA) 127 certificates containing the same subject name and the same public keys 128 but with overlapping validity intervals. 130 2.2 CertificateChoices 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 134 entity certificates MUST include an Internet mail address, as 135 described in section 3.1. 137 2.2.1 Historical Note About CMS Certificates 139 The CMS message format supports a choice of certificate two formats 140 for public key content types: X.509 and PKCS #6 Extended Certificates. 141 The PKCS #6 format is not in widespread use. In addition, proposed 142 revisions of X.509 certificates address much of the same functionality 143 and flexibility as was intended in the PKCS #6. Thus, sending and 144 receiving agents MUST NOT use PKCS #6 extended certificates. 146 2.3 CertificateSet 148 Receiving agents MUST be able to handle an arbitrary number of 149 certificates of arbitrary relationship to the message sender and to 150 each other in arbitrary order. In many cases, the certificates 151 included in a signed message may represent a chain of certification 152 from the sender to a particular root. There may be, however, 153 situations where the certificates in a signed message may be unrelated 154 and included for convenience. 156 Sending agents SHOULD include any certificates for the user's public 157 key(s) and associated issuer certificates. This increases the 158 likelihood that the intended recipient can establish trust in the 159 originator's public key(s). This is especially important when sending 160 a message to recipients that may not have access to the sender's 161 public key through any other means or when sending a signed message to 162 a new recipient. The inclusion of certificates in outgoing messages 163 can be omitted if S/MIME objects are sent within a group of 164 correspondents that has established access to each other's 165 certificates by some other means such as a shared directory or manual 166 certificate distribution. Receiving S/MIME agents SHOULD be able to 167 handle messages without certificates using a database or directory 168 lookup scheme. 170 A sending agent SHOULD include at least one chain of certificates up 171 to, but not including, a Certificate Authority (CA) that it believes 172 that the recipient may trust as authoritative. A receiving agent 173 SHOULD be able to handle an arbitrarily large number of certificates 174 and chains. 176 Clients MAY send CA certificates, that is, certificates that are self- 177 signed and can be considered the "root" of other chains. Note that 178 receiving agents SHOULD NOT simply trust any self-signed certificates 179 as valid CAs, but SHOULD use some other mechanism to determine if this 180 is a CA that should be trusted. 182 Receiving agents MUST support chaining based on the distinguished name 183 fields. Other methods of building certificate chains may be supported 184 but are not currently recommended. 186 3. Distinguished Names in Certificates 188 3.1 Using Distinguished Names for Internet Mail 190 The format of an X.509 certificate includes fields for the subject 191 name and issuer name. The subject name identifies the owner of a 192 particular public key/private key pair while the issuer name is meant 193 to identify the entity that "certified" the subject (that is, who 194 signed the subject's certificate). The subject name and issuer name 195 are defined by X.509 as Distinguished Names. 197 Distinguished Names are defined by a CCITT standard X.501 [X.501]. A 198 Distinguished Name is broken into one or more Relative Distinguished 199 Names. Each Relative Distinguished Name is comprised of one or more 200 Attribute-Value Assertions. Each Attribute-Value Assertion consists of 201 a Attribute Identifier and its corresponding value information, such 202 as CountryName=US. Distinguished Names were intended to identify 203 entities in the X.500 directory tree [X.500]. Each Relative 204 Distinguished Name can be thought of as a node in the tree which is 205 described by some collection of Attribute-Value Assertions. The entire 206 Distinguished Name is some collection of nodes in the tree that 207 traverse a path from the root of the tree to some end node which 208 represents a particular entity. 210 The goal of the directory was to provide an infrastructure to uniquely 211 name every communications entity everywhere. However, adoption of a 212 global X.500 directory infrastructure has been slower than expected. 213 Consequently, there is no requirement for X.500 directory service 214 provision in the S/MIME environment, although such provision would 215 almost undoubtedly be of great value in facilitating key management 216 for S/MIME. 218 The use of Distinguished Names in accordance with the X.500 directory 219 is not very widespread. By contrast, Internet mail addresses, as 220 described in RFC 822 [RFC-822], are used almost exclusively in the 221 Internet environment to identify originators and recipients of 222 messages. However, Internet mail addresses bear no resemblance to 223 X.500 Distinguished Names (except, perhaps, that they are both 224 hierarchical in nature). Some method is needed to map Internet mail 225 addresses to entities that hold public keys. Some people have 226 suggested that the X.509 certificate format should be abandoned in 227 favor of other binding mechanisms. Instead, S/MIME keeps the X.509 228 certificate and Distinguished Name mechanisms while tailoring the 229 content of the naming information to suit the Internet mail 230 environment. 232 End-entity certificates MUST contain an Internet mail address as 233 described in [RFC-822]. The address must be an "addr-spec" as defined 234 in Section 6.1 of that specification. 236 Receiving agents MUST recognize email addresses in the subjectAltName 237 field. Receiving agents MUST recognize email addresses in the 238 Distinguished Name field. 240 Sending agents SHOULD make the address in the From header in a mail 241 message match an Internet mail address in the signer's certificate. 242 Receiving agents MUST check that the address in the From header of a 243 mail message matches an Internet mail address in the signer's 244 certificate. A receiving agent MUST provide some explicit alternate 245 processing of the message if this comparison fails, which may be to 246 reject the message. 248 3.2 Required Name Attributes 250 Receiving agents MUST support parsing of zero, one, or more instances 251 of each of the following set of name attributes within the 252 Distinguished Names in certificates. 254 Sending agents MUST include the Internet mail address during 255 Distinguished Name creation. Guidelines for the inclusion, omission, 256 and ordering of the remaining name attributes during the creation of a 257 distinguished name will most likely be dictated by the policies 258 associated with the certification service which will certify the 259 corresponding name and public key. 261 CountryName 262 StateOrProvinceName 263 Locality 264 CommonName 265 Title 266 Organization 267 OrganizationalUnit 268 StreetAddress 269 PostalCode 270 PhoneNumber 271 EmailAddress 273 All attributes other than EmailAddress are described in X.520 [X.520]. 274 EmailAddress is an IA5String that can have multiple attribute values. 276 4. Certificate Processing 278 A receiving agent needs to provide some certificate retrieval 279 mechanism in order to gain access to certificates for recipients of 280 digital envelopes. There are many ways to implement certificate 281 retrieval mechanisms. X.500 directory service is an excellent example 282 of a certificate retrieval-only mechanism that is compatible with 283 classic X.500 Distinguished Names. The PKIX Working Group is 284 investigating other mechanisms. Another method under consideration by 285 the IETF is to provide certificate retrieval services as part of the 286 existing Domain Name System (DNS). Until such mechanisms are widely 287 used, their utility may be limited by the small number of 288 correspondent's certificates that can be retrieved. At a minimum, for 289 initial S/MIME deployment, a user agent could automatically generate a 290 message to an intended recipient requesting that recipient's 291 certificate in a signed return message. 293 Receiving and sending agents SHOULD also provide a mechanism to allow 294 a user to "store and protect" certificates for correspondents in such 295 a way so as to guarantee their later retrieval. In many environments, 296 it may be desirable to link the certificate retrieval/storage 297 mechanisms together in some sort of certificate database. In its 298 simplest form, a certificate database would be local to a particular 299 user and would function in a similar way as a "address book" that 300 stores a user's frequent correspondents. In this way, the certificate 301 retrieval mechanism would be limited to the certificates that a user 302 has stored (presumably from incoming messages). A comprehensive 303 certificate retrieval/storage solution may combine two or more 304 mechanisms to allow the greatest flexibility and utility to the user. 305 For instance, a secure Internet mail agent may resort 306 to checking a centralized certificate retrieval mechanism for a 307 certificate if it can not be found in a user's local certificate 308 storage/retrieval database. 310 Receiving and sending agents SHOULD provide a mechanism for the import 311 and export of certificates, using a PKCS #7 certs-only message. This 312 allows for import and export of full certificate chains as opposed to 313 just a single certificate. This is described in [SMIME-MSG]. 315 4.1 Certificate Revocation Lists 317 A receiving agent SHOULD have access to some certificate-revocation 318 list (CRL) retrieval mechanism in order to gain access to certificate- 319 revocation information when validating certificate chains. A receiving 320 or sending agent SHOULD also provide a mechanism to allow a user to 321 store incoming certificate-revocation information for correspondents 322 in such a way so as to guarantee its later retrieval. However, it is 323 always better to get the latest information from the CA than to get 324 information stored away from incoming messages. 326 Receiving and sending agents SHOULD retrieve and utilize CRL 327 information every time a certificate is verified as part of a 328 certificate chain validation even if the certificate was already 329 verified in the past. However, in many instances (such as off-line 330 verification) access to the latest CRL information may be difficult or 331 impossible. The use of CRL information, therefore, may be dictated by 332 the value of the information that is protected. The value of the CRL 333 information in a particular context is beyond the scope of this draft 334 but may be governed by the policies associated with particular 335 certificate hierarchies. 337 4.2 Certificate Chain Validation 339 In creating a user agent for secure messaging, certificate, CRL, and 340 certificate chain validation SHOULD be highly automated while still 341 acting in the best interests of the user. Certificate, CRL, and chain 342 validation MUST be performed when validating a correspondent's public 343 key. This is necessary when a) verifying a signature from a 344 correspondent and, b) creating a digital envelope with the 345 correspondent as the intended recipient. 347 Certificates and CRLs are made available to the chain validation 348 procedure in two ways: a) incoming messages, and b) certificate and 349 CRL retrieval mechanisms. Certificates and CRLs in incoming messages 350 are not required to be in any particular order nor are they required 351 to be in any way related to the sender or recipient of the message 352 (although in most cases they will be related to the sender). Incoming 353 certificates and CRLs SHOULD be cached for use in chain validation and 354 optionally stored for later use. This temporary certificate and CRL 355 cache SHOULD be used to augment any other certificate and CRL 356 retrieval mechanisms for chain validation on incoming signed messages. 358 4.3 Certificate and CRL Signing Algorithms 360 Certificates and Certificate-Revocation Lists (CRLs) are signed by the 361 certificate issuer. A receiving agent MUST be capable of verifying the 362 signatures on certificates and CRLs made with id-dsa-with-sha1. 364 A receiving agent SHOULD be capable of verifying the signatures on 365 certificates and CRLs made with md2WithRSAEncryption, 366 md5WithRSAEncryption and sha-1WithRSAEncryption signature algorithms 367 with key sizes from 512 bits to 2048 bits described in [SMIME-MSG]. 369 4.4 X.509 Version 3 Certificate Extensions 371 The X.509 v3 standard describes an extensible framework in which the 372 basic certificate information can be extended and how such extensions 373 can be used to control the process of issuing and validating 374 certificates. The PKIX Working Group has ongoing efforts to identify 375 and create extensions which have value in particular certification 376 environments. As such, there is 377 still a fair amount of profiling work to be done before there is 378 widespread agreement on which v3 extensions will be used. Further, 379 there are active efforts underway to issue X.509 v3 certificates for 380 business purposes. This draft identifies the minumum required set of 381 certificate extensions which have the greatest value in the S/MIME 382 environment. The basicConstraints, and keyUsage extensions are defined 383 in [X.509]. 385 Sending and receiving agents MUST correctly handle the v3 Basic 386 Constraints Certificate Extension, the Key Usage Certificate 387 Extension, authorityKeyID, subjectKeyID, and the subjectAltNames when 388 they appear in end-user certificates. Some mechanism SHOULD exist to 389 handle the defined v3 certificate extensions when they appear in 390 intermediate or CA certificates. 392 Certificates issued for the S/MIME environment SHOULD NOT contain any 393 critical extensions other than those listed here. These extensions 394 SHOULD be marked as non-critical unless the proper handling of the 395 extension is deemed critical to the correct interpretation of the 396 associated certificate. Other extensions may be included, but those 397 extensions SHOULD NOT be marked as critical. 399 4.4.1 Basic Constraints Certificate Extension 401 The basic constraints extension serves to delimit the role and 402 position of an issuing authority or end-user certificate plays in a 403 chain of certificates. 405 For example, certificates issued to CAs and subordinate CAs contain a 406 basic constraint extension that identifies them as issuing authority 407 certificates. End-user subscriber certificates contain an extension 408 that constrains the certificate from being an issuing authority 409 certificate. 411 Certificates SHOULD contain a basicContstraints extension. 413 4.4.2 Key Usage Certificate Extension 415 The key usage extension serves to limit the technical purposes for 416 which a public key listed in a valid certificate may be used. Issuing 417 authority certificates may contain a key usage extension that 418 restricts the key to signing certificates, certificate revocation 419 lists and other data. 421 For example, a certification authority may create subordinate issuer 422 certificates which contain a keyUsage extension which specifies that 424 he corresponding public key can be used to sign end user certs and 425 sign CRLs. 427 5. Generating Keys and Certification Requests 429 5.1 Binding Names and Keys 431 An S/MIME agent or some related administrative utility or function 432 MUST be capable of generating a certification request given a user's 433 public key and associated name information. In most cases, the user's 434 public key/private key pair will be generated simultaneously. However, 435 there are cases where the keying information may be generated by an 436 external process (such as when a key pair is generated on a 437 cryptographic token or by a "key recovery" service). 439 There SHOULD NOT be multiple valid (that is, non-expired and non- 440 revoked) certificates for the same key pair bound to different 441 Distinguished Names. Otherwise, a security flaw exists where an 442 attacker can substitute one valid certificate for another in such a 443 way that can not be detected by a message recipient. If a users wishes 444 to change their name (or create an alternate name), the user agent 445 SHOULD generate a new key pair. If the user wishes to reuse an 446 existing key pair with a new or alternate name, the user SHOULD first 447 have any valid certificates for the existing public key revoked. 449 In general, it is possible for a user to request certification for the 450 same name and different public key from the same or different 451 certification authorities. This is acceptable both for end-entity and 452 issuer certificates and can be useful in supporting a change of issuer 453 keys in a smooth fashion. 455 CAs that re-use their own name with distinct keys MUST include the 456 AuthorityKeyIdentifier extension in certificates that they issue, and 457 MUST have the SubjectKeyIdentifier extension in their own certificate. 458 CAs SHOULD use these extensions uniformly. 460 Clients SHOULD handle multiple valid CA certificates that certify 461 different public keys but contain the same subject name (in this case, 462 that CA's name). 464 When selecting an appropriate issuer's certificate to use to verify a 465 given certificate, clients SHOULD process the AuthorityKeyIdentifier 466 and SubjectKeyIdentifier extensions. 468 5.2 Using PKCS #10 for Certification Requests 470 PKCS #10 is a flexible and extensible message format for representing 471 the results of cryptographic operations on some data. The choice of 472 naming information is largely dictated by the policies and procedures 473 associated with the intended certification service. 475 In addition to key and naming information, the PKCS #10 format 476 supports the inclusion of optional attributes, signed by the entity 477 requesting certification. This allows for information to be conveyed 478 in a certification request which may be useful to the request process, 479 but not necessarily part of the Distinguished Name being certified. 481 Receiving agents MUST support the identification of an RSA key with 482 the rsa defined in X.509 and the rsaEncryption OID. Certification 483 authorities MUST support sha-1WithRSAEncryption and 484 md5WithRSAEncryption and SHOULD support md2WithRSAEncryption for 485 verification of signatures on certificate requests as described in 486 [SMIME-MSG]. 488 For the creation and submission of certification-requests, RSA keys 489 SHOULD be identified with the rsaEncryption OID and signed with the 490 sha-1WithRSAEncryption signature algorithm. Certification-requests 491 MUST NOT be signed with the md2WithRSAEncryption signature algorithm. 493 Certification requests MUST include a valid Internet mail address, 494 either as part of the certificate (as described in 3.2) or as part of 495 the PKCS #10 attribute list. Certification authorities MUST check that 496 the address in the "From:" header matches either of these addresses. 497 CAs SHOULD allow the CA operator to configure processing of messages 498 whose addresses do not match. 500 Certification authorities SHOULD support parsing of zero or one 501 instance of each of the following set of certification-request 502 attributes on incoming messages. Attributes that a particular 503 implementation does not support may generate a warning message to the 504 requestor, or may be silently ignored. Inclusion of the following 505 attributes during the creation and submission of a certification- 506 request will most likely be dictated by the policies associated with 507 the certification service which will certify the corresponding name 508 and public key. 510 postalAddress 511 challengePassword 512 unstructuredAddress 514 postalAddress is described in [X.520]. 516 5.2.1 Challenge Password 518 The challenge-password attribute type specifies a password by which an 519 entity may request certificate revocation. The interpretation of the 520 password is intended to be specified by the issuer of the certificate; 521 no particular interpretation is required. The challenge-password 522 attribute type is intended for PKCS #10 certification requests. 524 Challenge-password attribute values have ASN.1 type ChallengePassword: 526 ChallengePassword ::= CHOICE { 527 PrintableString, T61String } 529 A challenge-password attribute must have a single attribute value. 531 It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL 532 STRING), ChallengePassword will become a CHOICE type: 534 ChallengePassword ::= CHOICE { 535 PrintableString, T61String, UNIVERSAL STRING } 537 5.2.2 Unstructured Address 539 The unstructured-address attribute type specifies the address or 540 addresses of the subject of a certificate as an unstructured ASCII or 541 T.61 string. The interpretation of the addresses is intended to be 542 specified by the issuer of the certificate; no particular 543 interpretation is required. A likely interpretation is as an 544 alternative to the X.520 postalAddress attribute type. The 545 unstructured-address attribute type is intended for PKCS #10 546 certification requests. 548 Unstructured-address attribute values have ASN.1 type 549 UnstructuredAddress: 551 UnstructuredAddress ::= CHOICE { 552 PrintableString, T61String } 554 An unstructured-address attribute can have multiple attribute values. 556 Note: T.61's newline character (hexadecimal code 0d) is recommended as 557 a line separator in multi-line addresses. 559 It is expected that if UCS becomes an ASN.1 type (e.g., UNIVERSAL 560 STRING), UnstructuredAddress will become a CHOICE type: 562 UnstructuredAddress ::= CHOICE { 563 PrintableString, T61String, UNIVERSAL STRING } 565 5.3 Fulfilling a Certification Request 567 Certification authorities SHOULD use the sha-1WithRSAEncryption 568 signature algorithms when signing certificates. 570 5.4 Using CMS for Fulfilled Certificate Response 572 [CMS] supports a degenerate case of the SignedData content type where 573 there are no signers on the content (and hence, the content value is 574 "irrelevant"). This degenerate case is used to convey certificate and 575 CRL information. Certification authorities MUST use this format for 576 returning certificate information resulting from the successful 577 fulfillment of a certification request. At a minimum, the fulfilled 578 certificate response MUST include the actual subject certificate 579 (corresponding to the information in the certification request). The 580 response SHOULD include other certificates which link the issuer to 581 higher level certification authorities and corresponding certificate- 582 revocation lists. Unrelated certificates and revocation information is 583 also acceptable. 585 Receiving agents MUST parse this degenerate CMS message type and 586 handle the certificates and CRLs according to the requirements and 587 recommendations in Section 4. 589 6. Security Considerations 591 All of the security issues faced by any cryptographic application must 592 be faced by a S/MIME agent. Among these issues are protecting the 593 user's private key, preventing various attacks, and helping the user 594 avoid mistakes such as inadvertently encrypting a message for the 595 wrong recipient. The entire list of security considerations is beyond 596 the scope of this document, but some significant concerns are listed 597 here. 599 When processing certificates, there are many situations where the 600 processing might fail. Because the processing may be done by a user 601 agent, a security gateway, or other program, there is no single way to 602 handle such failures. Just because the methods to handle the failures 603 has not been listed, however, the reader should not assume that they 604 are not important. The opposite is true: if a certificate is not 605 provably valid and associated with the message, the processing 606 software should take immediate and noticable steps to inform the end 607 user about it. 609 Some of the many places where signature and certificate checking might 610 fail include: 611 - no Internet mail addresses in a certificate match the sender of a 612 message 613 - no certificate chain leads to a trusted CA 614 - no ability to check the CRL for a certificate 615 - an invalid CRL was received 616 - the CRL being checked is expired 617 - the certificate is expired 618 - the certificate has been revoked 619 There are certainly other instances where a certificate may be 620 invalid, and it is the responsibility of the processing software to 621 check them all thoroughly, and to decide what to do if the check 622 fails. 624 A. Object Identifiers and Syntax 626 Sections A.1 through A.4 are adopted from [SMIME-MSG]. 628 A.5 Name Attributes 630 emailAddress OBJECT IDENTIFIER ::= 631 {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1} 633 CountryName OBJECT IDENTIFIER ::= 634 {joint-iso-ccitt(2) ds(5) attributeType(4) 6} 636 StateOrProvinceName OBJECT IDENTIFIER ::= 637 {joint-iso-ccitt(2) ds(5) attributeType(4) 8} 639 locality OBJECT IDENTIFIER ::= 640 {joint-iso-ccitt(2) ds(5) attributeType(4) 7} 642 CommonName OBJECT IDENTIFIER ::= 643 {joint-iso-ccitt(2) ds(5) attributeType(4) 3} 645 Title OBJECT IDENTIFIER ::= 646 {joint-iso-ccitt(2) ds(5) attributeType(4) 12} 648 Organization OBJECT IDENTIFIER ::= 649 {joint-iso-ccitt(2) ds(5) attributeType(4) 10} 651 OrganizationalUnit OBJECT IDENTIFIER ::= 652 {joint-iso-ccitt(2) ds(5) attributeType(4) 11} 654 StreetAddress OBJECT IDENTIFIER ::= 655 {joint-iso-ccitt(2) ds(5) attributeType(4) 9} 657 Postal Code OBJECT IDENTIFIER ::= 658 {joint-iso-ccitt(2) ds(5) attributeType(4) 17} 660 Phone Number OBJECT IDENTIFIER ::= 661 {joint-iso-ccitt(2) ds(5) attributeType(4) 20} 663 A.6 Certification Request Attributes 665 postalAddress OBJECT IDENTIFIER ::= 666 {joint-iso-ccitt(2) ds(5) attributeType(4) 16} 668 challengePassword OBJECT IDENTIFIER ::= 669 {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 7} 671 unstructuredAddress OBJECT IDENTIFIER ::= 672 {iso(1) member-body(2) US(840) rsadsi(113549) pkcs(1) pkcs-9(9) 8} 674 A.7 X.509 V3 Certificate Extensions 676 basicConstraints OBJECT IDENTIFIER ::= 677 {joint-iso-ccitt(2) ds(5) 29 19 } 679 The ASN.1 definition of basicConstraints certificate extension is: 681 basicConstraints basicConstraints EXTENSION ::= { 682 SYNTAX BasicConstraintsSyntax 683 IDENTIFIED BY { id-ce 19 } } 685 BasicConstraintsSyntax ::= SEQUENCE { 686 cA BOOLEAN DEFAULT FALSE, 687 pathLenConstraint INTEGER (0..MAX) OPTIONAL } 689 keyUsage OBJECT IDENTIFIER ::= 690 {joint-iso-ccitt(2) ds(5) 29 15 } 692 The ASN.1 definition of keyUsage certificate extension is: 694 keyUsage EXTENSION ::= { 695 SYNTAX KeyUsage 696 IDENTIFIED BY { id-ce 15 }} 698 KeyUsage ::= BIT STRING { 699 digitalSignature (0), 700 nonRepudiation (1), 701 keyEncipherment (2), 702 dataEncipherment (3), 703 keyAgreement (4), 704 keyCertSign (5), 705 cRLSign (6)} 707 B. References 709 [CERTV2] "S/MIME Certificate Handling", Internet Draft draft-dusse- 710 smime-cert 712 [KEYM] PKIX Part 1. At the time of this writing, PKIX is in Internet 713 Draft stage, but it is expected that there will be standards-track 714 RFCs at some point in the future. 716 [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement 717 Levels", RFC 2119 719 [PKCS-1], "PKCS #1: RSA Encryption", draft has been submitted for RFC 720 status 722 [PKCS-10], "PKCS #10: Certification Request Syntax", draft has been 723 submitted for RFC status 725 [RFC-822], "Standard For The Format Of ARPA Internet Text Messages", 726 RFC 822. 728 [SMIME-MSG] "S/MIME Version 3 Message Specification ", Internet Draft 729 draft-ietf-smime-msg 731 [X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997, 732 Information technology - Open Systems Interconnection - The Directory: 733 Overview of concepts, models and services 735 [X.501] ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-2:1997, 736 Information technology - Open Systems Interconnection - The Directory: 737 Models 739 [X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997, 740 Information technology - Open Systems Interconnection - The Directory: 741 Authentication framework 743 [X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997, 744 Information technology - Open Systems Interconnection - The Directory: 745 Selected attribute types. 747 C. Compatibility with Prior Practice in S/MIME 749 S/MIME was originally developed by RSA Data Security, Inc. Many 750 developers implemented S/MIME agents before this document was 751 published. All S/MIME receiving agents SHOULD make every attempt to 752 interoperate with these earlier implementations of S/MIME. 754 D. Changes from S/MIME v2 756 Reworded section 4.3 for signing algorithms to MUST id-dsa-with-sha1 757 and SHOULD all others 758 Changed [SMIME-MSG] to draft-ietf-smime-msg 759 Changed references to PKCS #7 and [PKCS-7] to Cryptographic Message 760 Specification and [CMS] 761 Section 2.2 is now "CertificateChoices" instead of 762 "ExtendedCertificatesOrCertificate" 763 Section 2.3 is now "CertificateSet" instead of 764 "ExtendedCertificatesAndCertificates" 766 E. Acknowledgements 768 This document is largely based on [CERTV2] written by Steve Dusse, 769 Paul Hoffman, Blake Ramsdell, and Jeff Weinstein. 771 F. Needed changes 773 UNIVERSAL STRING for Challenge Password? Should this simply be 774 BMPString? 775 Algorithms for certs 776 Capitalization of OIDs 777 Stronger MD2 / MD5 language needed? 778 Names for chaining 779 Only one "official" email address? 780 Rewrite 5.2 for CMP and id-dsa-with-sha1 781 Make references [PKCS-*] consistent with smime-msg spec 782 2.2.1 -- are they "proposed" revisions, or actual revisions? 783 Attribute certificates? 785 G. Editor's address 787 Blake Ramsdell 788 Worldtalk 789 13122 NE 20th St., Suite C 790 Bellevue, WA 98005 791 (425) 882-8861 792 blaker@deming.com