--- 1/draft-ietf-lamps-rfc5750-bis-07.txt 2018-09-04 14:13:15.328151448 -0700 +++ 2/draft-ietf-lamps-rfc5750-bis-08.txt 2018-09-04 14:13:15.384152813 -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: December 23, 2018 S. Turner +Expires: March 8, 2019 S. Turner sn3rd - June 21, 2018 + September 4, 2018 Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0 Certificate Handling - draft-ietf-lamps-rfc5750-bis-07 + draft-ietf-lamps-rfc5750-bis-08 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 December 23, 2018. + This Internet-Draft will expire on March 8, 2019. 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 @@ -82,21 +82,21 @@ 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 . . . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 11 + 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 10 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 @@ -148,24 +148,24 @@ Certificate: A type that binds an entity's name to a public key with a digital signature. This type is defined in the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Profile [RFC5280]. This type also contains the distinguished name of the certificate issuer (the signer), an issuer-specific serial number, the issuer's signature algorithm identifier, a validity period, and extensions also defined in that document. Certificate Revocation List (CRL): A type that contains information - about certificates whose validity an issuer has prematurely revoked. - The information consists of an issuer name, the time of issue, the - next scheduled time of issue, a list of certificate serial numbers - and their associated revocation times, and extensions as defined in + about certificates whose validity an issuer has revoked. The + information consists of an issuer name, the time of issue, the next + scheduled time of issue, a list of certificate serial numbers and + their associated revocation times, and extensions as defined in [RFC5280]. The CRL is signed by the issuer. The type intended by this specification is the one defined in [RFC5280]. Receiving agent: Software that interprets and processes S/MIME CMS objects, MIME body parts that contain CMS objects, or both. Sending agent: Software that creates S/MIME CMS objects, MIME body parts that contain CMS objects, or both. S/MIME agent: User software that is a receiving agent, a sending @@ -429,30 +429,27 @@ agent's address book, if available. Receiving agents MUST recognize 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 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 + upper bound of 255 characters. 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 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 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 @@ -865,22 +862,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-10 - (work in progress), June 2018. + Message Specification", draft-ietf-lamps-rfc5751-bis-11 + (work in progress), July 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, . @@ -1126,21 +1123,21 @@ of weak keys. Implementations that wish to support previous versions of S/MIME or process old messages need to consider the security risks that result from smaller key sizes (e.g., spoofed 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 + may no 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 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 @@ -1169,22 +1166,22 @@ the first reference provides the signature algorithm's object identifier and the second provides the signature algorithm's definition. Appendix B. Moving S/MIME v2 Certificate Handling to Historic Status The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], v3.2 [SMIMEv3.2], and v4.0 (this document) are backward compatible with the S/MIME v2 Certificate Handling Specification [SMIMEv2], with the exception of the algorithms (dropped RC2/40 requirement and added DSA and RSASSA- - PSS requirements). Therefore, it is recommended that RFC 2312 - [SMIMEv2] be moved to Historic status. + PSS requirements). Therefore, RFC 2312 [SMIMEv2] was moved to + Historic status. Appendix C. Acknowledgments Many thanks go out to the other authors of the S/MIME v2 RFC: Steve Dusse, Paul Hoffman, and Jeff Weinstein. Without v2, there wouldn't be a v3, v3.1, v3.2 or v4.0. A number of the members of the S/MIME Working Group have also worked very hard and contributed to this document. Any list of people is doomed to omission, and for that I apologize. In alphabetical order,