draft-ietf-lamps-rfc5750-bis-05.txt   draft-ietf-lamps-rfc5750-bis-06.txt 
LAMPS J. Schaad LAMPS J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Obsoletes: 5750 (if approved) B. Ramsdell Obsoletes: 5750 (if approved) B. Ramsdell
Intended status: Standards Track Brute Squad Labs, Inc. Intended status: Standards Track Brute Squad Labs, Inc.
Expires: October 15, 2018 S. Turner Expires: November 3, 2018 S. Turner
sn3rd sn3rd
April 13, 2018 May 2, 2018
Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0 Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0
Certificate Handling Certificate Handling
draft-ietf-lamps-rfc5750-bis-05 draft-ietf-lamps-rfc5750-bis-06
Abstract Abstract
This document specifies conventions for X.509 certificate usage by This document specifies conventions for X.509 certificate usage by
Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents.
S/MIME provides a method to send and receive secure MIME messages, S/MIME provides a method to send and receive secure MIME messages,
and certificates are an integral part of S/MIME agent processing. and certificates are an integral part of S/MIME agent processing.
S/MIME agents validate certificates as described in RFC 5280, the S/MIME agents validate certificates as described in RFC 5280, the
Internet X.509 Public Key Infrastructure Certificate and CRL Profile. Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
S/MIME agents must meet the certificate processing requirements in S/MIME agents must meet the certificate processing requirements in
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on October 15, 2018. This Internet-Draft will expire on November 3, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 41 skipping to change at page 2, line 41
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions Used in This Document . . . . . . . . . . . . 4 1.2. Conventions Used in This Document . . . . . . . . . . . . 4
1.3. Compatibility with Prior Practice S/MIME . . . . . . . . 5 1.3. Compatibility with Prior Practice S/MIME . . . . . . . . 5
1.4. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 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.5. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 6
1.6. Changes since S/MIME 3.2 . . . . . . . . . . . . . . . . 6 1.6. Changes since S/MIME 3.2 . . . . . . . . . . . . . . . . 7
2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Certificate Revocation Lists . . . . . . . . . . . . . . 7 2.1. Certificate Revocation Lists . . . . . . . . . . . . . . 7
2.2. Certificate Choices . . . . . . . . . . . . . . . . . . . 7 2.2. Certificate Choices . . . . . . . . . . . . . . . . . . . 7
2.2.1. Historical Note about CMS Certificates . . . . . . . 7 2.2.1. Historical Note about CMS Certificates . . . . . . . 8
2.3. CertificateSet . . . . . . . . . . . . . . . . . . . . . 8 2.3. CertificateSet . . . . . . . . . . . . . . . . . . . . . 8
3. Using Distinguished Names for Internet Mail . . . . . . . . . 9 3. Using Distinguished Names for Internet Mail . . . . . . . . . 9
4. Certificate Processing . . . . . . . . . . . . . . . . . . . 10 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 10
4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 11 4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 11
4.2. Certificate Path Validation . . . . . . . . . . . . . . . 12 4.2. Certificate Path Validation . . . . . . . . . . . . . . . 12
4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 12 4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 13
4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 13 4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 14
4.4.1. Basic Constraints . . . . . . . . . . . . . . . . . . 14 4.4.1. Basic Constraints . . . . . . . . . . . . . . . . . . 14
4.4.2. Key Usage Certificate Extension . . . . . . . . . . . 14 4.4.2. Key Usage Certificate Extension . . . . . . . . . . . 15
4.4.3. Subject Alternative Name . . . . . . . . . . . . . . 15 4.4.3. Subject Alternative Name . . . . . . . . . . . . . . 15
4.4.4. Extended Key Usage Extension . . . . . . . . . . . . 15 4.4.4. Extended Key Usage Extension . . . . . . . . . . . . 16
5. IANA Considertions . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considertions . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 18 7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informational References . . . . . . . . . . . . . . . . 21 7.2. Informational References . . . . . . . . . . . . . . . . 21
Appendix A. Historic Considerations . . . . . . . . . . . . . . 23 Appendix A. Historic Considerations . . . . . . . . . . . . . . 24
A.1. Signature Algorithms and Key Sizes . . . . . . . . . . . 23 A.1. Signature Algorithms and Key Sizes . . . . . . . . . . . 24
Appendix B. Moving S/MIME v2 Certificate Handling to Historic Appendix B. Moving S/MIME v2 Certificate Handling to Historic
Status . . . . . . . . . . . . . . . . . . . . . . . 25 Status . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 25 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26
1. Introduction 1. Introduction
S/MIME (Secure/Multipurpose Internet Mail Extensions) v4.0, described S/MIME (Secure/Multipurpose Internet Mail Extensions) v4.0, described
in [I-D.ietf-lamps-rfc5751-bis], provides a method to send and in [I-D.ietf-lamps-rfc5751-bis], provides a method to send and
receive secure MIME messages. Before using a public key to provide receive secure MIME messages. Before using a public key to provide
security services, the S/MIME agent MUST verify that the public key security services, the S/MIME agent MUST verify that the public key
is valid. S/MIME agents MUST use PKIX certificates to validate is valid. S/MIME agents MUST use PKIX certificates to validate
public keys as described in the Internet X.509 Public Key public keys as described in the Internet X.509 Public Key
Infrastructure (PKIX) Certificate and CRL Profile [RFC5280]. S/MIME Infrastructure (PKIX) Certificate and CRL Profile [RFC5280]. S/MIME
agents MUST meet the certificate processing requirements documented agents MUST meet the certificate processing requirements documented
in this document in addition to those stated in [RFC5280]. in this document in addition to those stated in [RFC5280].
This specification is compatible with the Cryptographic Message This specification is compatible with the Cryptographic Message
Syntax (CMS) RFC 5652 [RFC5652] in that it uses the data types Syntax (CMS) RFC 5652 [RFC5652] in that it uses the data types
defined by CMS. It also inherits all the varieties of architectures defined by CMS. It also inherits all the varieties of architectures
for certificate-based key management supported by CMS. for certificate-based key management supported by CMS.
This document obsoletes [RFC5750]. The most significant changes
revolve around changes in recommendations around the cryptographic
algorithms used by the specification. More details can be found in
Section 1.6.
1.1. Definitions 1.1. Definitions
For the purposes of this document, the following definitions apply. For the purposes of this document, the following definitions apply.
ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680 ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680
[X.680]. [X.680].
Attribute certificate (AC): An X.509 AC is a separate structure from Attribute certificate (AC): An X.509 AC is a separate structure from
a subject's public key X.509 certificate. A subject may have a subject's public key X.509 certificate. A subject may have
multiple X.509 ACs associated with each of its public key X.509 multiple X.509 ACs associated with each of its public key X.509
skipping to change at page 4, line 33 skipping to change at page 4, line 37
Sending agent: Software that creates S/MIME CMS objects, MIME body Sending agent: Software that creates S/MIME CMS objects, MIME body
parts that contain CMS objects, or both. parts that contain CMS objects, or both.
S/MIME agent: User software that is a receiving agent, a sending S/MIME agent: User software that is a receiving agent, a sending
agent, or both. agent, or both.
1.2. Conventions Used in This Document 1.2. Conventions Used in This Document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
document are to be interpreted as described in [RFC2119]. "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here.
We define the additional requirement levels: We define the additional requirement levels:
SHOULD+ This term means the same as SHOULD. However, the authors SHOULD+ This term means the same as SHOULD. However, the authors
expect that a requirement marked as SHOULD+ will be promoted expect that a requirement marked as SHOULD+ will be promoted
at some future time to be a MUST. at some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, the authors SHOULD- This term means the same as SHOULD. However, the authors
expect that a requirement marked as SHOULD- will be demoted expect that a requirement marked as SHOULD- will be demoted
to a MAY in a future version of this document. to a MAY in a future version of this document.
skipping to change at page 7, line 51 skipping to change at page 8, line 15
2.2.1. Historical Note about CMS Certificates 2.2.1. Historical Note about CMS Certificates
The CMS message format supports a choice of certificate formats for The CMS message format supports a choice of certificate formats for
public key content types: PKIX, PKCS #6 extended certificates public key content types: PKIX, PKCS #6 extended certificates
[PKCS6], and PKIX attribute certificates. [PKCS6], and PKIX attribute certificates.
The PKCS #6 format is not in widespread use. In addition, PKIX The PKCS #6 format is not in widespread use. In addition, PKIX
certificate extensions address much of the same functionality and certificate extensions address much of the same functionality and
flexibility as was intended in the PKCS #6. Thus, sending and flexibility as was intended in the PKCS #6. Thus, sending and
receiving agents MUST NOT use PKCS #6 extended certificates. receiving agents MUST NOT use PKCS #6 extended certificates.
Receiving agents MUST be able to process a message containing PKCS #6 Receiving agents MUST be able to parser and process a message
extended certificates. containing PKCS #6 extended certificates although ignoring those
certificates is expected behavior.
X.509 version 1 attribute certificates are also not widely X.509 version 1 attribute certificates are also not widely
implemented, and have been superseded with version 2 attribute implemented, and have been superseded with version 2 attribute
certificates. Sending agents MUST NOT send version 1 attribute certificates. Sending agents MUST NOT send version 1 attribute
certificates. certificates.
2.3. CertificateSet 2.3. CertificateSet
Receiving agents MUST be able to handle an arbitrary number of Receiving agents MUST be able to handle an arbitrary number of
certificates of arbitrary relationship to the message sender and to certificates of arbitrary relationship to the message sender and to
skipping to change at page 10, line 34 skipping to change at page 10, line 49
extension will include the subject's identifier and MUST be marked as extension will include the subject's identifier and MUST be marked as
critical. critical.
4. Certificate Processing 4. Certificate Processing
S/MIME agents need to provide some certificate retrieval mechanism in S/MIME agents need to provide some certificate retrieval mechanism in
order to gain access to certificates for recipients of digital order to gain access to certificates for recipients of digital
envelopes. There are many ways to implement certificate retrieval envelopes. There are many ways to implement certificate retrieval
mechanisms. [X.500] directory service is an excellent example of a mechanisms. [X.500] directory service is an excellent example of a
certificate retrieval-only mechanism that is compatible with classic certificate retrieval-only mechanism that is compatible with classic
X.500 Distinguished Names. Another method under consideration by the X.500 Distinguished Names. The IETF has published [RFC8162] which
IETF is to provide certificate retrieval services as part of the describes an experimental protocol to retrieve certificates from the
existing Domain Name System (DNS). Until such mechanisms are widely Domain Name System (DNS). Until such mechanisms are widely used,
used, their utility may be limited by the small number of the their utility may be limited by the small number of the
correspondent's certificates that can be retrieved. At a minimum, correspondent's certificates that can be retrieved. At a minimum,
for initial S/MIME deployment, a user agent could automatically for initial S/MIME deployment, a user agent could automatically
generate a message to an intended recipient requesting the generate a message to an intended recipient requesting the
recipient's certificate in a signed return message. recipient's certificate in a signed return message.
Receiving and sending agents SHOULD also provide a mechanism to allow Receiving and sending agents SHOULD also provide a mechanism to allow
a user to "store and protect" certificates for correspondents in such a user to "store and protect" certificates for correspondents in such
a way so as to guarantee their later retrieval. In many a way so as to guarantee their later retrieval. In many
environments, it may be desirable to link the certificate retrieval/ environments, it may be desirable to link the certificate retrieval/
storage mechanisms together in some sort of certificate database. In storage mechanisms together in some sort of certificate database. In
skipping to change at page 18, line 45 skipping to change at page 19, line 18
Processing Standards Publication 186-3, June 2009. Processing Standards Publication 186-3, June 2009.
[I-D.ietf-lamps-eai-addresses] [I-D.ietf-lamps-eai-addresses]
Melnikov, A. and W. Chuang, "Internationalized Email Melnikov, A. and W. Chuang, "Internationalized Email
Addresses in X.509 certificates", draft-ietf-lamps-eai- Addresses in X.509 certificates", draft-ietf-lamps-eai-
addresses-18 (work in progress), March 2018. addresses-18 (work in progress), March 2018.
[I-D.ietf-lamps-rfc5751-bis] [I-D.ietf-lamps-rfc5751-bis]
Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", draft-ietf-lamps-rfc5751-bis-06 Message Specification", draft-ietf-lamps-rfc5751-bis-08
(work in progress), April 2017. (work in progress), May 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
RFC 2634, DOI 10.17487/RFC2634, June 1999, RFC 2634, DOI 10.17487/RFC2634, June 1999,
<https://www.rfc-editor.org/info/rfc2634>. <https://www.rfc-editor.org/info/rfc2634>.
skipping to change at page 20, line 31 skipping to change at page 21, line 5
Polk, "Internet X.509 Public Key Infrastructure: Polk, "Internet X.509 Public Key Infrastructure:
Additional Algorithms and Identifiers for DSA and ECDSA", Additional Algorithms and Identifiers for DSA and ECDSA",
RFC 5758, DOI 10.17487/RFC5758, January 2010, RFC 5758, DOI 10.17487/RFC5758, January 2010,
<https://www.rfc-editor.org/info/rfc5758>. <https://www.rfc-editor.org/info/rfc5758>.
[RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
Algorithm (DSA) and Elliptic Curve Digital Signature Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <https://www.rfc-editor.org/info/rfc6979>. 2013, <https://www.rfc-editor.org/info/rfc6979>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[SMIMEv3.2] [SMIMEv3.2]
"S/MIME version 3.2". "S/MIME version 3.2".
This group of documents represents S/MIME version 3.2. This group of documents represents S/MIME version 3.2.
This set of documents are [RFC2634], [RFC5750], [[This This set of documents are [RFC2634], [RFC5750], [[This
Document]], [RFC5652], and [RFC5035]. Document]], [RFC5652], and [RFC5035].
[SMIMEv4.0] [SMIMEv4.0]
"S/MIME version 4.0". "S/MIME version 4.0".
skipping to change at page 21, line 16 skipping to change at page 21, line 39
[ESS] "Enhanced Security Services for S/ MIME". [ESS] "Enhanced Security Services for S/ MIME".
This is the set of documents dealing with enhanced This is the set of documents dealing with enhanced
security services and refers to [RFC2634] and [RFC5035]. security services and refers to [RFC2634] and [RFC5035].
[I-D.ietf-curdle-pkix] [I-D.ietf-curdle-pkix]
Josefsson, S. and J. Schaad, "Algorithm Identifiers for Josefsson, S. and J. Schaad, "Algorithm Identifiers for
Ed25519, Ed448, X25519 and X448 for use in the Internet Ed25519, Ed448, X25519 and X448 for use in the Internet
X.509 Public Key Infrastructure", draft-ietf-curdle- X.509 Public Key Infrastructure", draft-ietf-curdle-
pkix-07 (work in progress), November 2017. pkix-09 (work in progress), April 2018.
[PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax [PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax
Standard", November 1993. Standard", November 1993.
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
L. Repka, "S/MIME Version 2 Message Specification", L. Repka, "S/MIME Version 2 Message Specification",
RFC 2311, DOI 10.17487/RFC2311, March 1998, RFC 2311, DOI 10.17487/RFC2311, March 1998,
<https://www.rfc-editor.org/info/rfc2311>. <https://www.rfc-editor.org/info/rfc2311>.
[RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein,
skipping to change at page 22, line 52 skipping to change at page 23, line 25
[RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security [RFC6194] Polk, T., Chen, L., Turner, S., and P. Hoffman, "Security
Considerations for the SHA-0 and SHA-1 Message-Digest Considerations for the SHA-0 and SHA-1 Message-Digest
Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011, Algorithms", RFC 6194, DOI 10.17487/RFC6194, March 2011,
<https://www.rfc-editor.org/info/rfc6194>. <https://www.rfc-editor.org/info/rfc6194>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital [RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032, Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017, DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[RFC8162] Hoffman, P. and J. Schlyter, "Using Secure DNS to
Associate Certificates with Domain Names for S/MIME",
RFC 8162, DOI 10.17487/RFC8162, May 2017,
<https://www.rfc-editor.org/info/rfc8162>.
[SMIMEv2] "S/MIME version v2". [SMIMEv2] "S/MIME version v2".
This group of documents represents S/MIME version 2. This This group of documents represents S/MIME version 2. This
set of documents are [RFC2311], [RFC2312], [RFC2313], set of documents are [RFC2311], [RFC2312], [RFC2313],
[RFC2314], and [RFC2315]. [RFC2314], and [RFC2315].
[SMIMEv3] "S/MIME version 3". [SMIMEv3] "S/MIME version 3".
This group of documents represents S/MIME version 3. This This group of documents represents S/MIME version 3. This
set of documents are [RFC2630], [RFC2631], [RFC2632], set of documents are [RFC2630], [RFC2631], [RFC2632],
 End of changes. 19 change blocks. 
24 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/