idnits 2.17.1 draft-ietf-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 (August 29, 2016) is 2769 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 952, but no explicit reference was found in the text == Unused Reference: 'RFC2315' is defined on line 899, but no explicit reference was found in the text == Unused Reference: 'RFC2633' is defined on line 958, but no explicit reference was found in the text == Unused Reference: 'RFC3852' is defined on line 965, 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 5750 (Obsoleted by RFC 8550) ** 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: 5 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: March 2, 2017 Brute Squad Labs, Inc. 6 S. Turner 7 sn3rd 8 August 29, 2016 10 Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 3.2 11 Certificate Handling 12 draft-ietf-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 LAMPS 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 March 2, 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 1.6. Changes from 3.2 to 3.5 . . . . . . . . . . . . . . . . . 6 74 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 6 75 2.1. Certificate Revocation Lists . . . . . . . . . . . . . . 6 76 2.2. Certificate Choices . . . . . . . . . . . . . . . . . . . 6 77 2.2.1. Historical Note about CMS Certificates . . . . . . . 7 78 2.3. CertificateSet . . . . . . . . . . . . . . . . . . . . . 7 79 3. Using Distinguished Names for Internet Mail . . . . . . . . . 8 80 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 9 81 4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 10 82 4.2. Certificate Path Validation . . . . . . . . . . . . . . . 10 83 4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 11 84 4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 12 85 4.4.1. Basic Constraints . . . . . . . . . . . . . . . . . . 13 86 4.4.2. Key Usage Certificate Extension . . . . . . . . . . . 13 87 4.4.3. Subject Alternative Name . . . . . . . . . . . . . . 14 88 4.4.4. Extended Key Usage Extension . . . . . . . . . . . . 14 89 5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 90 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 91 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 92 6.2. Informational References . . . . . . . . . . . . . . . . 19 93 Appendix A. Historic Considerations . . . . . . . . . . . . . . 21 94 A.1. Signature Algorithms and Key Sizes . . . . . . . . . . . 21 95 Appendix B. Moving S/MIME v2 Certificate Handling to Historic 96 Status . . . . . . . . . . . . . . . . . . . . . . . 22 97 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 22 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 100 1. Introduction 102 S/MIME (Secure/Multipurpose Internet Mail Extensions) v3.2, described 103 in [RFC5751], provides a method to send and receive secure MIME 104 messages. Before using a public key to provide security services, 105 the S/MIME agent MUST verify that the public key is valid. S/MIME 106 agents MUST use PKIX certificates to validate public keys as 107 described in the Internet X.509 Public Key Infrastructure (PKIX) 108 Certificate and CRL Profile [RFC5280]. S/MIME agents MUST meet the 109 certificate processing requirements documented in this document in 110 addition to those stated in [RFC5280]. 112 This specification is compatible with the Cryptographic Message 113 Syntax (CMS) RFC 5652 [RFC5652] in that it uses the data types 114 defined by CMS. It also inherits all the varieties of architectures 115 for certificate-based key management supported by CMS. 117 1.1. Definitions 119 For the purposes of this document, the following definitions apply. 121 ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680 122 [X.680]. 124 Attribute certificate (AC): An X.509 AC is a separate structure from 125 a subject's public key X.509 certificate. A subject may have 126 multiple X.509 ACs associated with each of its public key X.509 127 certificates. Each X.509 AC binds one or more attributes with one of 128 the subject's public key X.509 certificates. The X.509 AC syntax is 129 defined in [RFC5755]. 131 Certificate: A type that binds an entity's name to a public key with 132 a digital signature. This type is defined in the Internet X.509 133 Public Key Infrastructure (PKIX) Certificate and CRL Profile 134 [RFC5280]. This type also contains the distinguished name of the 135 certificate issuer (the signer), an issuer-specific serial number, 136 the issuer's signature algorithm identifier, a validity period, and 137 extensions also defined in that document. 139 Certificate Revocation List (CRL): A type that contains information 140 about certificates whose validity an issuer has prematurely revoked. 141 The information consists of an issuer name, the time of issue, the 142 next scheduled time of issue, a list of certificate serial numbers 143 and their associated revocation times, and extensions as defined in 145 [RFC5280]. The CRL is signed by the issuer. The type intended by 146 this specification is the one defined in [RFC5280]. 148 Receiving agent: Software that interprets and processes S/MIME CMS 149 objects, MIME body parts that contain CMS objects, or both. 151 Sending agent: Software that creates S/MIME CMS objects, MIME body 152 parts that contain CMS objects, or both. 154 S/MIME agent: User software that is a receiving agent, a sending 155 agent, or both. 157 1.2. Conventions Used in This Document 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in [RFC2119]. 163 We define some additional terms here: 165 SHOULD+ This term means the same as SHOULD. However, the authors 166 expect that a requirement marked as SHOULD+ will be promoted 167 at some future time to be a MUST. 169 SHOULD- This term means the same as SHOULD. However, the authors 170 expect that a requirement marked as SHOULD- will be demoted 171 to a MAY in a future version of this document. 173 MUST- This term means the same as MUST. However, the authors 174 expect that this requirement will no longer be a MUST in a 175 future document. Although its status will be determined at a 176 later time, it is reasonable to expect that if a future 177 revision of a document alters the status of a MUST- 178 requirement, it will remain at least a SHOULD or a SHOULD-. 180 1.3. Compatibility with Prior Practice S/MIME 182 S/MIME version 3.2 agents ought to attempt to have the greatest 183 interoperability possible with agents for prior versions of S/MIME. 185 S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive 186 [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634 187 inclusive and RFC 5035 [SMIMEv3], and S/MIME version 3.1 is described 188 in RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1]. 189 RFC 2311 also has historical information about the development of 190 S/MIME. 192 1.4. Changes from S/MIME v3 to S/MIME v3.1 194 Version 1 and version 2 CRLs MUST be supported. 196 Multiple certification authority (CA) certificates with the same 197 subject and public key, but with overlapping validity periods, MUST 198 be supported. 200 Version 2 attribute certificates SHOULD be supported, and version 1 201 attributes certificates MUST NOT be used. 203 The use of the MD2 digest algorithm for certificate signatures is 204 discouraged, and security language was added. 206 Clarified use of email address use in certificates. Certificates 207 that do not contain an email address have no requirements for 208 verifying the email address associated with the certificate. 210 Receiving agents SHOULD display certificate information when 211 displaying the results of signature verification. 213 Receiving agents MUST NOT accept a signature made with a certificate 214 that does not have the digitalSignature or nonRepudiation bit set. 216 Clarifications for the interpretation of the key usage and extended 217 key usage extensions. 219 1.5. Changes since S/MIME v3.1 221 Conventions Used in This Document: Moved to Section 1.2. Added 222 definitions for SHOULD+, SHOULD-, and MUST-. 224 Section 1.1: Updated ASN.1 definition and reference. 226 Section 1.3: Added text about v3.1 RFCs. 228 Section 3: Aligned email address text with RFC 5280. Updated note 229 to indicate emailAddress IA5String upper bound is 255 230 characters. Added text about matching email addresses. 232 Section 4.2: Added text to indicate how S/MIME agents locate the 233 correct user certificate. 235 Section 4.3: RSA with SHA-256 (PKCS #1 v1.5) added as MUST; DSA with 236 SHA-256 added as SHOULD+; RSA with SHA-1, DSA with SHA-1, 237 and RSA with MD5 changed to SHOULD-; and RSASSA-PSS with 238 SHA-256 added as SHOULD+. Updated key sizes and changed 239 pointer to PKIX RFCs. 241 Section 4.4.1: Aligned with PKIX on use of basic constraints 242 extension in CA certificates. Clarified which extension 243 is used to constrain end entities from using their keys 244 to perform issuing authority operations. 246 Section 5: Updated security considerations. 248 Section 7: Moved references from Appendix B to Section 6. Updated 249 the references. 251 Appendix A: Moved Appendix A to Appendix B. Added Appendix A to move 252 S/MIME v2 Certificate Handling to Historic Status. 254 1.6. Changes from 3.2 to 3.5 256 2. CMS Options 258 The CMS message format allows for a wide variety of options in 259 content and algorithm support. This section puts forth a number of 260 support requirements and recommendations in order to achieve a base 261 level of interoperability among all S/MIME implementations. Most of 262 the CMS format for S/MIME messages is defined in [RFC5751]. 264 2.1. Certificate Revocation Lists 266 Receiving agents MUST support the Certificate Revocation List (CRL) 267 format defined in [RFC5280]. If sending agents include CRLs in 268 outgoing messages, the CRL format defined in [RFC5280] MUST be used. 269 In all cases, both v1 and v2 CRLs MUST be supported. 271 All agents MUST be capable of performing revocation checks using CRLs 272 as specified in [RFC5280]. All agents MUST perform revocation status 273 checking in accordance with [RFC5280]. Receiving agents MUST 274 recognize CRLs in received S/MIME messages. 276 Agents SHOULD store CRLs received in messages for use in processing 277 later messages. 279 2.2. Certificate Choices 281 Receiving agents MUST support v1 X.509 and v3 X.509 certificates as 282 profiled in [RFC5280]. End-entity certificates MAY include an 283 Internet mail address, as described in Section 3. 285 Receiving agents SHOULD support X.509 version 2 attribute 286 certificates. See [RFC5755] for details about the profile for 287 attribute certificates. 289 2.2.1. Historical Note about CMS Certificates 291 The CMS message format supports a choice of certificate formats for 292 public key content types: PKIX, PKCS #6 extended certificates 293 [PKCS6], and PKIX attribute certificates. 295 The PKCS #6 format is not in widespread use. In addition, PKIX 296 certificate extensions address much of the same functionality and 297 flexibility as was intended in the PKCS #6. Thus, sending and 298 receiving agents MUST NOT use PKCS #6 extended certificates. 300 X.509 version 1 attribute certificates are also not widely 301 implemented, and have been superseded with version 2 attribute 302 certificates. Sending agents MUST NOT send version 1 attribute 303 certificates. 305 2.3. CertificateSet 307 Receiving agents MUST be able to handle an arbitrary number of 308 certificates of arbitrary relationship to the message sender and to 309 each other in arbitrary order. In many cases, the certificates 310 included in a signed message may represent a chain of certification 311 from the sender to a particular root. There may be, however, 312 situations where the certificates in a signed message may be 313 unrelated and included for convenience. 315 Sending agents SHOULD include any certificates for the user's public 316 key(s) and associated issuer certificates. This increases the 317 likelihood that the intended recipient can establish trust in the 318 originator's public key(s). This is especially important when 319 sending a message to recipients that may not have access to the 320 sender's public key through any other means or when sending a signed 321 message to a new recipient. The inclusion of certificates in 322 outgoing messages can be omitted if S/MIME objects are sent within a 323 group of correspondents that has established access to each other's 324 certificates by some other means such as a shared directory or manual 325 certificate distribution. Receiving S/MIME agents SHOULD be able to 326 handle messages without certificates using a database or directory 327 lookup scheme. 329 A sending agent SHOULD include at least one chain of certificates up 330 to, but not including, a certification authority (CA) that it 331 believes that the recipient may trust as authoritative. A receiving 332 agent MUST be able to handle an arbitrarily large number of 333 certificates and chains. 335 Agents MAY send CA certificates, that is, cross-certificates, self- 336 issued certificates, and self-signed certificates. Note that 337 receiving agents SHOULD NOT simply trust any self-signed certificates 338 as valid CAs, but SHOULD use some other mechanism to determine if 339 this is a CA that should be trusted. Also note that when 340 certificates contain Digital Signature Algorithm (DSA) public keys 341 the parameters may be located in the root certificate. This would 342 require that the recipient possess both the end-entity certificate 343 and the root certificate to perform a signature verification, and is 344 a valid example of a case where transmitting the root certificate may 345 be required. 347 Receiving agents MUST support chaining based on the distinguished 348 name fields. Other methods of building certificate chains MAY be 349 supported. 351 Receiving agents SHOULD support the decoding of X.509 attribute 352 certificates included in CMS objects. All other issues regarding the 353 generation and use of X.509 attribute certificates are outside of the 354 scope of this specification. One specification that addresses 355 attribute certificate use is defined in [RFC3114]. 357 3. Using Distinguished Names for Internet Mail 359 End-entity certificates MAY contain an Internet mail address as 360 described in [RFC5280], Section 4.2.1.6. The email address SHOULD be 361 in the subjectAltName extension, and SHOULD NOT be in the subject 362 distinguished name. 364 Receiving agents MUST recognize and accept certificates that contain 365 no email address. Agents are allowed to provide an alternative 366 mechanism for associating an email address with a certificate that 367 does not contain an email address, such as through the use of the 368 agent's address book, if available. Receiving agents MUST recognize 369 email addresses in the subjectAltName field. Receiving agents MUST 370 recognize email addresses in the Distinguished Name field in the PKCS 371 #9 [RFC2985] emailAddress attribute: 373 pkcs-9-at-emailAddress OBJECT IDENTIFIER ::= 374 { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 } 376 Note that this attribute MUST be encoded as IA5String and has an 377 upper bound of 255 characters. The right side of the email address 378 SHOULD be treated as ASCII-case-insensitive. 380 Sending agents SHOULD make the address in the From or Sender header 381 in a mail message match an Internet mail address in the signer's 382 certificate. Receiving agents MUST check that the address in the 383 From or Sender header of a mail message matches an Internet mail 384 address, if present, in the signer's certificate, if mail addresses 385 are present in the certificate. A receiving agent SHOULD provide 386 some explicit alternate processing of the message if this comparison 387 fails, which may be to display a message that shows the recipient the 388 addresses in the certificate or other certificate details. 390 A receiving agent SHOULD display a subject name or other certificate 391 details when displaying an indication of successful or unsuccessful 392 signature verification. 394 All subject and issuer names MUST be populated (i.e., not an empty 395 SEQUENCE) in S/MIME-compliant X.509 certificates, except that the 396 subject distinguished name (DN) in a user's (i.e., end-entity) 397 certificate MAY be an empty SEQUENCE in which case the subjectAltName 398 extension will include the subject's identifier and MUST be marked as 399 critical. 401 4. Certificate Processing 403 S/MIME agents need to provide some certificate retrieval mechanism in 404 order to gain access to certificates for recipients of digital 405 envelopes. There are many ways to implement certificate retrieval 406 mechanisms. [X.500] directory service is an excellent example of a 407 certificate retrieval-only mechanism that is compatible with classic 408 X.500 Distinguished Names. Another method under consideration by the 409 IETF is to provide certificate retrieval services as part of the 410 existing Domain Name System (DNS). Until such mechanisms are widely 411 used, their utility may be limited by the small number of the 412 correspondent's certificates that can be retrieved. At a minimum, 413 for initial S/MIME deployment, a user agent could automatically 414 generate a message to an intended recipient requesting the 415 recipient's certificate in a signed return message. 417 Receiving and sending agents SHOULD also provide a mechanism to allow 418 a user to "store and protect" certificates for correspondents in such 419 a way so as to guarantee their later retrieval. In many 420 environments, it may be desirable to link the certificate retrieval/ 421 storage mechanisms together in some sort of certificate database. In 422 its simplest form, a certificate database would be local to a 423 particular user and would function in a similar way as an "address 424 book" that stores a user's frequent correspondents. In this way, the 425 certificate retrieval mechanism would be limited to the certificates 426 that a user has stored (presumably from incoming messages). A 427 comprehensive certificate retrieval/storage solution may combine two 428 or more mechanisms to allow the greatest flexibility and utility to 429 the user. For instance, a secure Internet mail agent may resort to 430 checking a centralized certificate retrieval mechanism for a 431 certificate if it cannot be found in a user's local certificate 432 storage/retrieval database. 434 Receiving and sending agents SHOULD provide a mechanism for the 435 import and export of certificates, using a CMS certs-only message. 436 This allows for import and export of full certificate chains as 437 opposed to just a single certificate. This is described in 438 [RFC5751]. 440 Agents MUST handle multiple valid certification authority (CA) 441 certificates containing the same subject name and the same public 442 keys but with overlapping validity intervals. 444 4.1. Certificate Revocation Lists 446 In general, it is always better to get the latest CRL information 447 from a CA than to get information stored away from incoming messages. 448 A receiving agent SHOULD have access to some CRL retrieval mechanism 449 in order to gain access to certificate revocation information when 450 validating certification paths. A receiving or sending agent SHOULD 451 also provide a mechanism to allow a user to store incoming 452 certificate revocation information for correspondents in such a way 453 so as to guarantee its later retrieval. 455 Receiving and sending agents SHOULD retrieve and utilize CRL 456 information every time a certificate is verified as part of a 457 certification path validation even if the certificate was already 458 verified in the past. However, in many instances (such as off-line 459 verification) access to the latest CRL information may be difficult 460 or impossible. The use of CRL information, therefore, may be 461 dictated by the value of the information that is protected. The 462 value of the CRL information in a particular context is beyond the 463 scope of this specification but may be governed by the policies 464 associated with particular certification paths. 466 All agents MUST be capable of performing revocation checks using CRLs 467 as specified in [RFC5280]. All agents MUST perform revocation status 468 checking in accordance with [RFC5280]. Receiving agents MUST 469 recognize CRLs in received S/MIME messages. 471 4.2. Certificate Path Validation 473 In creating a user agent for secure messaging, certificate, CRL, and 474 certification path validation SHOULD be highly automated while still 475 acting in the best interests of the user. Certificate, CRL, and path 476 validation MUST be performed as per [RFC5280] when validating a 477 correspondent's public key. This is necessary before using a public 478 key to provide security services such as verifying a signature, 479 encrypting a content-encryption key (e.g., RSA), or forming a 480 pairwise symmetric key (e.g., Diffie-Hellman) to be used to encrypt 481 or decrypt a content-encryption key. 483 Certificates and CRLs are made available to the path validation 484 procedure in two ways: a) incoming messages, and b) certificate and 485 CRL retrieval mechanisms. Certificates and CRLs in incoming messages 486 are not required to be in any particular order nor are they required 487 to be in any way related to the sender or recipient of the message 488 (although in most cases they will be related to the sender). 489 Incoming certificates and CRLs SHOULD be cached for use in path 490 validation and optionally stored for later use. This temporary 491 certificate and CRL cache SHOULD be used to augment any other 492 certificate and CRL retrieval mechanisms for path validation on 493 incoming signed messages. 495 When verifying a signature and the certificates that are included in 496 the message, if a signingCertificate attribute from RFC 2634 [ESS] or 497 a signingCertificateV2 attribute from RFC 5035 [ESS] is found in an 498 S/MIME message, it SHALL be used to identify the signer's 499 certificate. Otherwise, the certificate is identified in an S/MIME 500 message, either using the issuerAndSerialNumber, which identifies the 501 signer's certificate by the issuer's distinguished name and the 502 certificate serial number, or the subjectKeyIdentifier, which 503 identifies the signer's certificate by a key identifier. 505 When decrypting an encrypted message, if a 506 SMIMEEncryptionKeyPreference attribute is found in an encapsulating 507 SignedData, it SHALL be used to identify the originator's certificate 508 found in OriginatorInfo. See [RFC5652] for the CMS fields that 509 reference the originator's and recipient's certificates. 511 4.3. Certificate and CRL Signing Algorithms and Key Sizes 513 Certificates and Certificate Revocation Lists (CRLs) are signed by 514 the certificate issuer. Receiving agents: 516 - MUST support ECDSA with curve P-256 with SHA-256. 518 - MUST support EdDSA with curve 25519 using PureEdDSA mode. 520 - MUST- support RSA with SHA-256. 522 - SHOULD support RSASSA-PSS with SHA-256. 524 - MUST NOT support EdDSA using Pre-hash mode. 526 The following are the RSA and RSASSA-PSS key size requirements for 527 S/MIME receiving agents during certificate and CRL signature 528 verification: 530 key size <= 2047 : SHOULD NOT (see Historic Considerations) 531 2048 <= key size <= 4096 : MUST (see Security Considerations) 532 4096 < key size : MAY (see Security Considerations) 534 For 512-bit RSA with SHA-1 see [RFC3279] and [FIPS186-2] without 535 Change Notice 1, for 512-bit RSA with SHA-256 see [RFC4055] and 536 [FIPS186-2] without Change Notice 1, for 1024-bit through 3072-bit 537 RSA with SHA-256 see [RFC4055] and [FIPS186-2] with Change Notice 1, 538 and for 4096-bit RSA with SHA-256 see [RFC4055] and [RFC3447]. In 539 either case, the first reference provides the signature algorithm's 540 object identifier and the second provides the signature algorithm's 541 definition. 543 For 512-bit DSA with SHA-1 see [RFC3279] and [FIPS186-2] without 544 Change Notice 1, for 512-bit DSA with SHA-256 see [RFC5758] and 545 [FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see 546 [RFC3279] and [FIPS186-2] with Change Notice 1, for 1024-bit through 547 3072 DSA with SHA-256 see [RFC5758] and [FIPS186-3]. In either case, 548 the first reference provides the signature algorithm's object 549 identifier and the second provides the signature algorithm's 550 definition. 552 For RSASSA-PSS with SHA-256 see [RFC4056]. 554 4.4. PKIX Certificate Extensions 556 PKIX describes an extensible framework in which the basic certificate 557 information can be extended and describes how such extensions can be 558 used to control the process of issuing and validating certificates. 559 The PKIX Working Group has ongoing efforts to identify and create 560 extensions that have value in particular certification environments. 561 Further, there are active efforts underway to issue PKIX certificates 562 for business purposes. This document identifies the minimum required 563 set of certificate extensions that have the greatest value in the 564 S/MIME environment. The syntax and semantics of all the identified 565 extensions are defined in [RFC5280]. 567 Sending and receiving agents MUST correctly handle the basic 568 constraints, key usage, authority key identifier, subject key 569 identifier, and subject alternative names certificate extensions when 570 they appear in end-entity and CA certificates. Some mechanism SHOULD 571 exist to gracefully handle other certificate extensions when they 572 appear in end-entity or CA certificates. 574 Certificates issued for the S/MIME environment SHOULD NOT contain any 575 critical extensions (extensions that have the critical field set to 576 TRUE) other than those listed here. These extensions SHOULD be 577 marked as non-critical unless the proper handling of the extension is 578 deemed critical to the correct interpretation of the associated 579 certificate. Other extensions may be included, but those extensions 580 SHOULD NOT be marked as critical. 582 Interpretation and syntax for all extensions MUST follow [RFC5280], 583 unless otherwise specified here. 585 4.4.1. Basic Constraints 587 The basic constraints extension serves to delimit the role and 588 position that an issuing authority or end-entity certificate plays in 589 a certification path. 591 For example, certificates issued to CAs and subordinate CAs contain a 592 basic constraint extension that identifies them as issuing authority 593 certificates. End-entity certificates contain the key usage 594 extension that restrains end entities from using the key when 595 performing issuing authority operations (see Section 4.4.2). 597 As per [RFC5280], certificates MUST contain a basicConstraints 598 extension in CA certificates, and SHOULD NOT contain that extension 599 in end- entity certificates. 601 4.4.2. Key Usage Certificate Extension 603 The key usage extension serves to limit the technical purposes for 604 which a public key listed in a valid certificate may be used. 605 Issuing authority certificates may contain a key usage extension that 606 restricts the key to signing certificates, certificate revocation 607 lists, and other data. 609 For example, a certification authority may create subordinate issuer 610 certificates that contain a key usage extension that specifies that 611 the corresponding public key can be used to sign end user 612 certificates and sign CRLs. 614 If a key usage extension is included in a PKIX certificate, then it 615 MUST be marked as critical. 617 S/MIME receiving agents MUST NOT accept the signature of a message if 618 it was verified using a certificate that contains the key usage 619 extension without either the digitalSignature or nonRepudiation bit 620 set. Sometimes S/MIME is used as a secure message transport for 621 applications beyond interpersonal messaging. In such cases, the 622 S/MIME-enabled application can specify additional requirements 623 concerning the digitalSignature or nonRepudiation bits within this 624 extension. 626 If the key usage extension is not specified, receiving clients MUST 627 presume that the digitalSignature and nonRepudiation bits are set. 629 4.4.3. Subject Alternative Name 631 The subject alternative name extension is used in S/MIME as the 632 preferred means to convey the email address(es) that correspond(s) to 633 the entity for this certificate. Any email addresses present MUST be 634 encoded using the rfc822Name CHOICE of the GeneralName type as 635 described in [RFC5280], Section 4.2.1.6. Since the SubjectAltName 636 type is a SEQUENCE OF GeneralName, multiple email addresses MAY be 637 present. 639 4.4.4. Extended Key Usage Extension 641 The extended key usage extension also serves to limit the technical 642 purposes for which a public key listed in a valid certificate may be 643 used. The set of technical purposes for the certificate therefore 644 are the intersection of the uses indicated in the key usage and 645 extended key usage extensions. 647 For example, if the certificate contains a key usage extension 648 indicating digital signature and an extended key usage extension that 649 includes the email protection OID, then the certificate may be used 650 for signing but not encrypting S/MIME messages. If the certificate 651 contains a key usage extension indicating digital signature but no 652 extended key usage extension, then the certificate may also be used 653 to sign but not encrypt S/MIME messages. 655 If the extended key usage extension is present in the certificate, 656 then interpersonal message S/MIME receiving agents MUST check that it 657 contains either the emailProtection or the anyExtendedKeyUsage OID as 658 defined in [RFC5280]. S/MIME uses other than interpersonal messaging 659 MAY require the explicit presence of the extended key usage extension 660 or other OIDs to be present in the extension or both. 662 5. Security Considerations 664 All of the security issues faced by any cryptographic application 665 must be faced by a S/MIME agent. Among these issues are protecting 666 the user's private key, preventing various attacks, and helping the 667 user avoid mistakes such as inadvertently encrypting a message for 668 the wrong recipient. The entire list of security considerations is 669 beyond the scope of this document, but some significant concerns are 670 listed here. 672 When processing certificates, there are many situations where the 673 processing might fail. Because the processing may be done by a user 674 agent, a security gateway, or other program, there is no single way 675 to handle such failures. Just because the methods to handle the 676 failures have not been listed, however, the reader should not assume 677 that they are not important. The opposite is true: if a certificate 678 is not provably valid and associated with the message, the processing 679 software should take immediate and noticeable steps to inform the end 680 user about it. 682 Some of the many places where signature and certificate checking 683 might fail include: 685 - no Internet mail addresses in a certificate match the sender of a 686 message, if the certificate contains at least one mail address 688 - no certificate chain leads to a trusted CA 690 - no ability to check the CRL for a certificate 692 - an invalid CRL was received 694 - the CRL being checked is expired 696 - the certificate is expired 698 - the certificate has been revoked 700 There are certainly other instances where a certificate may be 701 invalid, and it is the responsibility of the processing software to 702 check them all thoroughly, and to decide what to do if the check 703 fails. 705 It is possible for there to be multiple unexpired CRLs for a CA. If 706 an agent is consulting CRLs for certificate validation, it SHOULD 707 make sure that the most recently issued CRL for that CA is consulted, 708 since an S/MIME message sender could deliberately include an older 709 unexpired CRL in an S/MIME message. This older CRL might not include 710 recently revoked certificates, which might lead an agent to accept a 711 certificate that has been revoked in a subsequent CRL. 713 When determining the time for a certificate validity check, agents 714 have to be careful to use a reliable time. Unless it is from a 715 trusted agent, this time MUST NOT be the SigningTime attribute found 716 in an S/MIME message. For most sending agents, the SigningTime 717 attribute could be deliberately set to direct the receiving agent to 718 check a CRL that could have out-of-date revocation status for a 719 certificate, or cause an improper result when checking the Validity 720 field of a certificate. 722 In addition to the Security Considerations identified in [RFC5280], 723 caution should be taken when processing certificates that have not 724 first been validated to a trust anchor. Certificates could be 725 manufactured by untrusted sources for the purpose of mounting denial 726 of service or other attacks. For example, keys selected to require 727 excessive cryptographic processing, or extensive lists of CRL 728 Distribution Point (CDP) and/or Authority Information Access (AIA) 729 addresses in the certificate, could be used to mount denial-of- 730 service attacks. Similarly, attacker-specified CDP and/or AIA 731 addresses could be included in fake certificates to allow the 732 originator to detect receipt of the message even if signature 733 verification fails. 735 The 4096-bit RSA key size requirement for certificate and CRL 736 verification is larger than the 2048-bit RSA key sizes for message 737 signature generation/verification or message encryption/decryption in 738 [RFC5751] because many root CAs included in certificate stores have 739 already issued root certificates with the 4096-bit key. The standard 740 that defines comparable key sizes for DSA is not yet available. In 741 particular, [FIPS186-2] without Change Notice 1 allowed DSA key sizes 742 between 512 and 1024 bits, [FIPS186-2] with Change Notice 1 only 743 allowed DSA key sizes of 1024 bits, and [FIPS186-3] allowed DSA key 744 sizes from 1024 to 3072 bits. Further, 4096-bit keys are normally 745 only used by Root certificates and not by subordinate CA 746 certificates, thereby lengthening the root CA certificate's validity 747 period. 749 RSA and DSA keys of less than 2048 bits are now considered by many 750 experts to be cryptographically insecure (due to advances in 751 computing power), and should no longer be used to sign certificates 752 or CRLs. Such keys were previously considered secure, so processing 753 previously received signed and encrypted mail may require processing 754 certificates or CRLs signed with weak keys. Implementations that 755 wish to support previous versions of S/MIME or process old messages 756 need to consider the security risks that result from accepting 757 certificates and CRLs with smaller key sizes (e.g., spoofed 758 certificates) versus the costs of denial of service. If an 759 implementation supports verification of certificates or CRLs 760 generated with RSA and DSA keys of less than 2048 bits, it MUST warn 761 the user. Implementers should consider providing a stronger warning 762 for weak signatures on certificates and CRLs associated with newly 763 received messages than the one provided for certificates and CRLs 764 associated with previously stored messages. Server implementations 765 (e.g., secure mail list servers) where user warnings are not 766 appropriate SHOULD reject messages with weak cryptography. 768 If an implementation is concerned about compliance with National 769 Institute of Standards and Technology (NIST) key size 770 recommendations, then see [SP800-57]. 772 6. References 774 6.1. Normative References 776 [FIPS186-2] 777 National Institute of Standards and Technology (NIST), 778 "Digital Signature Standard (DSS) [With Change Notice 1]", 779 Federal Information Processing Standards 780 Publication 186-2, January 2000. 782 [FIPS186-3] 783 National Institute of Standards and Technology (NIST), 784 "Digital Signature Standard (DSS)", Federal Information 785 Processing Standards Publication 186-3, June 2009. 787 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 788 Requirement Levels", BCP 14, RFC 2119, 789 DOI 10.17487/RFC2119, March 1997, 790 . 792 [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", 793 RFC 2634, DOI 10.17487/RFC2634, June 1999, 794 . 796 [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object 797 Classes and Attribute Types Version 2.0", RFC 2985, 798 DOI 10.17487/RFC2985, November 2000, 799 . 801 [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and 802 Identifiers for the Internet X.509 Public Key 803 Infrastructure Certificate and Certificate Revocation List 804 (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April 805 2002, . 807 [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography 808 Standards (PKCS) #1: RSA Cryptography Specifications 809 Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February 810 2003, . 812 [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional 813 Algorithms and Identifiers for RSA Cryptography for use in 814 the Internet X.509 Public Key Infrastructure Certificate 815 and Certificate Revocation List (CRL) Profile", RFC 4055, 816 DOI 10.17487/RFC4055, June 2005, 817 . 819 [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in 820 Cryptographic Message Syntax (CMS)", RFC 4056, 821 DOI 10.17487/RFC4056, June 2005, 822 . 824 [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: 825 Adding CertID Algorithm Agility", RFC 5035, 826 DOI 10.17487/RFC5035, August 2007, 827 . 829 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 830 Housley, R., and W. Polk, "Internet X.509 Public Key 831 Infrastructure Certificate and Certificate Revocation List 832 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 833 . 835 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 836 RFC 5652, DOI 10.17487/RFC5652, September 2009, 837 . 839 [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 840 Mail Extensions (S/MIME) Version 3.2 Certificate 841 Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, 842 . 844 [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet 845 Mail Extensions (S/MIME) Version 3.2 Message 846 Specification", RFC 5751, DOI 10.17487/RFC5751, January 847 2010, . 849 [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet 850 Attribute Certificate Profile for Authorization", 851 RFC 5755, DOI 10.17487/RFC5755, January 2010, 852 . 854 [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. 855 Polk, "Internet X.509 Public Key Infrastructure: 856 Additional Algorithms and Identifiers for DSA and ECDSA", 857 RFC 5758, DOI 10.17487/RFC5758, January 2010, 858 . 860 [SMIMEv3.5] 861 "S/MIME version 3.5". 863 This group of documents represents S/MIME version 3.5. 864 This set of documents are [RFC2634], [RFC5750], [[This 865 Document]], [RFC5652], and [RFC5035]. 867 [X.680] "Information Technology - Abstract Syntax Notation One 868 (ASN.1): Specification of basic notation. ITU-T 869 Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.". 871 6.2. Informational References 873 [ESS] "Enhanced Security Services for S/ MIME". 875 This is the set of documents dealing with enhanged 876 security services and refers to [RFC2634] and [RFC5035]. 878 [PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax 879 Standard", November 1993. 881 [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and 882 L. Repka, "S/MIME Version 2 Message Specification", 883 RFC 2311, DOI 10.17487/RFC2311, March 1998, 884 . 886 [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, 887 "S/MIME Version 2 Certificate Handling", RFC 2312, 888 DOI 10.17487/RFC2312, March 1998, 889 . 891 [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", 892 RFC 2313, DOI 10.17487/RFC2313, March 1998, 893 . 895 [RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax 896 Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998, 897 . 899 [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax 900 Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, 901 . 903 [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, 904 DOI 10.17487/RFC2630, June 1999, 905 . 907 [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", 908 RFC 2631, DOI 10.17487/RFC2631, June 1999, 909 . 911 [RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate 912 Handling", RFC 2632, DOI 10.17487/RFC2632, June 1999, 913 . 915 [RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message 916 Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999, 917 . 919 [RFC3114] Nicolls, W., "Implementing Company Classification Policy 920 with the S/MIME Security Label", RFC 3114, 921 DOI 10.17487/RFC3114, May 2002, 922 . 924 [RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail 925 Extensions (S/MIME) Version 3.1 Certificate Handling", 926 RFC 3850, DOI 10.17487/RFC3850, July 2004, 927 . 929 [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail 930 Extensions (S/MIME) Version 3.1 Message Specification", 931 RFC 3851, DOI 10.17487/RFC3851, July 2004, 932 . 934 [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", 935 RFC 3852, DOI 10.17487/RFC3852, July 2004, 936 . 938 [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations 939 for the MD5 Message-Digest and the HMAC-MD5 Algorithms", 940 RFC 6151, DOI 10.17487/RFC6151, March 2011, 941 . 943 [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security 944 Considerations for the SHA-0 and SHA-1 Message-Digest 945 Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, 946 . 948 [SMIMEv2] "S/MIME version v2". 950 This group of documents represents S/MIME version 2. This 951 set of documents are [RFC2311], [RFC2312], [RFC2313], 952 [RFC2314], and [RFC2315]. 954 [SMIMEv3] "S/MIME version 3". 956 This group of documents represents S/MIME version 3. This 957 set of documents are [RFC2630], [RFC2631], [RFC2632], 958 [RFC2633], [RFC2634], and [RFC5035]. 960 [SMIMEv3.1] 961 "S/MIME version 3.1". 963 This group of documents represents S/MIME version 3.1. 964 This set of documents are [RFC2634], [RFC3850], [RFC3851], 965 [RFC3852], and [RFC5035]. 967 [SP800-57] 968 National Institute of Standards and Technology (NIST), 969 "Special Publication 800-57: Recommendation for Key 970 Management", August 2005. 972 [X.500] "ITU-T Recommendation X.500 (1997) | ISO/IEC 9594- 1:1997, 973 Information technology - Open Systems Interconnection - 974 The Directory: Overview of concepts, models and 975 services.". 977 Appendix A. Historic Considerations 979 A.1. Signature Algorithms and Key Sizes 981 There are a number of problems with validating certificates on 982 sufficiently historic messages. For this reason it is strongly 983 suggested that UAs treat these certificates differently from those on 984 current messages. These problems include: 986 - CAs are not required to keep certificates on a CRL beyond one 987 update after a certificate has expired. This means that unless 988 CRLs are cached as part of the message it is not always possible 989 to check if a certificate has been revoked. The same problems 990 exist with OCSP responses as they may be based on a CRL rather 991 than on the certificate database. 993 - RSA and DSA keys of less than 2048 bits are now considered by many 994 experts to be cryptographically insecure (due to advances in 995 computing power). Such keys were previously considered secure, so 996 processing of historic certificates will often result in the use 997 of weak keys. Implementations that wish to support previous 998 versions of S/MIME or process old messages need to consider the 999 security risks that result from smaller key sizes (e.g., spoofed 1000 messages) versus the costs of denial of service. 1002 [SMIMEv3.1] set the lower limit on suggested key sizes for 1003 creating and validation at 1024 bits. Prior to that the lower 1004 bound on key sizes was 512 bits. 1006 - Hash functions used to validate signatures on historic messages 1007 may longer be considered to be secure (see below). While there 1008 are not currently any known practical pre-image or second pre- 1009 image attacks against MD5 or SHA-1, the fact they are no longer 1010 considered to be collision resistent the security levels of the 1011 signatures are generally considered suspect. 1013 The following algorithms have been called out for some level of 1014 support by previous S/MIME specifications: 1016 - RSA with MD5 was dropped in [SMIMEv3.5]. MD5 is no longer 1017 considered to be secure as it is no longer collision-resistant. 1018 Details can be found in [RFC6151]. 1020 - RSA and DSA with SHA-1 were dropped in [SMIMEv3.5]. SHA-1 is 1021 nolonger considered to be secure as it is no longer collision- 1022 resistant. The IETF statement on SHA-1 can be found in [RFC6194] 1023 but it is out-of-date relative to the most recent advances. 1025 - SHOULD+ support DSA with SHA-256 1027 Appendix B. Moving S/MIME v2 Certificate Handling to Historic Status 1029 The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document) 1030 are backwards compatible with the S/MIME v2 Certificate Handling 1031 Specification [SMIMEv2], with the exception of the algorithms 1032 (dropped RC2/40 requirement and added DSA and RSASSA-PSS 1033 requirements). Therefore, it is recommended that RFC 2312 [SMIMEv2] 1034 be moved to Historic status. 1036 Appendix C. Acknowledgments 1038 Many thanks go out to the other authors of the S/MIME v2 RFC: Steve 1039 Dusse, Paul Hoffman, and Jeff Weinstein. Without v2, there wouldn't 1040 be a v3, v3.1, or v3.2. 1042 A number of the members of the S/MIME Working Group have also worked 1043 very hard and contributed to this document. Any list of people is 1044 doomed to omission, and for that I apologize. In alphabetical order, 1045 the following people stand out in my mind because they made direct 1046 contributions to this document. 1048 Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Alfred Hoenes, Paul 1049 Hoffman, Russ Housley, David P. Kemp, Michael Myers, John Pawling, 1050 Denis Pinkas, and Jim Schaad. 1052 Authors' Addresses 1054 Jim Schaad 1055 August Cellars 1057 Email: ietf@augustcellars.com 1059 Blake Ramsdell 1060 Brute Squad Labs, Inc. 1062 Email: blaker@gmail.com 1064 Sean Turner 1065 sn3rd 1067 Email: sean@sn3rd.com