draft-ietf-lamps-rfc5750-bis-01.txt   draft-ietf-lamps-rfc5750-bis-02.txt 
LAMPS J. Schaad LAMPS J. Schaad
Internet-Draft August Cellars Internet-Draft August Cellars
Intended status: Standards Track B. Ramsdell Intended status: Standards Track B. Ramsdell
Expires: May 2, 2017 Brute Squad Labs, Inc. Expires: August 27, 2017 Brute Squad Labs, Inc.
S. Turner S. Turner
sn3rd sn3rd
October 29, 2016 February 23, 2017
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-01 draft-ietf-lamps-rfc5750-bis-02
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 http://datatracker.ietf.org/drafts/current/. Drafts is at http://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 May 2, 2017. This Internet-Draft will expire on August 27, 2017.
Copyright Notice 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. 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
(http://trustee.ietf.org/license-info) in effect on the date of (http://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 3, line 11 skipping to change at page 3, line 11
4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 11 4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 11
4.2. Certificate Path Validation . . . . . . . . . . . . . . . 11 4.2. Certificate Path Validation . . . . . . . . . . . . . . . 11
4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 12 4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 12
4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 13 4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 13
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 . . . . . . . . . . . 14
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 . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 15 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . 18 6.1. Normative References . . . . . . . . . . . . . . . . . . 17
6.2. Informational References . . . . . . . . . . . . . . . . 20 6.2. Informational References . . . . . . . . . . . . . . . . 20
Appendix A. Historic Considerations . . . . . . . . . . . . . . 23 Appendix A. Historic Considerations . . . . . . . . . . . . . . 23
A.1. Signature Algorithms and Key Sizes . . . . . . . . . . . 23 A.1. Signature Algorithms and Key Sizes . . . . . . . . . . . 23
Appendix B. Moving S/MIME v2 Certificate Handling to Historic Appendix B. Moving S/MIME v2 Certificate Handling to Historic
Status . . . . . . . . . . . . . . . . . . . . . . . 24 Status . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 24 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
skipping to change at page 6, line 44 skipping to change at page 6, line 44
Section 7: Moved references from Appendix B to Section 6. Updated Section 7: Moved references from Appendix B to Section 6. Updated
the references. the references.
Appendix A: Moved Appendix A to Appendix B. Added Appendix A to move Appendix A: Moved Appendix A to Appendix B. Added Appendix A to move
S/MIME v2 Certificate Handling to Historic Status. S/MIME v2 Certificate Handling to Historic Status.
1.6. Changes since S/MIME 3.2 1.6. Changes since S/MIME 3.2
Section 3: Require support for internationalized email addresses. 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 algorithms with SHA-1 and MD5 to historical status.
Moved DSA support to historical status. Increased lower Moved DSA support to historical status. Increased lower
bounds on RSA key sizes. bounds on RSA key sizes.
Appendix A: Add a new appendix for algorithms that are now considered Appendix A: Add a new appendix for algorithms that are now considered
to be historical. to be historical.
2. CMS Options 2. CMS Options
The CMS message format allows for a wide variety of options in The CMS message format allows for a wide variety of options in
skipping to change at page 9, line 11 skipping to change at page 9, line 11
Receiving agents SHOULD support the decoding of X.509 attribute Receiving agents SHOULD support the decoding of X.509 attribute
certificates included in CMS objects. All other issues regarding the certificates included in CMS objects. All other issues regarding the
generation and use of X.509 attribute certificates are outside of the generation and use of X.509 attribute certificates are outside of the
scope of this specification. One specification that addresses scope of this specification. One specification that addresses
attribute certificate use is defined in [RFC3114]. attribute certificate use is defined in [RFC3114].
3. Using Distinguished Names for Internet Mail 3. Using Distinguished Names for Internet Mail
End-entity certificates MAY contain an Internet mail address. Email End-entity certificates MAY contain an Internet mail address. Email
addresses retricted to US-ASCII characters are encoded as described addresses retricted to 7-bit ASCII characters are encoded as
in Section 4.2.1.6 of [RFC5280]. Internationalized Email address described in Section 4.2.1.6 of [RFC5280]. Internationalized Email
names are encoded as described in [I-D.ietf-lamps-eai-addresses]. address names are encoded as described in
The email address SHOULD be in the subjectAltName extension, and [I-D.ietf-lamps-eai-addresses]. The email address SHOULD be in the
SHOULD NOT be in the subject distinguished name. subjectAltName extension, and SHOULD NOT be in the subject
distinguished name.
Receiving agents MUST recognize and accept certificates that contain Receiving agents MUST recognize and accept certificates that contain
no email address. Agents are allowed to provide an alternative no email address. Agents are allowed to provide an alternative
mechanism for associating an email address with a certificate that mechanism for associating an email address with a certificate that
does not contain an email address, such as through the use of the does not contain an email address, such as through the use of the
agent's address book, if available. Receiving agents MUST recognize 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 subjectAltName field. Receiving agents MUST recognize email
addresses in the Distinguished Name field in the PKCS #9 [RFC2985] addresses in the Distinguished Name field in the PKCS #9 [RFC2985]
emailAddress attribute: emailAddress attribute:
pkcs-9-at-emailAddress OBJECT IDENTIFIER ::= pkcs-9-at-emailAddress OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 } { 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 Note that this attribute MUST be encoded as IA5String and has an
upper bound of 255 characters. The right side of the email address upper bound of 255 characters. The right side of the email address
SHOULD be treated as ASCII-case-insensitive. SHOULD be treated as ASCII-case-insensitive.
Comparing of email addresses is fraught with peril. Comparing of email addresses is fraught with peril.
[I-D.ietf-lamps-eai-addresses] defines the procedure for doing [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 addresses the domain component (right-hand side of the '@') MUST be
compared using a case-insensitive function. The local name component compared using a case-insensitive function. The local name component
(left-hand side of the '@') SHOULD be compared using a case- (left-hand side of the '@') SHOULD be compared using a case-
insensitive function. Some localities may perform other insensitive function. Some localities may perform other
transformations on the local name component before doing the transformations on the local name component before doing the
comparison, however an S/MIME client cannot know what specific comparison, however an S/MIME client cannot know what specific
localities do. localities do.
Sending agents SHOULD make the address in the From or Sender header 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 in a mail message match an Internet mail address in the signer's
skipping to change at page 13, line 23 skipping to change at page 13, line 23
For 1024-bit through 3072-bit RSA with SHA-256 see [RFC4055] and 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 [FIPS186-2] with Change Notice 1, and for 4096-bit RSA with SHA-256
see [RFC4055] and [RFC3447]. In either case, the first reference 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 object identifier and the second
provides the signature algorithm's definition. provides the signature algorithm's definition.
For RSASSA-PSS with SHA-256 see [RFC4056]. For RSASSA-PSS with SHA-256 see [RFC4056].
For ECDSA see [RFC5758] and [RFC6090]. The first reference provides For ECDSA see [RFC5758] and [RFC6090]. The first reference provides
the signature algorithm's object identifier and the second 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. MAY be used as well.
For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. The For EdDSA see [I-D.ietf-curdle-pkix] and [I-D.irtf-cfrg-eddsa]. The
first reference provides the signature algorithm's object identifier first reference provides the signature algorithm's object identifier
and the second provides the signature algorithm's definition. Other and the second provides the signature algorithm's definition. Other
curves than curve 25519 MAY be used as well. curves than curve 25519 MAY be used as well.
4.4. PKIX Certificate Extensions 4.4. PKIX Certificate Extensions
PKIX describes an extensible framework in which the basic certificate PKIX describes an extensible framework in which the basic certificate
skipping to change at page 15, line 14 skipping to change at page 15, line 14
concerning the digitalSignature or nonRepudiation bits within this concerning the digitalSignature or nonRepudiation bits within this
extension. extension.
If the key usage extension is not specified, receiving clients MUST If the key usage extension is not specified, receiving clients MUST
presume that the digitalSignature and nonRepudiation bits are set. presume that the digitalSignature and nonRepudiation bits are set.
4.4.3. Subject Alternative Name 4.4.3. Subject Alternative Name
The subject alternative name extension is used in S/MIME as the The subject alternative name extension is used in S/MIME as the
preferred means to convey the email address(es) that correspond(s) to preferred means to convey the email address(es) that correspond(s) to
the entity for this certificate. Any US-ASCII email addresses the entity for this certificate. Any ASCII email addresses present
present MUST be encoded using the rfc822Name CHOICE of the MUST be encoded using the rfc822Name CHOICE of the GeneralName type
GeneralName type as described in [RFC5280], Section 4.2.1.6. Any as described in [RFC5280], Section 4.2.1.6. Any internationalized
internationalized email addresses present MUST be encoded using the email addresses present MUST be encoded using the otherName CHOICE of
otherName CHOICE of the GeneralName type as described in the GeneralName type as described in [I-D.ietf-lamps-eai-addresses],
[I-D.ietf-lamps-eai-addresses], Section 3. Since the SubjectAltName Section 3. Since the SubjectAltName type is a SEQUENCE OF
type is a SEQUENCE OF GeneralName, multiple email addresses MAY be GeneralName, multiple email addresses MAY be present.
present.
4.4.4. Extended Key Usage Extension 4.4.4. Extended Key Usage Extension
The extended key usage extension also serves to limit the technical The extended key usage extension also serves to limit the technical
purposes for which a public key listed in a valid certificate may be purposes for which a public key listed in a valid certificate may be
used. The set of technical purposes for the certificate therefore used. The set of technical purposes for the certificate therefore
are the intersection of the uses indicated in the key usage and are the intersection of the uses indicated in the key usage and
extended key usage extensions. extended key usage extensions.
For example, if the certificate contains a key usage extension For example, if the certificate contains a key usage extension
skipping to change at page 18, line 20 skipping to change at page 18, line 19
Publication 186-2, January 2000. Publication 186-2, January 2000.
[FIPS186-3] [FIPS186-3]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS)", Federal Information "Digital Signature Standard (DSS)", Federal Information
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-00 (work in progress), July 2016. addresses-06 (work in progress), February 2017.
[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 3.5 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", draft-ietf-lamps-rfc5751-bis-01 Message Specification", draft-ietf-lamps-rfc5751-bis-02
(work in progress), August 2016. (work in progress), October 2016.
[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,
<http://www.rfc-editor.org/info/rfc2119>. <http://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,
<http://www.rfc-editor.org/info/rfc2634>. <http://www.rfc-editor.org/info/rfc2634>.
skipping to change at page 20, line 40 skipping to change at page 20, line 40
[ESS] "Enhanced Security Services for S/ MIME". [ESS] "Enhanced Security Services for S/ MIME".
This is the set of documents dealing with enhanged This is the set of documents dealing with enhanged
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, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for Ed25519, Ed25519ph, Ed448, Ed448ph, X25519 and X448 for
use in the Internet X.509 Public Key Infrastructure", 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] [I-D.irtf-cfrg-eddsa]
Josefsson, S. and I. Liusvaara, "Edwards-curve Digital Josefsson, S. and I. Liusvaara, "Edwards-curve Digital
Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08 Signature Algorithm (EdDSA)", draft-irtf-cfrg-eddsa-08
(work in progress), August 2016. (work in progress), August 2016.
[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
 End of changes. 15 change blocks. 
28 lines changed or deleted 29 lines changed or added

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