idnits 2.17.1 draft-schaad-lamps-rfc5750-bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. 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.) -- The abstract seems to indicate that this document obsoletes RFC3850, but the header doesn't have an 'Obsoletes:' line to match this. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 22, 2016) is 2835 days in the past. Is this intentional? -- 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) == Unused Reference: 'RFC2314' is defined on line 932, but no explicit reference was found in the text == Unused Reference: 'RFC2315' is defined on line 889, but no explicit reference was found in the text == Unused Reference: 'RFC2633' is defined on line 938, but no explicit reference was found in the text == Unused Reference: 'RFC3852' is defined on line 945, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-2' -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS186-3' ** Downref: Normative reference to an Informational RFC: RFC 2985 ** Obsolete normative reference: RFC 3447 (Obsoleted by RFC 8017) ** Obsolete normative reference: RFC 5751 (Obsoleted by RFC 8551) -- Obsolete informational reference (is this intentional?): RFC 2313 (Obsoleted by RFC 2437) -- Duplicate reference: RFC2315, mentioned in 'RFC2315', was also mentioned in 'RFC2314'. -- Obsolete informational reference (is this intentional?): RFC 2630 (Obsoleted by RFC 3369, RFC 3370) -- Obsolete informational reference (is this intentional?): RFC 2632 (Obsoleted by RFC 3850) -- Duplicate reference: RFC5035, mentioned in 'RFC2633', was also mentioned in 'RFC5035'. -- Obsolete informational reference (is this intentional?): RFC 3850 (Obsoleted by RFC 5750) -- Obsolete informational reference (is this intentional?): RFC 3851 (Obsoleted by RFC 5751) -- Duplicate reference: RFC5035, mentioned in 'RFC3852', was also mentioned in 'RFC2633'. Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 LAMPS J. Schaad 3 Internet-Draft August Cellars 4 Intended status: Standards Track B. Ramsdell 5 Expires: January 23, 2017 Brute Squad Labs, Inc. 6 S. Turner 7 sn3rd 8 July 22, 2016 10 Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 3.2 11 Certificate Handling 12 draft-schaad-lamps-rfc5750-bis-00 14 Abstract 16 This document specifies conventions for X.509 certificate usage by 17 Secure/Multipurpose Internet Mail Extensions (S/MIME) v3.2 agents. 18 S/MIME provides a method to send and receive secure MIME messages, 19 and certificates are an integral part of S/MIME agent processing. 20 S/MIME agents validate certificates as described in RFC 5280, the 21 Internet X.509 Public Key Infrastructure Certificate and CRL Profile. 22 S/MIME agents must meet the certificate processing requirements in 23 this document as well as those in RFC 5280. This document obsoletes 24 RFC 3850. 26 Contributing to this document 28 The source for this draft is being maintained in GitHub. Suggested 29 changes should be submitted as pull requests at . Instructions are on that page as well. Editorial 31 changes can be managed in GitHub, but any substantial issues need to 32 be discussed on the SPASM mailing list. 34 Status of This Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on January 23, 2017. 50 Copyright Notice 52 Copyright (c) 2016 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 68 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 69 1.2. Conventions Used in This Document . . . . . . . . . . . . 4 70 1.3. Compatibility with Prior Practice S/MIME . . . . . . . . 4 71 1.4. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 5 72 1.5. Changes since S/MIME v3.1 . . . . . . . . . . . . . . . . 5 73 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 6 74 2.1. Certificate Revocation Lists . . . . . . . . . . . . . . 6 75 2.2. Certificate Choices . . . . . . . . . . . . . . . . . . . 6 76 2.2.1. Historical Note about CMS Certificates . . . . . . . 7 77 2.3. CertificateSet . . . . . . . . . . . . . . . . . . . . . 7 78 3. Using Distinguished Names for Internet Mail . . . . . . . . . 8 79 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 9 80 4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 10 81 4.2. Certificate Path Validation . . . . . . . . . . . . . . . 10 82 4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 11 83 4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 12 84 4.4.1. Basic Constraints . . . . . . . . . . . . . . . . . . 13 85 4.4.2. Key Usage Certificate Extension . . . . . . . . . . . 13 86 4.4.3. Subject Alternative Name . . . . . . . . . . . . . . 14 87 4.4.4. Extended Key Usage Extension . . . . . . . . . . . . 14 88 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 89 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 90 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 91 6.2. Informational References . . . . . . . . . . . . . . . . 19 92 Appendix A. Moving S/MIME v2 Certificate Handling to Historic 93 Status . . . . . . . . . . . . . . . . . . . . . . . 21 94 Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . 21 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 97 1. Introduction 99 S/MIME (Secure/Multipurpose Internet Mail Extensions) v3.2, described 100 in [RFC5751], provides a method to send and receive secure MIME 101 messages. Before using a public key to provide security services, 102 the S/MIME agent MUST verify that the public key is valid. S/MIME 103 agents MUST use PKIX certificates to validate public keys as 104 described in the Internet X.509 Public Key Infrastructure (PKIX) 105 Certificate and CRL Profile [RFC5280]. S/MIME agents MUST meet the 106 certificate processing requirements documented in this document in 107 addition to those stated in [RFC5280]. 109 This specification is compatible with the Cryptographic Message 110 Syntax (CMS) RFC 5652 [RFC5652] in that it uses the data types 111 defined by CMS. It also inherits all the varieties of architectures 112 for certificate-based key management supported by CMS. 114 1.1. Definitions 116 For the purposes of this document, the following definitions apply. 118 ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680 119 [X.680]. 121 Attribute certificate (AC): An X.509 AC is a separate structure from 122 a subject's public key X.509 certificate. A subject may have 123 multiple X.509 ACs associated with each of its public key X.509 124 certificates. Each X.509 AC binds one or more attributes with one of 125 the subject's public key X.509 certificates. The X.509 AC syntax is 126 defined in [RFC5755]. 128 Certificate: A type that binds an entity's name to a public key with 129 a digital signature. This type is defined in the Internet X.509 130 Public Key Infrastructure (PKIX) Certificate and CRL Profile 131 [RFC5280]. This type also contains the distinguished name of the 132 certificate issuer (the signer), an issuer-specific serial number, 133 the issuer's signature algorithm identifier, a validity period, and 134 extensions also defined in that document. 136 Certificate Revocation List (CRL): A type that contains information 137 about certificates whose validity an issuer has prematurely revoked. 138 The information consists of an issuer name, the time of issue, the 139 next scheduled time of issue, a list of certificate serial numbers 140 and their associated revocation times, and extensions as defined in 141 [RFC5280]. The CRL is signed by the issuer. The type intended by 142 this specification is the one defined in [RFC5280]. 144 Receiving agent: Software that interprets and processes S/MIME CMS 145 objects, MIME body parts that contain CMS objects, or both. 147 Sending agent: Software that creates S/MIME CMS objects, MIME body 148 parts that contain CMS objects, or both. 150 S/MIME agent: User software that is a receiving agent, a sending 151 agent, or both. 153 1.2. Conventions Used in This Document 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in [RFC2119]. 159 We define some additional terms here: 161 SHOULD+ This term means the same as SHOULD. However, the authors 162 expect that a requirement marked as SHOULD+ will be promoted 163 at some future time to be a MUST. 165 SHOULD- This term means the same as SHOULD. However, the authors 166 expect that a requirement marked as SHOULD- will be demoted 167 to a MAY in a future version of this document. 169 MUST- This term means the same as MUST. However, the authors 170 expect that this requirement will no longer be a MUST in a 171 future document. Although its status will be determined at a 172 later time, it is reasonable to expect that if a future 173 revision of a document alters the status of a MUST- 174 requirement, it will remain at least a SHOULD or a SHOULD-. 176 1.3. Compatibility with Prior Practice S/MIME 178 S/MIME version 3.2 agents ought to attempt to have the greatest 179 interoperability possible with agents for prior versions of S/MIME. 181 S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive 182 [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634 183 inclusive and RFC 5035 [SMIMEv3], and S/MIME version 3.1 is described 184 in RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1]. 185 RFC 2311 also has historical information about the development of 186 S/MIME. 188 1.4. Changes from S/MIME v3 to S/MIME v3.1 190 Version 1 and version 2 CRLs MUST be supported. 192 Multiple certification authority (CA) certificates with the same 193 subject and public key, but with overlapping validity periods, MUST 194 be supported. 196 Version 2 attribute certificates SHOULD be supported, and version 1 197 attributes certificates MUST NOT be used. 199 The use of the MD2 digest algorithm for certificate signatures is 200 discouraged, and security language was added. 202 Clarified use of email address use in certificates. Certificates 203 that do not contain an email address have no requirements for 204 verifying the email address associated with the certificate. 206 Receiving agents SHOULD display certificate information when 207 displaying the results of signature verification. 209 Receiving agents MUST NOT accept a signature made with a certificate 210 that does not have the digitalSignature or nonRepudiation bit set. 212 Clarifications for the interpretation of the key usage and extended 213 key usage extensions. 215 1.5. Changes since S/MIME v3.1 217 Conventions Used in This Document: Moved to Section 1.2. Added 218 definitions for SHOULD+, SHOULD-, and MUST-. 220 Section 1.1: Updated ASN.1 definition and reference. 222 Section 1.3: Added text about v3.1 RFCs. 224 Section 3: Aligned email address text with RFC 5280. Updated note 225 to indicate emailAddress IA5String upper bound is 255 226 characters. Added text about matching email addresses. 228 Section 4.2: Added text to indicate how S/MIME agents locate the 229 correct user certificate. 231 Section 4.3: RSA with SHA-256 (PKCS #1 v1.5) added as MUST; DSA with 232 SHA-256 added as SHOULD+; RSA with SHA-1, DSA with SHA-1, 233 and RSA with MD5 changed to SHOULD-; and RSASSA-PSS with 234 SHA-256 added as SHOULD+. Updated key sizes and changed 235 pointer to PKIX RFCs. 237 Section 4.4.1: Aligned with PKIX on use of basic constraints 238 extension in CA certificates. Clarified which extension 239 is used to constrain end entities from using their keys 240 to perform issuing authority operations. 242 Section 5: Updated security considerations. 244 Section 7: Moved references from Appendix B to Section 6. Updated 245 the references. 247 Appendix A: Moved Appendix A to Appendix B. Added Appendix A to move 248 S/MIME v2 Certificate Handling to Historic Status. 250 2. CMS Options 252 The CMS message format allows for a wide variety of options in 253 content and algorithm support. This section puts forth a number of 254 support requirements and recommendations in order to achieve a base 255 level of interoperability among all S/MIME implementations. Most of 256 the CMS format for S/MIME messages is defined in [RFC5751]. 258 2.1. Certificate Revocation Lists 260 Receiving agents MUST support the Certificate Revocation List (CRL) 261 format defined in [RFC5280]. If sending agents include CRLs in 262 outgoing messages, the CRL format defined in [RFC5280] MUST be used. 263 In all cases, both v1 and v2 CRLs MUST be supported. 265 All agents MUST be capable of performing revocation checks using CRLs 266 as specified in [RFC5280]. All agents MUST perform revocation status 267 checking in accordance with [RFC5280]. Receiving agents MUST 268 recognize CRLs in received S/MIME messages. 270 Agents SHOULD store CRLs received in messages for use in processing 271 later messages. 273 2.2. Certificate Choices 275 Receiving agents MUST support v1 X.509 and v3 X.509 certificates as 276 profiled in [RFC5280]. End-entity certificates MAY include an 277 Internet mail address, as described in Section 3. 279 Receiving agents SHOULD support X.509 version 2 attribute 280 certificates. See [RFC5755] for details about the profile for 281 attribute certificates. 283 2.2.1. Historical Note about CMS Certificates 285 The CMS message format supports a choice of certificate formats for 286 public key content types: PKIX, PKCS #6 extended certificates 287 [PKCS6], and PKIX attribute certificates. 289 The PKCS #6 format is not in widespread use. In addition, PKIX 290 certificate extensions address much of the same functionality and 291 flexibility as was intended in the PKCS #6. Thus, sending and 292 receiving agents MUST NOT use PKCS #6 extended certificates. 294 X.509 version 1 attribute certificates are also not widely 295 implemented, and have been superseded with version 2 attribute 296 certificates. Sending agents MUST NOT send version 1 attribute 297 certificates. 299 2.3. CertificateSet 301 Receiving agents MUST be able to handle an arbitrary number of 302 certificates of arbitrary relationship to the message sender and to 303 each other in arbitrary order. In many cases, the certificates 304 included in a signed message may represent a chain of certification 305 from the sender to a particular root. There may be, however, 306 situations where the certificates in a signed message may be 307 unrelated and included for convenience. 309 Sending agents SHOULD include any certificates for the user's public 310 key(s) and associated issuer certificates. This increases the 311 likelihood that the intended recipient can establish trust in the 312 originator's public key(s). This is especially important when 313 sending a message to recipients that may not have access to the 314 sender's public key through any other means or when sending a signed 315 message to a new recipient. The inclusion of certificates in 316 outgoing messages can be omitted if S/MIME objects are sent within a 317 group of correspondents that has established access to each other's 318 certificates by some other means such as a shared directory or manual 319 certificate distribution. Receiving S/MIME agents SHOULD be able to 320 handle messages without certificates using a database or directory 321 lookup scheme. 323 A sending agent SHOULD include at least one chain of certificates up 324 to, but not including, a certification authority (CA) that it 325 believes that the recipient may trust as authoritative. A receiving 326 agent MUST be able to handle an arbitrarily large number of 327 certificates and chains. 329 Agents MAY send CA certificates, that is, cross-certificates, self- 330 issued certificates, and self-signed certificates. Note that 331 receiving agents SHOULD NOT simply trust any self-signed certificates 332 as valid CAs, but SHOULD use some other mechanism to determine if 333 this is a CA that should be trusted. Also note that when 334 certificates contain Digital Signature Algorithm (DSA) public keys 335 the parameters may be located in the root certificate. This would 336 require that the recipient possess both the end-entity certificate 337 and the root certificate to perform a signature verification, and is 338 a valid example of a case where transmitting the root certificate may 339 be required. 341 Receiving agents MUST support chaining based on the distinguished 342 name fields. Other methods of building certificate chains MAY be 343 supported. 345 Receiving agents SHOULD support the decoding of X.509 attribute 346 certificates included in CMS objects. All other issues regarding the 347 generation and use of X.509 attribute certificates are outside of the 348 scope of this specification. One specification that addresses 349 attribute certificate use is defined in [RFC3114]. 351 3. Using Distinguished Names for Internet Mail 353 End-entity certificates MAY contain an Internet mail address as 354 described in [RFC5280], Section 4.2.1.6. The email address SHOULD be 355 in the subjectAltName extension, and SHOULD NOT be in the subject 356 distinguished name. 358 Receiving agents MUST recognize and accept certificates that contain 359 no email address. Agents are allowed to provide an alternative 360 mechanism for associating an email address with a certificate that 361 does not contain an email address, such as through the use of the 362 agent's address book, if available. Receiving agents MUST recognize 363 email addresses in the subjectAltName field. Receiving agents MUST 364 recognize email addresses in the Distinguished Name field in the PKCS 365 #9 [RFC2985] emailAddress attribute: 367 pkcs-9-at-emailAddress OBJECT IDENTIFIER ::= 368 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 } 370 Note that this attribute MUST be encoded as IA5String and has an 371 upper bound of 255 characters. The right side of the email address 372 SHOULD be treated as ASCII-case-insensitive. 374 Sending agents SHOULD make the address in the From or Sender header 375 in a mail message match an Internet mail address in the signer's 376 certificate. Receiving agents MUST check that the address in the 377 From or Sender header of a mail message matches an Internet mail 378 address, if present, in the signer's certificate, if mail addresses 379 are present in the certificate. A receiving agent SHOULD provide 380 some explicit alternate processing of the message if this comparison 381 fails, which may be to display a message that shows the recipient the 382 addresses in the certificate or other certificate details. 384 A receiving agent SHOULD display a subject name or other certificate 385 details when displaying an indication of successful or unsuccessful 386 signature verification. 388 All subject and issuer names MUST be populated (i.e., not an empty 389 SEQUENCE) in S/MIME-compliant X.509 certificates, except that the 390 subject distinguished name (DN) in a user's (i.e., end-entity) 391 certificate MAY be an empty SEQUENCE in which case the subjectAltName 392 extension will include the subject's identifier and MUST be marked as 393 critical. 395 4. Certificate Processing 397 S/MIME agents need to provide some certificate retrieval mechanism in 398 order to gain access to certificates for recipients of digital 399 envelopes. There are many ways to implement certificate retrieval 400 mechanisms. [X.500] directory service is an excellent example of a 401 certificate retrieval-only mechanism that is compatible with classic 402 X.500 Distinguished Names. Another method under consideration by the 403 IETF is to provide certificate retrieval services as part of the 404 existing Domain Name System (DNS). Until such mechanisms are widely 405 used, their utility may be limited by the small number of the 406 correspondent's certificates that can be retrieved. At a minimum, 407 for initial S/MIME deployment, a user agent could automatically 408 generate a message to an intended recipient requesting the 409 recipient's certificate in a signed return message. 411 Receiving and sending agents SHOULD also provide a mechanism to allow 412 a user to "store and protect" certificates for correspondents in such 413 a way so as to guarantee their later retrieval. In many 414 environments, it may be desirable to link the certificate retrieval/ 415 storage mechanisms together in some sort of certificate database. In 416 its simplest form, a certificate database would be local to a 417 particular user and would function in a similar way as an "address 418 book" that stores a user's frequent correspondents. In this way, the 419 certificate retrieval mechanism would be limited to the certificates 420 that a user has stored (presumably from incoming messages). A 421 comprehensive certificate retrieval/storage solution may combine two 422 or more mechanisms to allow the greatest flexibility and utility to 423 the user. For instance, a secure Internet mail agent may resort to 424 checking a centralized certificate retrieval mechanism for a 425 certificate if it cannot be found in a user's local certificate 426 storage/retrieval database. 428 Receiving and sending agents SHOULD provide a mechanism for the 429 import and export of certificates, using a CMS certs-only message. 430 This allows for import and export of full certificate chains as 431 opposed to just a single certificate. This is described in 432 [RFC5751]. 434 Agents MUST handle multiple valid certification authority (CA) 435 certificates containing the same subject name and the same public 436 keys but with overlapping validity intervals. 438 4.1. Certificate Revocation Lists 440 In general, it is always better to get the latest CRL information 441 from a CA than to get information stored away from incoming messages. 442 A receiving agent SHOULD have access to some CRL retrieval mechanism 443 in order to gain access to certificate revocation information when 444 validating certification paths. A receiving or sending agent SHOULD 445 also provide a mechanism to allow a user to store incoming 446 certificate revocation information for correspondents in such a way 447 so as to guarantee its later retrieval. 449 Receiving and sending agents SHOULD retrieve and utilize CRL 450 information every time a certificate is verified as part of a 451 certification path validation even if the certificate was already 452 verified in the past. However, in many instances (such as off-line 453 verification) access to the latest CRL information may be difficult 454 or impossible. The use of CRL information, therefore, may be 455 dictated by the value of the information that is protected. The 456 value of the CRL information in a particular context is beyond the 457 scope of this specification but may be governed by the policies 458 associated with particular certification paths. 460 All agents MUST be capable of performing revocation checks using CRLs 461 as specified in [RFC5280]. All agents MUST perform revocation status 462 checking in accordance with [RFC5280]. Receiving agents MUST 463 recognize CRLs in received S/MIME messages. 465 4.2. Certificate Path Validation 467 In creating a user agent for secure messaging, certificate, CRL, and 468 certification path validation SHOULD be highly automated while still 469 acting in the best interests of the user. Certificate, CRL, and path 470 validation MUST be performed as per [RFC5280] when validating a 471 correspondent's public key. This is necessary before using a public 472 key to provide security services such as verifying a signature, 473 encrypting a content-encryption key (e.g., RSA), or forming a 474 pairwise symmetric key (e.g., Diffie-Hellman) to be used to encrypt 475 or decrypt a content-encryption key. 477 Certificates and CRLs are made available to the path validation 478 procedure in two ways: a) incoming messages, and b) certificate and 479 CRL retrieval mechanisms. Certificates and CRLs in incoming messages 480 are not required to be in any particular order nor are they required 481 to be in any way related to the sender or recipient of the message 482 (although in most cases they will be related to the sender). 483 Incoming certificates and CRLs SHOULD be cached for use in path 484 validation and optionally stored for later use. This temporary 485 certificate and CRL cache SHOULD be used to augment any other 486 certificate and CRL retrieval mechanisms for path validation on 487 incoming signed messages. 489 When verifying a signature and the certificates that are included in 490 the message, if a signingCertificate attribute from RFC 2634 [ESS] or 491 a signingCertificateV2 attribute from RFC 5035 [ESS] is found in an 492 S/MIME message, it SHALL be used to identify the signer's 493 certificate. Otherwise, the certificate is identified in an S/MIME 494 message, either using the issuerAndSerialNumber, which identifies the 495 signer's certificate by the issuer's distinguished name and the 496 certificate serial number, or the subjectKeyIdentifier, which 497 identifies the signer's certificate by a key identifier. 499 When decrypting an encrypted message, if a 500 SMIMEEncryptionKeyPreference attribute is found in an encapsulating 501 SignedData, it SHALL be used to identify the originator's certificate 502 found in OriginatorInfo. See [RFC5652] for the CMS fields that 503 reference the originator's and recipient's certificates. 505 4.3. Certificate and CRL Signing Algorithms and Key Sizes 507 Certificates and Certificate Revocation Lists (CRLs) are signed by 508 the certificate issuer. Receiving agents: 510 - MUST support RSA with SHA-256 512 - SHOULD+ support DSA with SHA-256 514 - SHOULD+ support RSASSA-PSS with SHA-256 516 - SHOULD- support RSA with SHA-1 518 - SHOULD- support DSA with SHA-1 520 - SHOULD- support RSA with MD5 522 The following are the RSA and RSASSA-PSS key size requirements for 523 S/MIME receiving agents during certificate and CRL signature 524 verification: 526 key size <= 1023 : MAY (see Section 5) 527 1024 <= key size <= 4096 : MUST (see Section 5) 528 4096 < key size : MAY (see Section 5) 530 The following are the DSA key size requirements for S/MIME receiving 531 agents during certificate and CRL signature verification: 533 key size <= 1023 : MAY (see Section 5) 534 1024 <= key size <= 3072 : MUST (see Section 5) 536 For 512-bit RSA with SHA-1 see [RFC3279] and [FIPS186-2] without 537 Change Notice 1, for 512-bit RSA with SHA-256 see [RFC4055] and 538 [FIPS186-2] without Change Notice 1, for 1024-bit through 3072-bit 539 RSA with SHA-256 see [RFC4055] and [FIPS186-2] with Change Notice 1, 540 and for 4096-bit RSA with SHA-256 see [RFC4055] and [RFC3447]. In 541 either case, the first reference provides the signature algorithm's 542 object identifier and the second provides the signature algorithm's 543 definition. 545 For 512-bit DSA with SHA-1 see [RFC3279] and [FIPS186-2] without 546 Change Notice 1, for 512-bit DSA with SHA-256 see [RFC5758] and 547 [FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see 548 [RFC3279] and [FIPS186-2] with Change Notice 1, for 1024-bit through 549 3072 DSA with SHA-256 see [RFC5758] and [FIPS186-3]. In either case, 550 the first reference provides the signature algorithm's object 551 identifier and the second provides the signature algorithm's 552 definition. 554 For RSASSA-PSS with SHA-256 see [RFC4056]. 556 4.4. PKIX Certificate Extensions 558 PKIX describes an extensible framework in which the basic certificate 559 information can be extended and describes how such extensions can be 560 used to control the process of issuing and validating certificates. 561 The PKIX Working Group has ongoing efforts to identify and create 562 extensions that have value in particular certification environments. 563 Further, there are active efforts underway to issue PKIX certificates 564 for business purposes. This document identifies the minimum required 565 set of certificate extensions that have the greatest value in the 566 S/MIME environment. The syntax and semantics of all the identified 567 extensions are defined in [RFC5280]. 569 Sending and receiving agents MUST correctly handle the basic 570 constraints, key usage, authority key identifier, subject key 571 identifier, and subject alternative names certificate extensions when 572 they appear in end-entity and CA certificates. Some mechanism SHOULD 573 exist to gracefully handle other certificate extensions when they 574 appear in end-entity or CA certificates. 576 Certificates issued for the S/MIME environment SHOULD NOT contain any 577 critical extensions (extensions that have the critical field set to 578 TRUE) other than those listed here. These extensions SHOULD be 579 marked as non-critical unless the proper handling of the extension is 580 deemed critical to the correct interpretation of the associated 581 certificate. Other extensions may be included, but those extensions 582 SHOULD NOT be marked as critical. 584 Interpretation and syntax for all extensions MUST follow [RFC5280], 585 unless otherwise specified here. 587 4.4.1. Basic Constraints 589 The basic constraints extension serves to delimit the role and 590 position that an issuing authority or end-entity certificate plays in 591 a certification path. 593 For example, certificates issued to CAs and subordinate CAs contain a 594 basic constraint extension that identifies them as issuing authority 595 certificates. End-entity certificates contain the key usage 596 extension that restrains end entities from using the key when 597 performing issuing authority operations (see Section 4.4.2). 599 As per [RFC5280], certificates MUST contain a basicConstraints 600 extension in CA certificates, and SHOULD NOT contain that extension 601 in end- entity certificates. 603 4.4.2. Key Usage Certificate Extension 605 The key usage extension serves to limit the technical purposes for 606 which a public key listed in a valid certificate may be used. 607 Issuing authority certificates may contain a key usage extension that 608 restricts the key to signing certificates, certificate revocation 609 lists, and other data. 611 For example, a certification authority may create subordinate issuer 612 certificates that contain a key usage extension that specifies that 613 the corresponding public key can be used to sign end user 614 certificates and sign CRLs. 616 If a key usage extension is included in a PKIX certificate, then it 617 MUST be marked as critical. 619 S/MIME receiving agents MUST NOT accept the signature of a message if 620 it was verified using a certificate that contains the key usage 621 extension without either the digitalSignature or nonRepudiation bit 622 set. Sometimes S/MIME is used as a secure message transport for 623 applications beyond interpersonal messaging. In such cases, the 624 S/MIME-enabled application can specify additional requirements 625 concerning the digitalSignature or nonRepudiation bits within this 626 extension. 628 If the key usage extension is not specified, receiving clients MUST 629 presume that the digitalSignature and nonRepudiation bits are set. 631 4.4.3. Subject Alternative Name 633 The subject alternative name extension is used in S/MIME as the 634 preferred means to convey the email address(es) that correspond(s) to 635 the entity for this certificate. Any email addresses present MUST be 636 encoded using the rfc822Name CHOICE of the GeneralName type as 637 described in [RFC5280], Section 4.2.1.6. Since the SubjectAltName 638 type is a SEQUENCE OF GeneralName, multiple email addresses MAY be 639 present. 641 4.4.4. Extended Key Usage Extension 643 The extended key usage extension also serves to limit the technical 644 purposes for which a public key listed in a valid certificate may be 645 used. The set of technical purposes for the certificate therefore 646 are the intersection of the uses indicated in the key usage and 647 extended key usage extensions. 649 For example, if the certificate contains a key usage extension 650 indicating digital signature and an extended key usage extension that 651 includes the email protection OID, then the certificate may be used 652 for signing but not encrypting S/MIME messages. If the certificate 653 contains a key usage extension indicating digital signature but no 654 extended key usage extension, then the certificate may also be used 655 to sign but not encrypt S/MIME messages. 657 If the extended key usage extension is present in the certificate, 658 then interpersonal message S/MIME receiving agents MUST check that it 659 contains either the emailProtection or the anyExtendedKeyUsage OID as 660 defined in [RFC5280]. S/MIME uses other than interpersonal messaging 661 MAY require the explicit presence of the extended key usage extension 662 or other OIDs to be present in the extension or both. 664 5. Security Considerations 666 All of the security issues faced by any cryptographic application 667 must be faced by a S/MIME agent. Among these issues are protecting 668 the user's private key, preventing various attacks, and helping the 669 user avoid mistakes such as inadvertently encrypting a message for 670 the wrong recipient. The entire list of security considerations is 671 beyond the scope of this document, but some significant concerns are 672 listed here. 674 When processing certificates, there are many situations where the 675 processing might fail. Because the processing may be done by a user 676 agent, a security gateway, or other program, there is no single way 677 to handle such failures. Just because the methods to handle the 678 failures have not been listed, however, the reader should not assume 679 that they are not important. The opposite is true: if a certificate 680 is not provably valid and associated with the message, the processing 681 software should take immediate and noticeable steps to inform the end 682 user about it. 684 Some of the many places where signature and certificate checking 685 might fail include: 687 - no Internet mail addresses in a certificate match the sender of a 688 message, if the certificate contains at least one mail address 690 - no certificate chain leads to a trusted CA 692 - no ability to check the CRL for a certificate 694 - an invalid CRL was received 696 - the CRL being checked is expired 698 - the certificate is expired 700 - the certificate has been revoked 702 There are certainly other instances where a certificate may be 703 invalid, and it is the responsibility of the processing software to 704 check them all thoroughly, and to decide what to do if the check 705 fails. 707 It is possible for there to be multiple unexpired CRLs for a CA. If 708 an agent is consulting CRLs for certificate validation, it SHOULD 709 make sure that the most recently issued CRL for that CA is consulted, 710 since an S/MIME message sender could deliberately include an older 711 unexpired CRL in an S/MIME message. This older CRL might not include 712 recently revoked certificates, which might lead an agent to accept a 713 certificate that has been revoked in a subsequent CRL. 715 When determining the time for a certificate validity check, agents 716 have to be careful to use a reliable time. Unless it is from a 717 trusted agent, this time MUST NOT be the SigningTime attribute found 718 in an S/MIME message. For most sending agents, the SigningTime 719 attribute could be deliberately set to direct the receiving agent to 720 check a CRL that could have out-of-date revocation status for a 721 certificate, or cause an improper result when checking the Validity 722 field of a certificate. 724 In addition to the Security Considerations identified in [RFC5280], 725 caution should be taken when processing certificates that have not 726 first been validated to a trust anchor. Certificates could be 727 manufactured by untrusted sources for the purpose of mounting denial 728 of service or other attacks. For example, keys selected to require 729 excessive cryptographic processing, or extensive lists of CRL 730 Distribution Point (CDP) and/or Authority Information Access (AIA) 731 addresses in the certificate, could be used to mount denial-of- 732 service attacks. Similarly, attacker-specified CDP and/or AIA 733 addresses could be included in fake certificates to allow the 734 originator to detect receipt of the message even if signature 735 verification fails. 737 The 4096-bit RSA key size requirement for certificate and CRL 738 verification is larger than the 2048-bit RSA key sizes for message 739 signature generation/verification or message encryption/decryption in 740 [RFC5751] because many root CAs included in certificate stores have 741 already issued root certificates with the 4096-bit key. The standard 742 that defines comparable key sizes for DSA is not yet available. In 743 particular, [FIPS186-2] without Change Notice 1 allowed DSA key sizes 744 between 512 and 1024 bits, [FIPS186-2] with Change Notice 1 only 745 allowed DSA key sizes of 1024 bits, and [FIPS186-3] allowed DSA key 746 sizes from 1024 to 3072 bits. Further, 4096-bit keys are normally 747 only used by Root certificates and not by subordinate CA 748 certificates, thereby lengthening the root CA certificate's validity 749 period. 751 RSA and DSA keys of less than 1024 bits are now considered by many 752 experts to be cryptographically insecure (due to advances in 753 computing power), and should no longer be used to sign certificates 754 or CRLs. Such keys were previously considered secure, so processing 755 previously received signed and encrypted mail may require processing 756 certificates or CRLs signed with weak keys. Implementations that 757 wish to support previous versions of S/MIME or process old messages 758 need to consider the security risks that result from accepting 759 certificates and CRLs with smaller key sizes (e.g., spoofed 760 certificates) versus the costs of denial of service. If an 761 implementation supports verification of certificates or CRLs 762 generated with RSA and DSA keys of less than 1024 bits, it MUST warn 763 the user. Implementers should consider providing a stronger warning 764 for weak signatures on certificates and CRLs associated with newly 765 received messages than the one provided for certificates and CRLs 766 associated with previously stored messages. Server implementations 767 (e.g., secure mail list servers) where user warnings are not 768 appropriate SHOULD reject messages with weak cryptography. 770 If an implementation is concerned about compliance with National 771 Institute of Standards and Technology (NIST) key size 772 recommendations, then see [SP800-57]. 774 6. References 776 6.1. Normative References 778 [FIPS186-2] 779 National Institute of Standards and Technology (NIST), 780 "Digital Signature Standard (DSS) [With Change Notice 1]", 781 Federal Information Processing Standards 782 Publication 186-2, January 2000. 784 [FIPS186-3] 785 National Institute of Standards and Technology (NIST), 786 "Digital Signature Standard (DSS)", Federal Information 787 Processing Standards Publication 186-3, June 2009. 789 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 790 Requirement Levels", BCP 14, RFC 2119, 791 DOI 10.17487/RFC2119, March 1997, 792 . 794 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 795 RFC 2634, DOI 10.17487/RFC2634, June 1999, 796 . 798 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 799 Classes and Attribute Types Version 2.0", RFC 2985, 800 DOI 10.17487/RFC2985, November 2000, 801 . 803 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 804 Identifiers for the Internet X.509 Public Key 805 Infrastructure Certificate and Certificate Revocation List 806 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 807 2002, . 809 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 810 Standards (PKCS) #1: RSA Cryptography Specifications 811 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 812 2003, . 814 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 815 Algorithms and Identifiers for RSA Cryptography for use in 816 the Internet X.509 Public Key Infrastructure Certificate 817 and Certificate Revocation List (CRL) Profile", RFC 4055, 818 DOI 10.17487/RFC4055, June 2005, 819 . 821 [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in 822 Cryptographic Message Syntax (CMS)", RFC 4056, 823 DOI 10.17487/RFC4056, June 2005, 824 . 826 [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: 827 Adding CertID Algorithm Agility", RFC 5035, 828 DOI 10.17487/RFC5035, August 2007, 829 . 831 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 832 Housley, R., and W. Polk, "Internet X.509 Public Key 833 Infrastructure Certificate and Certificate Revocation List 834 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 835 . 837 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 838 RFC 5652, DOI 10.17487/RFC5652, September 2009, 839 . 841 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 842 Mail Extensions (S/MIME) Version 3.2 Message 843 Specification", RFC 5751, DOI 10.17487/RFC5751, January 844 2010, . 846 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 847 Attribute Certificate Profile for Authorization", 848 RFC 5755, DOI 10.17487/RFC5755, January 2010, 849 . 851 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 852 Polk, "Internet X.509 Public Key Infrastructure: 853 Additional Algorithms and Identifiers for DSA and ECDSA", 854 RFC 5758, DOI 10.17487/RFC5758, January 2010, 855 . 857 [X.680] "Information Technology - Abstract Syntax Notation One 858 (ASN.1): Specification of basic notation. ITU-T 859 Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.". 861 6.2. Informational References 863 [ESS] "Enhanced Security Services for S/ MIME". 865 This is the set of documents dealing with enhanged 866 security services and refers to [RFC2634] and [RFC5035]. 868 [PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax 869 Standard", November 1993. 871 [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and 872 L. Repka, "S/MIME Version 2 Message Specification", 873 RFC 2311, DOI 10.17487/RFC2311, March 1998, 874 . 876 [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, 877 "S/MIME Version 2 Certificate Handling", RFC 2312, 878 DOI 10.17487/RFC2312, March 1998, 879 . 881 [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", 882 RFC 2313, DOI 10.17487/RFC2313, March 1998, 883 . 885 [RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax 886 Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998, 887 . 889 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 890 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 891 . 893 [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, 894 DOI 10.17487/RFC2630, June 1999, 895 . 897 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 898 RFC 2631, DOI 10.17487/RFC2631, June 1999, 899 . 901 [RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate 902 Handling", RFC 2632, DOI 10.17487/RFC2632, June 1999, 903 . 905 [RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message 906 Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999, 907 . 909 [RFC3114] Nicolls, W., "Implementing Company Classification Policy 910 with the S/MIME Security Label", RFC 3114, 911 DOI 10.17487/RFC3114, May 2002, 912 . 914 [RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail 915 Extensions (S/MIME) Version 3.1 Certificate Handling", 916 RFC 3850, DOI 10.17487/RFC3850, July 2004, 917 . 919 [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail 920 Extensions (S/MIME) Version 3.1 Message Specification", 921 RFC 3851, DOI 10.17487/RFC3851, July 2004, 922 . 924 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 925 RFC 3852, DOI 10.17487/RFC3852, July 2004, 926 . 928 [SMIMEv2] "S/MIME version v2". 930 This group of documents represents S/MIME version 2. This 931 set of documents are [RFC2311], [RFC2312], [RFC2313], 932 [RFC2314], and [RFC2315]. 934 [SMIMEv3] "S/MIME version 3". 936 This group of documents represents S/MIME version 3. This 937 set of documents are [RFC2630], [RFC2631], [RFC2632], 938 [RFC2633], [RFC2634], and [RFC5035]. 940 [SMIMEv3.1] 941 "S/MIME version 3.1". 943 This group of documents represents S/MIME version 3.1. 944 This set of documents are [RFC2634], [RFC3850], [RFC3851], 945 [RFC3852], and [RFC5035]. 947 [SP800-57] 948 National Institute of Standards and Technology (NIST), 949 "Special Publication 800-57: Recommendation for Key 950 Management", August 2005. 952 [X.500] "ITU-T Recommendation X.500 (1997) | ISO/IEC 9594- 1:1997, 953 Information technology - Open Systems Interconnection - 954 The Directory: Overview of concepts, models and 955 services.". 957 Appendix A. Moving S/MIME v2 Certificate Handling to Historic Status 959 The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document) 960 are backwards compatible with the S/MIME v2 Certificate Handling 961 Specification [SMIMEv2], with the exception of the algorithms 962 (dropped RC2/40 requirement and added DSA and RSASSA-PSS 963 requirements). Therefore, it is recommended that RFC 2312 [SMIMEv2] 964 be moved to Historic status. 966 Appendix B. Acknowledgments 968 Many thanks go out to the other authors of the S/MIME v2 RFC: Steve 969 Dusse, Paul Hoffman, and Jeff Weinstein. Without v2, there wouldn't 970 be a v3, v3.1, or v3.2. 972 A number of the members of the S/MIME Working Group have also worked 973 very hard and contributed to this document. Any list of people is 974 doomed to omission, and for that I apologize. In alphabetical order, 975 the following people stand out in my mind because they made direct 976 contributions to this document. 978 Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Alfred Hoenes, Paul 979 Hoffman, Russ Housley, David P. Kemp, Michael Myers, John Pawling, 980 Denis Pinkas, and Jim Schaad. 982 Authors' Addresses 984 Jim Schaad 985 August Cellars 987 Email: ietf@augustcellars.com 989 Blake Ramsdell 990 Brute Squad Labs, Inc. 992 Email: blaker@gmail.com 994 Sean Turner 995 sn3rd 997 Email: sean@sn3rd.com