--- 1/draft-ietf-lamps-rfc5750-bis-01.txt 2017-02-23 15:13:09.666695474 -0800 +++ 2/draft-ietf-lamps-rfc5750-bis-02.txt 2017-02-23 15:13:09.714696614 -0800 @@ -1,22 +1,22 @@ LAMPS J. Schaad Internet-Draft August Cellars Intended status: Standards Track B. Ramsdell -Expires: May 2, 2017 Brute Squad Labs, Inc. +Expires: August 27, 2017 Brute Squad Labs, Inc. S. Turner sn3rd - October 29, 2016 + February 23, 2017 Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0 Certificate Handling - draft-ietf-lamps-rfc5750-bis-01 + draft-ietf-lamps-rfc5750-bis-02 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,25 +38,25 @@ 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 http://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 May 2, 2017. + This Internet-Draft will expire on August 27, 2017. Copyright Notice - Copyright (c) 2016 IETF Trust and the persons identified as the + Copyright (c) 2017 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 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as @@ -93,21 +93,21 @@ 4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 11 4.2. Certificate Path Validation . . . . . . . . . . . . . . . 11 4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 12 4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 13 4.4.1. Basic Constraints . . . . . . . . . . . . . . . . . . 14 4.4.2. Key Usage Certificate Extension . . . . . . . . . . . 14 4.4.3. Subject Alternative Name . . . . . . . . . . . . . . 15 4.4.4. Extended Key Usage Extension . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 - 6.1. Normative References . . . . . . . . . . . . . . . . . . 18 + 6.1. Normative References . . . . . . . . . . . . . . . . . . 17 6.2. Informational References . . . . . . . . . . . . . . . . 20 Appendix A. Historic Considerations . . . . . . . . . . . . . . 23 A.1. Signature Algorithms and Key Sizes . . . . . . . . . . . 23 Appendix B. Moving S/MIME v2 Certificate Handling to Historic Status . . . . . . . . . . . . . . . . . . . . . . . 24 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 1. Introduction @@ -264,21 +264,21 @@ 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 Section 3: Require support for internationalized email addresses. - Section 4.3: Mandated support for ECDSA for P-256 and Ed25519. + 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 @@ -376,46 +376,47 @@ Receiving agents SHOULD support the decoding of X.509 attribute certificates included in CMS objects. All other issues regarding the generation and use of X.509 attribute certificates are outside of the scope of this specification. One specification that addresses attribute certificate use is defined in [RFC3114]. 3. Using Distinguished Names for Internet Mail End-entity certificates MAY contain an Internet mail address. Email - addresses retricted to US-ASCII characters are encoded as described - in Section 4.2.1.6 of [RFC5280]. Internationalized Email address - names are encoded as described in [I-D.ietf-lamps-eai-addresses]. - The email address SHOULD be in the subjectAltName extension, and - SHOULD NOT be in the subject distinguished name. + addresses retricted to 7-bit ASCII characters are encoded as + described in Section 4.2.1.6 of [RFC5280]. Internationalized Email + address names are encoded as described in + [I-D.ietf-lamps-eai-addresses]. The email address SHOULD be in the + subjectAltName extension, and SHOULD NOT be in the subject + distinguished name. Receiving agents MUST recognize and accept certificates that contain no email address. Agents are allowed to provide an alternative mechanism for associating an email address with a certificate that does not contain an email address, such as through the use of the agent's address book, if available. Receiving agents MUST recognize - both US-ASCII and internationalized email addresses in the + both ASCII and internationalized email addresses in the subjectAltName field. Receiving agents MUST recognize email addresses in the Distinguished Name field in the PKCS #9 [RFC2985] emailAddress attribute: pkcs-9-at-emailAddress OBJECT IDENTIFIER ::= { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 } Note that this attribute MUST be encoded as IA5String and has an upper bound of 255 characters. The right side of the email address SHOULD be treated as ASCII-case-insensitive. Comparing of email addresses is fraught with peril. [I-D.ietf-lamps-eai-addresses] defines the procedure for doing - comparison of Internationalized email addresses. For US-ASCII email + comparison of Internationalized email addresses. For ASCII email addresses the domain component (right-hand side of the '@') MUST be compared using a case-insensitive function. The local name component (left-hand side of the '@') SHOULD be compared using a case- insensitive function. Some localities may perform other 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 @@ -578,21 +579,21 @@ For 1024-bit through 3072-bit RSA with SHA-256 see [RFC4055] and [FIPS186-2] with Change Notice 1, and for 4096-bit RSA with SHA-256 see [RFC4055] and [RFC3447]. In either case, the first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. For RSASSA-PSS with SHA-256 see [RFC4056]. For ECDSA see [RFC5758] and [RFC6090]. The first reference provides the signature algorithm's object identifier and the second provides - the signature algorithm's definition. Other curves than durve P-256 + the signature algorithm's definition. Curves other than curve P-256 MAY be used as well. For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. 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 @@ -665,28 +666,27 @@ concerning the digitalSignature or nonRepudiation bits within this extension. If the key usage extension is not specified, receiving clients MUST presume that the digitalSignature and nonRepudiation bits are set. 4.4.3. Subject Alternative Name The subject alternative name extension is used in S/MIME as the preferred means to convey the email address(es) that correspond(s) to - the entity for this certificate. Any US-ASCII email addresses - present MUST be encoded using the rfc822Name CHOICE of the - GeneralName type as described in [RFC5280], Section 4.2.1.6. Any - internationalized email addresses present MUST be encoded using the - otherName CHOICE of the GeneralName type as described in - [I-D.ietf-lamps-eai-addresses], Section 3. Since the SubjectAltName - type is a SEQUENCE OF GeneralName, multiple email addresses MAY be - present. + the entity for this certificate. Any ASCII email addresses present + MUST be encoded using the rfc822Name CHOICE of the GeneralName type + as described in [RFC5280], Section 4.2.1.6. Any internationalized + email addresses present MUST be encoded using the otherName CHOICE of + the GeneralName type as described in [I-D.ietf-lamps-eai-addresses], + Section 3. Since the SubjectAltName type is a SEQUENCE OF + GeneralName, multiple email addresses MAY be present. 4.4.4. Extended Key Usage Extension The extended key usage extension also serves to limit the technical purposes for which a public key listed in a valid certificate may be used. The set of technical purposes for the certificate therefore are the intersection of the uses indicated in the key usage and extended key usage extensions. For example, if the certificate contains a key usage extension @@ -810,27 +811,27 @@ Publication 186-2, January 2000. [FIPS186-3] National Institute of Standards and Technology (NIST), "Digital Signature Standard (DSS)", Federal Information 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-00 (work in progress), July 2016. + addresses-06 (work in progress), February 2017. [I-D.ietf-lamps-rfc5751-bis] Schaad, J., Ramsdell, B., and S. Turner, "Secure/ - Multipurpose Internet Mail Extensions (S/MIME) Version 3.5 - Message Specification", draft-ietf-lamps-rfc5751-bis-01 - (work in progress), August 2016. + Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 + Message Specification", draft-ietf-lamps-rfc5751-bis-02 + (work in progress), October 2016. [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, . @@ -926,21 +927,22 @@ [ESS] "Enhanced Security Services for S/ MIME". This is the set of documents dealing with enhanged security services and refers to [RFC2634] and [RFC5035]. [I-D.ietf-curdle-pkix] Josefsson, S. and J. Schaad, "Algorithm Identifiers for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for use in the Internet X.509 Public Key Infrastructure", - draft-ietf-curdle-pkix-01 (work in progress), August 2016. + draft-ietf-curdle-pkix-03 (work in progress), November + 2016. [I-D.irtf-cfrg-eddsa] Josefsson, S. and I. Liusvaara, "Edwards-curve Digital Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08 (work in progress), August 2016. [PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax Standard", November 1993. [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and