--- 1/draft-ietf-lamps-rfc5750-bis-06.txt 2018-06-21 12:13:21.596251279 -0700 +++ 2/draft-ietf-lamps-rfc5750-bis-07.txt 2018-06-21 12:13:21.656252729 -0700 @@ -1,22 +1,22 @@ LAMPS J. Schaad Internet-Draft August Cellars Obsoletes: 5750 (if approved) B. Ramsdell Intended status: Standards Track Brute Squad Labs, Inc. -Expires: November 3, 2018 S. Turner +Expires: December 23, 2018 S. Turner sn3rd - May 2, 2018 + June 21, 2018 Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0 Certificate Handling - draft-ietf-lamps-rfc5750-bis-06 + draft-ietf-lamps-rfc5750-bis-07 Abstract This document specifies conventions for X.509 certificate usage by Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. S/MIME provides a method to send and receive secure MIME messages, and certificates are an integral part of S/MIME agent processing. S/MIME agents validate certificates as described in RFC 5280, the Internet X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME agents must meet the certificate processing requirements in @@ -38,21 +38,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 3, 2018. + This Internet-Draft will expire on December 23, 2018. Copyright Notice Copyright (c) 2018 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -78,25 +78,25 @@ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.2. Conventions Used in This Document . . . . . . . . . . . . 4 1.3. Compatibility with Prior Practice S/MIME . . . . . . . . 5 1.4. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 5 1.5. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 6 1.6. Changes since S/MIME 3.2 . . . . . . . . . . . . . . . . 7 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1. Certificate Revocation Lists . . . . . . . . . . . . . . 7 - 2.2. Certificate Choices . . . . . . . . . . . . . . . . . . . 7 + 2.2. Certificate Choices . . . . . . . . . . . . . . . . . . . 8 2.2.1. Historical Note about CMS Certificates . . . . . . . 8 2.3. CertificateSet . . . . . . . . . . . . . . . . . . . . . 8 3. Using Distinguished Names for Internet Mail . . . . . . . . . 9 - 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 10 + 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 11 4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 11 4.2. Certificate Path Validation . . . . . . . . . . . . . . . 12 4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 13 4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 14 4.4.1. Basic Constraints . . . . . . . . . . . . . . . . . . 14 4.4.2. Key Usage Certificate Extension . . . . . . . . . . . 15 4.4.3. Subject Alternative Name . . . . . . . . . . . . . . 15 4.4.4. Extended Key Usage Extension . . . . . . . . . . . . 16 5. IANA Considertions . . . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 @@ -192,41 +192,46 @@ MUST- This term means the same as MUST. However, the authors expect that this requirement will no longer be a MUST in a future document. Although its status will be determined at a later time, it is reasonable to expect that if a future revision of a document alters the status of a MUST- requirement, it will remain at least a SHOULD or a SHOULD-. The term RSA in this document almost always refers to the PKCS#1 v1.5 RSA signature algorithm even when not qualified as such. There are a couple of places where it refers to the general RSA cryptographic - operation, these can be determined from the context where it is used. + operation; these can be determined from the context where it is used. 1.3. Compatibility with Prior Practice S/MIME S/MIME version 4.0 agents ought to attempt to have the greatest interoperability possible with agents for prior versions of S/MIME. S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive and RFC 5035 [SMIMEv3], and S/MIME version 3.1 is described in RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1]. RFC 2311 also has historical information about the development of S/MIME. Appendix A contains information about algorithms that were used for prior versions of S/MIME but are no longer considered to meet modern security standards. Support of these algorithms may be needed to - support historic S/MIME messages but SHOULD NOT be used for new mail. + support historic S/MIME artifacts such as messages or files, but + SHOULD NOT be used for new artifacts. 1.4. Changes from S/MIME v3 to S/MIME v3.1 + This section reflects the changes that were made when S/MIME v3.1 was + released. The RFC2119 langauage may have superceeded in later + versions. + Version 1 and version 2 CRLs MUST be supported. Multiple certification authority (CA) certificates with the same subject and public key, but with overlapping validity periods, MUST be supported. Version 2 attribute certificates SHOULD be supported, and version 1 attributes certificates MUST NOT be used. The use of the MD2 digest algorithm for certificate signatures is @@ -241,20 +246,24 @@ Receiving agents MUST NOT accept a signature made with a certificate that does not have at least one of the the digitalSignature or nonRepudiation bits set. Clarifications for the interpretation of the key usage and extended key usage extensions. 1.5. Changes from S/MIME v3.1 to S/MIME v3.2 + This section reflects the changes that were made when S/MIME v3.2 was + released. The RFC2119 langauage may have superceeded in later + versions. + Conventions Used in This Document: Moved to Section 1.2. Added definitions for SHOULD+, SHOULD-, and MUST-. Section 1.1: Updated ASN.1 definition and reference. Section 1.3: Added text about v3.1 RFCs. Section 3: Aligned email address text with RFC 5280. Updated note to indicate emailAddress IA5String upper bound is 255 characters. Added text about matching email addresses. @@ -276,37 +285,42 @@ Section 5: Updated security considerations. Section 7: Moved references from Appendix B to Section 6. Updated the references. Appendix A: Moved Appendix A to Appendix B. Added Appendix A to move S/MIME v2 Certificate Handling to Historic Status. 1.6. Changes since S/MIME 3.2 + This section reflects the changes that were made when S/MIME v4.0 was + released. The RFC2119 langauage may have superceeded in later + versions. + Section 3: Require support for internationalized email addresses. Section 4.3: Mandated support for ECDSA with P-256 and Ed25519. Moved algorithms with SHA-1 and MD5 to historical status. Moved DSA support to historical status. Increased lower bounds on RSA key sizes. Appendix A: Add a new appendix for algorithms that are now considered to be historical. 2. CMS Options The CMS message format allows for a wide variety of options in content and algorithm support. This section puts forth a number of support requirements and recommendations in order to achieve a base level of interoperability among all S/MIME implementations. Most of - the CMS format for S/MIME messages is defined in [RFC5751]. + the CMS format for S/MIME messages is defined in + [I-D.ietf-lamps-rfc5751-bis]. 2.1. Certificate Revocation Lists Receiving agents MUST support the Certificate Revocation List (CRL) format defined in [RFC5280]. If sending agents include CRLs in outgoing messages, the CRL format defined in [RFC5280] MUST be used. Receiving agents MUST support both v1 and v2 CRLs. All agents MUST be capable of performing revocation checks using CRLs as specified in [RFC5280]. All agents MUST perform revocation status @@ -329,21 +343,21 @@ 2.2.1. Historical Note about CMS Certificates The CMS message format supports a choice of certificate formats for public key content types: PKIX, PKCS #6 extended certificates [PKCS6], and PKIX attribute certificates. The PKCS #6 format is not in widespread use. In addition, PKIX certificate extensions address much of the same functionality and flexibility as was intended in the PKCS #6. Thus, sending and receiving agents MUST NOT use PKCS #6 extended certificates. - Receiving agents MUST be able to parser and process a message + Receiving agents MUST be able to parse and process a message containing PKCS #6 extended certificates although ignoring those certificates is expected behavior. X.509 version 1 attribute certificates are also not widely implemented, and have been superseded with version 2 attribute certificates. Sending agents MUST NOT send version 1 attribute certificates. 2.3. CertificateSet @@ -359,22 +373,22 @@ key(s) and associated issuer certificates. This increases the likelihood that the intended recipient can establish trust in the originator's public key(s). This is especially important when sending a message to recipients that may not have access to the sender's public key through any other means or when sending a signed message to a new recipient. The inclusion of certificates in outgoing messages can be omitted if S/MIME objects are sent within a group of correspondents that has established access to each other's certificates by some other means such as a shared directory or manual certificate distribution. Receiving S/MIME agents SHOULD be able to - handle messages without certificates using a database or directory - lookup scheme. + handle messages without certificates by using a database or directory + lookup scheme to find them. A sending agent SHOULD include at least one chain of certificates up to, but not including, a certification authority (CA) that it believes that the recipient may trust as authoritative. A receiving agent MUST be able to handle an arbitrarily large number of certificates and chains. Agents MAY send CA certificates, that is, cross-certificates, self- issued certificates, and self-signed certificates. Note that receiving agents SHOULD NOT simply trust any self-signed certificates @@ -435,21 +449,21 @@ transformations on the local name component before doing the comparison, however an S/MIME client cannot know what specific localities do. Sending agents SHOULD make the address in the From or Sender header in a mail message match an Internet mail address in the signer's certificate. Receiving agents MUST check that the address in the From or Sender header of a mail message matches an Internet mail address in the signer's certificate, if mail addresses are present in the certificate. A receiving agent SHOULD provide some explicit - alternate processing of the message if this comparison fails, this + alternate processing of the message if this comparison fails; this might be done by displaying or logging a message that shows the recipient the mail addresses in the certificate or other certificate details. A receiving agent SHOULD display a subject name or other certificate details when displaying an indication of successful or unsuccessful signature verification. All subject and issuer names MUST be populated (i.e., not an empty SEQUENCE) in S/MIME-compliant X.509 certificates, except that the @@ -497,23 +511,23 @@ opposed to just a single certificate. This is described in [RFC5751]. Agents MUST handle multiple valid certification authority (CA) certificates containing the same subject name and the same public keys but with overlapping validity intervals. 4.1. Certificate Revocation Lists In general, it is always better to get the latest CRL information - from a CA than to get information stored away from incoming messages. - A receiving agent SHOULD have access to some CRL retrieval mechanism - in order to gain access to certificate revocation information when + from a CA than to get information stored in an incoming messages. A + receiving agent SHOULD have access to some CRL retrieval mechanism in + order to gain access to certificate revocation information when validating certification paths. A receiving or sending agent SHOULD also provide a mechanism to allow a user to store incoming certificate revocation information for correspondents in such a way so as to guarantee its later retrieval. Receiving and sending agents SHOULD retrieve and utilize CRL information every time a certificate is verified as part of a certification path validation even if the certificate was already verified in the past. However, in many instances (such as off-line verification) access to the latest CRL information may be difficult @@ -524,21 +538,21 @@ associated with particular certification paths. All agents MUST be capable of performing revocation checks using CRLs as specified in [RFC5280]. All agents MUST perform revocation status checking in accordance with [RFC5280]. Receiving agents MUST recognize CRLs in received S/MIME messages. 4.2. Certificate Path Validation In creating a user agent for secure messaging, certificate, CRL, and - certification path validation SHOULD be highly automated while still + certification path validation should be highly automated while still acting in the best interests of the user. Certificate, CRL, and path validation MUST be performed as per [RFC5280] when validating a correspondent's public key. This is necessary before using a public key to provide security services such as verifying a signature, encrypting a content-encryption key (e.g., RSA), or forming a pairwise symmetric key (e.g., Diffie-Hellman) to be used to encrypt or decrypt a content-encryption key. Certificates and CRLs are made available to the path validation procedure in two ways: a) incoming messages, and b) certificate and @@ -613,21 +627,21 @@ For EdDSA see [I-D.ietf-curdle-pkix] and [RFC8032]. The first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. Other curves than curve 25519 MAY be used as well. 4.4. PKIX Certificate Extensions PKIX describes an extensible framework in which the basic certificate information can be extended and describes how such extensions can be used to control the process of issuing and validating certificates. - The PKIX Working Group has ongoing efforts to identify and create + The LAMPS Working Group has ongoing efforts to identify and create extensions that have value in particular certification environments. Further, there are active efforts underway to issue PKIX certificates for business purposes. This document identifies the minimum required set of certificate extensions that have the greatest value in the S/MIME environment. The syntax and semantics of all the identified extensions are defined in [RFC5280]. Sending and receiving agents MUST correctly handle the basic constraints, key usage, authority key identifier, subject key identifier, and subject alternative names certificate extensions when @@ -851,22 +865,22 @@ Processing Standards Publication 186-3, June 2009. [I-D.ietf-lamps-eai-addresses] Melnikov, A. and W. Chuang, "Internationalized Email Addresses in X.509 certificates", draft-ietf-lamps-eai- addresses-18 (work in progress), March 2018. [I-D.ietf-lamps-rfc5751-bis] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 - Message Specification", draft-ietf-lamps-rfc5751-bis-08 - (work in progress), May 2018. + Message Specification", draft-ietf-lamps-rfc5751-bis-10 + (work in progress), June 2018. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", RFC 2634, DOI 10.17487/RFC2634, June 1999, . @@ -966,21 +980,21 @@ [ESS] "Enhanced Security Services for S/ MIME". This is the set of documents dealing with enhanced security services and refers to [RFC2634] and [RFC5035]. [I-D.ietf-curdle-pkix] Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed448, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure", draft-ietf-curdle- - pkix-09 (work in progress), April 2018. + pkix-10 (work in progress), May 2018. [PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax Standard", November 1993. [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and L. Repka, "S/MIME Version 2 Message Specification", RFC 2311, DOI 10.17487/RFC2311, March 1998, . [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, @@ -1115,22 +1129,23 @@ messages) versus the costs of denial of service. [SMIMEv3.1] set the lower limit on suggested key sizes for creating and validation at 1024 bits. Prior to that the lower bound on key sizes was 512 bits. - Hash functions used to validate signatures on historic messages may longer be considered to be secure (see below). While there are not currently any known practical pre-image or second pre- image attacks against MD5 or SHA-1, the fact they are no longer - considered to be collision resistant the security levels of the - signatures are generally considered suspect. + considered to be collision resistant implies that the security + level of any signature that is created with that these hash + algorithms should also be considered as suspect. The following algorithms have been called out for some level of support by previous S/MIME specifications: - RSA with MD5 was dropped in [SMIMEv4.0]. MD5 is no longer considered to be secure as it is no longer collision-resistant. Details can be found in [RFC6151]. - RSA and DSA with SHA-1 were dropped in [SMIMEv4.0]. SHA-1 is no longer considered to be secure as it is no longer collision-