draft-ietf-lamps-rfc5750-bis-00.txt   draft-ietf-lamps-rfc5750-bis-01.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: March 2, 2017 Brute Squad Labs, Inc. Expires: May 2, 2017 Brute Squad Labs, Inc.
S. Turner S. Turner
sn3rd sn3rd
August 29, 2016 October 29, 2016
Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 3.2 Secure/Multipurpose Internet Mail Extensions (S/ MIME) Version 4.0
Certificate Handling Certificate Handling
draft-ietf-lamps-rfc5750-bis-00 draft-ietf-lamps-rfc5750-bis-01
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) v3.2 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
this document as well as those in RFC 5280. This document obsoletes this document as well as those in RFC 5280. This document obsoletes
RFC 3850. RFC 3850.
Contributing to this document Contributing to this document
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 March 2, 2017. This Internet-Draft will expire on May 2, 2017.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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
described in the Simplified BSD License. described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
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 . . . . . . . . 4 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 since S/MIME v3.1 . . . . . . . . . . . . . . . . 5 1.5. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 6
1.6. Changes from 3.2 to 3.5 . . . . . . . . . . . . . . . . . 6 1.6. Changes since S/MIME 3.2 . . . . . . . . . . . . . . . . 6
2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Certificate Revocation Lists . . . . . . . . . . . . . . 6 2.1. Certificate Revocation Lists . . . . . . . . . . . . . . 7
2.2. Certificate Choices . . . . . . . . . . . . . . . . . . . 6 2.2. Certificate Choices . . . . . . . . . . . . . . . . . . . 7
2.2.1. Historical Note about CMS Certificates . . . . . . . 7 2.2.1. Historical Note about CMS Certificates . . . . . . . 7
2.3. CertificateSet . . . . . . . . . . . . . . . . . . . . . 7 2.3. CertificateSet . . . . . . . . . . . . . . . . . . . . . 8
3. Using Distinguished Names for Internet Mail . . . . . . . . . 8 3. Using Distinguished Names for Internet Mail . . . . . . . . . 9
4. Certificate Processing . . . . . . . . . . . . . . . . . . . 9 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 10
4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 10 4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 11
4.2. Certificate Path Validation . . . . . . . . . . . . . . . 10 4.2. Certificate Path Validation . . . . . . . . . . . . . . . 11
4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 11 4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 12
4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 12 4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 13
4.4.1. Basic Constraints . . . . . . . . . . . . . . . . . . 13 4.4.1. Basic Constraints . . . . . . . . . . . . . . . . . . 14
4.4.2. Key Usage Certificate Extension . . . . . . . . . . . 13 4.4.2. Key Usage Certificate Extension . . . . . . . . . . . 14
4.4.3. Subject Alternative Name . . . . . . . . . . . . . . 14 4.4.3. Subject Alternative Name . . . . . . . . . . . . . . 15
4.4.4. Extended Key Usage Extension . . . . . . . . . . . . 14 4.4.4. Extended Key Usage Extension . . . . . . . . . . . . 15
5. Security Considerations . . . . . . . . . . . . . . . . . . . 14 5. Security Considerations . . . . . . . . . . . . . . . . . . . 15
6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 6. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.1. Normative References . . . . . . . . . . . . . . . . . . 17 6.1. Normative References . . . . . . . . . . . . . . . . . . 18
6.2. Informational References . . . . . . . . . . . . . . . . 19 6.2. Informational References . . . . . . . . . . . . . . . . 20
Appendix A. Historic Considerations . . . . . . . . . . . . . . 21 Appendix A. Historic Considerations . . . . . . . . . . . . . . 23
A.1. Signature Algorithms and Key Sizes . . . . . . . . . . . 21 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 . . . . . . . . . . . . . . . . . . . . . . . 22 Status . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 22 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
S/MIME (Secure/Multipurpose Internet Mail Extensions) v3.2, described S/MIME (Secure/Multipurpose Internet Mail Extensions) v4.0, described
in [RFC5751], provides a method to send and receive secure MIME in [I-D.ietf-lamps-rfc5751-bis], provides a method to send and
messages. Before using a public key to provide security services, receive secure MIME messages. Before using a public key to provide
the S/MIME agent MUST verify that the public key is valid. S/MIME security services, the S/MIME agent MUST verify that the public key
agents MUST use PKIX certificates to validate public keys as is valid. S/MIME agents MUST use PKIX certificates to validate
described in the Internet X.509 Public Key Infrastructure (PKIX) public keys as described in the Internet X.509 Public Key
Certificate and CRL Profile [RFC5280]. S/MIME agents MUST meet the Infrastructure (PKIX) Certificate and CRL Profile [RFC5280]. S/MIME
certificate processing requirements documented in this document in agents MUST meet the certificate processing requirements documented
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.
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.
skipping to change at page 4, line 42 skipping to change at page 5, line 7
MUST- This term means the same as MUST. However, the authors MUST- This term means the same as MUST. However, the authors
expect that this requirement will no longer be a MUST in a expect that this requirement will no longer be a MUST in a
future document. Although its status will be determined at a future document. Although its status will be determined at a
later time, it is reasonable to expect that if a future later time, it is reasonable to expect that if a future
revision of a document alters the status of a MUST- revision of a document alters the status of a MUST-
requirement, it will remain at least a SHOULD or a SHOULD-. requirement, it will remain at least a SHOULD or a SHOULD-.
1.3. Compatibility with Prior Practice S/MIME 1.3. Compatibility with Prior Practice S/MIME
S/MIME version 3.2 agents ought to attempt to have the greatest S/MIME version 4.0 agents ought to attempt to have the greatest
interoperability possible with agents for prior versions of S/MIME. interoperability possible with agents for prior versions of S/MIME.
S/MIME version 2 is described in RFC 2311 through RFC 2315 inclusive 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 [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 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]. in RFC 3850, RFC 3851, RFC 3852, RFC 2634, and RFC 5035 [SMIMEv3.1].
RFC 2311 also has historical information about the development of RFC 2311 also has historical information about the development of
S/MIME. S/MIME.
Appendix A contains information about algorithms are 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.
1.4. Changes from S/MIME v3 to S/MIME v3.1 1.4. Changes from S/MIME v3 to S/MIME v3.1
Version 1 and version 2 CRLs MUST be supported. Version 1 and version 2 CRLs MUST be supported.
Multiple certification authority (CA) certificates with the same Multiple certification authority (CA) certificates with the same
subject and public key, but with overlapping validity periods, MUST subject and public key, but with overlapping validity periods, MUST
be supported. be supported.
Version 2 attribute certificates SHOULD be supported, and version 1 Version 2 attribute certificates SHOULD be supported, and version 1
attributes certificates MUST NOT be used. attributes certificates MUST NOT be used.
skipping to change at page 5, line 32 skipping to change at page 6, line 5
Receiving agents SHOULD display certificate information when Receiving agents SHOULD display certificate information when
displaying the results of signature verification. displaying the results of signature verification.
Receiving agents MUST NOT accept a signature made with a certificate Receiving agents MUST NOT accept a signature made with a certificate
that does not have the digitalSignature or nonRepudiation bit set. that does not have the digitalSignature or nonRepudiation bit set.
Clarifications for the interpretation of the key usage and extended Clarifications for the interpretation of the key usage and extended
key usage extensions. key usage extensions.
1.5. Changes since S/MIME v3.1 1.5. Changes from S/MIME v3.1 to S/MIME v3.2
Conventions Used in This Document: Moved to Section 1.2. Added Conventions Used in This Document: Moved to Section 1.2. Added
definitions for SHOULD+, SHOULD-, and MUST-. definitions for SHOULD+, SHOULD-, and MUST-.
Section 1.1: Updated ASN.1 definition and reference. Section 1.1: Updated ASN.1 definition and reference.
Section 1.3: Added text about v3.1 RFCs. Section 1.3: Added text about v3.1 RFCs.
Section 3: Aligned email address text with RFC 5280. Updated note Section 3: Aligned email address text with RFC 5280. Updated note
to indicate emailAddress IA5String upper bound is 255 to indicate emailAddress IA5String upper bound is 255
skipping to change at page 6, line 18 skipping to change at page 6, line 40
to perform issuing authority operations. to perform issuing authority operations.
Section 5: Updated security considerations. Section 5: Updated security considerations.
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 from 3.2 to 3.5 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.
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 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
content and algorithm support. This section puts forth a number of content and algorithm support. This section puts forth a number of
support requirements and recommendations in order to achieve a base support requirements and recommendations in order to achieve a base
level of interoperability among all S/MIME implementations. Most of 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 [RFC5751].
2.1. Certificate Revocation Lists 2.1. Certificate Revocation Lists
skipping to change at page 8, line 31 skipping to change at page 9, line 10
supported. supported.
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 as End-entity certificates MAY contain an Internet mail address. Email
described in [RFC5280], Section 4.2.1.6. The email address SHOULD be addresses retricted to US-ASCII characters are encoded as described
in the subjectAltName extension, and SHOULD NOT be in the subject in Section 4.2.1.6 of [RFC5280]. Internationalized Email address
distinguished name. 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 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
email addresses in the subjectAltName field. Receiving agents MUST both US-ASCII and internationalized email addresses in the
recognize email addresses in the Distinguished Name field in the PKCS subjectAltName field. Receiving agents MUST recognize email
#9 [RFC2985] emailAddress attribute: addresses in the Distinguished Name field in the PKCS #9 [RFC2985]
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.
[I-D.ietf-lamps-eai-addresses] defines the procedure for doing
comparison of Internationalized email addresses. For US-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 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
certificate. Receiving agents MUST check that the address in the certificate. Receiving agents MUST check that the address in the
From or Sender header of a mail message matches an Internet mail From or Sender header of a mail message matches an Internet mail
address, if present, in the signer's certificate, if mail addresses address in the signer's certificate, if mail addresses are present in
are present in the certificate. A receiving agent SHOULD provide the certificate. A receiving agent SHOULD provide some explicit
some explicit alternate processing of the message if this comparison alternate processing of the message if this comparison fails, which
fails, which may be to display a message that shows the recipient the may be to display a message that shows the recipient the addresses in
addresses in the certificate or other certificate details. the certificate or other certificate details.
A receiving agent SHOULD display a subject name or other certificate A receiving agent SHOULD display a subject name or other certificate
details when displaying an indication of successful or unsuccessful details when displaying an indication of successful or unsuccessful
signature verification. signature verification.
All subject and issuer names MUST be populated (i.e., not an empty All subject and issuer names MUST be populated (i.e., not an empty
SEQUENCE) in S/MIME-compliant X.509 certificates, except that the SEQUENCE) in S/MIME-compliant X.509 certificates, except that the
subject distinguished name (DN) in a user's (i.e., end-entity) subject distinguished name (DN) in a user's (i.e., end-entity)
certificate MAY be an empty SEQUENCE in which case the subjectAltName certificate MAY be an empty SEQUENCE in which case the subjectAltName
extension will include the subject's identifier and MUST be marked as extension will include the subject's identifier and MUST be marked as
skipping to change at page 12, line 7 skipping to change at page 12, line 48
- MUST support ECDSA with curve P-256 with SHA-256. - MUST support ECDSA with curve P-256 with SHA-256.
- MUST support EdDSA with curve 25519 using PureEdDSA mode. - MUST support EdDSA with curve 25519 using PureEdDSA mode.
- MUST- support RSA with SHA-256. - MUST- support RSA with SHA-256.
- SHOULD support RSASSA-PSS with SHA-256. - SHOULD support RSASSA-PSS with SHA-256.
- MUST NOT support EdDSA using Pre-hash mode. - MUST NOT support EdDSA using Pre-hash mode.
Implementations SHOULD use deterministic generation for the parameter
'k' for ECDSA as outlined in [RFC6979]. EdDSA is defined to generate
this parameter deterministically.
The following are the RSA and RSASSA-PSS key size requirements for The following are the RSA and RSASSA-PSS key size requirements for
S/MIME receiving agents during certificate and CRL signature S/MIME receiving agents during certificate and CRL signature
verification: verification:
key size <= 2047 : SHOULD NOT (see Historic Considerations) key size <= 2047 : SHOULD NOT (see Historic Considerations)
2048 <= key size <= 4096 : MUST (see Security Considerations) 2048 <= key size <= 4096 : MUST (see Security Considerations)
4096 < key size : MAY (see Security Considerations) 4096 < key size : MAY (see Security Considerations)
For 512-bit RSA with SHA-1 see [RFC3279] and [FIPS186-2] without For 1024-bit through 3072-bit RSA with SHA-256 see [RFC4055] and
Change Notice 1, for 512-bit RSA with SHA-256 see [RFC4055] and [FIPS186-2] with Change Notice 1, and for 4096-bit RSA with SHA-256
[FIPS186-2] without Change Notice 1, for 1024-bit through 3072-bit see [RFC4055] and [RFC3447]. In either case, the first reference
RSA with SHA-256 see [RFC4055] and [FIPS186-2] with Change Notice 1, provides the signature algorithm's object identifier and the second
and for 4096-bit RSA with SHA-256 see [RFC4055] and [RFC3447]. In provides the signature algorithm's definition.
either case, the first reference provides the signature algorithm's
object identifier and the second provides the signature algorithm's
definition.
For 512-bit DSA with SHA-1 see [RFC3279] and [FIPS186-2] without
Change Notice 1, for 512-bit DSA with SHA-256 see [RFC5758] and
[FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see
[RFC3279] and [FIPS186-2] with Change Notice 1, for 1024-bit through
3072 DSA with SHA-256 see [RFC5758] and [FIPS186-3]. 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 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
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 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
information can be extended and describes how such extensions can be information can be extended and describes how such extensions can be
used to control the process of issuing and validating certificates. used to control the process of issuing and validating certificates.
The PKIX Working Group has ongoing efforts to identify and create The PKIX Working Group has ongoing efforts to identify and create
extensions that have value in particular certification environments. extensions that have value in particular certification environments.
Further, there are active efforts underway to issue PKIX certificates Further, there are active efforts underway to issue PKIX certificates
for business purposes. This document identifies the minimum required for business purposes. This document identifies the minimum required
set of certificate extensions that have the greatest value in the set of certificate extensions that have the greatest value in the
skipping to change at page 14, line 18 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 email addresses present MUST be the entity for this certificate. Any US-ASCII email addresses
encoded using the rfc822Name CHOICE of the GeneralName type as present MUST be encoded using the rfc822Name CHOICE of the
described in [RFC5280], Section 4.2.1.6. Since the SubjectAltName 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 type is a SEQUENCE OF 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.
skipping to change at page 16, line 24 skipping to change at page 17, line 23
manufactured by untrusted sources for the purpose of mounting denial manufactured by untrusted sources for the purpose of mounting denial
of service or other attacks. For example, keys selected to require of service or other attacks. For example, keys selected to require
excessive cryptographic processing, or extensive lists of CRL excessive cryptographic processing, or extensive lists of CRL
Distribution Point (CDP) and/or Authority Information Access (AIA) Distribution Point (CDP) and/or Authority Information Access (AIA)
addresses in the certificate, could be used to mount denial-of- addresses in the certificate, could be used to mount denial-of-
service attacks. Similarly, attacker-specified CDP and/or AIA service attacks. Similarly, attacker-specified CDP and/or AIA
addresses could be included in fake certificates to allow the addresses could be included in fake certificates to allow the
originator to detect receipt of the message even if signature originator to detect receipt of the message even if signature
verification fails. verification fails.
The 4096-bit RSA key size requirement for certificate and CRL RSA keys of less than 2048 bits are now considered by many experts to
verification is larger than the 2048-bit RSA key sizes for message be cryptographically insecure (due to advances in computing power),
signature generation/verification or message encryption/decryption in and should no longer be used to sign certificates or CRLs. Such keys
[RFC5751] because many root CAs included in certificate stores have were previously considered secure, so processing previously received
already issued root certificates with the 4096-bit key. The standard signed and encrypted mail may require processing certificates or CRLs
that defines comparable key sizes for DSA is not yet available. In signed with weak keys. Implementations that wish to support previous
particular, [FIPS186-2] without Change Notice 1 allowed DSA key sizes versions of S/MIME or process old messages need to consider the
between 512 and 1024 bits, [FIPS186-2] with Change Notice 1 only security risks that result from accepting certificates and CRLs with
allowed DSA key sizes of 1024 bits, and [FIPS186-3] allowed DSA key smaller key sizes (e.g., spoofed certificates) versus the costs of
sizes from 1024 to 3072 bits. Further, 4096-bit keys are normally denial of service. If an implementation supports verification of
only used by Root certificates and not by subordinate CA certificates or CRLs generated with RSA and DSA keys of less than
certificates, thereby lengthening the root CA certificate's validity 2048 bits, it MUST warn the user. Implementers should consider
period. providing a stronger warning for weak signatures on certificates and
CRLs associated with newly received messages than the one provided
RSA and DSA keys of less than 2048 bits are now considered by many for certificates and CRLs associated with previously stored messages.
experts to be cryptographically insecure (due to advances in Server implementations (e.g., secure mail list servers) where user
computing power), and should no longer be used to sign certificates warnings are not appropriate SHOULD reject messages with weak
or CRLs. Such keys were previously considered secure, so processing cryptography.
previously received signed and encrypted mail may require processing
certificates or CRLs signed with 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 accepting
certificates and CRLs with smaller key sizes (e.g., spoofed
certificates) versus the costs of denial of service. If an
implementation supports verification of certificates or CRLs
generated with RSA and DSA keys of less than 2048 bits, it MUST warn
the user. Implementers should consider providing a stronger warning
for weak signatures on certificates and CRLs associated with newly
received messages than the one provided for certificates and CRLs
associated with previously stored messages. Server implementations
(e.g., secure mail list servers) where user warnings are not
appropriate SHOULD reject messages with weak cryptography.
If an implementation is concerned about compliance with National If an implementation is concerned about compliance with National
Institute of Standards and Technology (NIST) key size Institute of Standards and Technology (NIST) key size
recommendations, then see [SP800-57]. recommendations, then see [SP800-57].
6. References 6. References
6.1. Normative References 6.1. Normative References
[FIPS186-2] [FIPS186-2]
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS) [With Change Notice 1]", "Digital Signature Standard (DSS) [With Change Notice 1]",
Federal Information Processing Standards Federal Information Processing Standards
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),
skipping to change at page 17, line 28 skipping to change at page 18, line 17
National Institute of Standards and Technology (NIST), National Institute of Standards and Technology (NIST),
"Digital Signature Standard (DSS) [With Change Notice 1]", "Digital Signature Standard (DSS) [With Change Notice 1]",
Federal Information Processing Standards Federal Information Processing Standards
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]
Melnikov, A. and W. Chuang, "Internationalized Email
Addresses in X.509 certificates", draft-ietf-lamps-eai-
addresses-00 (work in progress), July 2016.
[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.
[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>.
[RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object [RFC2985] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
skipping to change at page 19, line 5 skipping to change at page 20, line 5
Attribute Certificate Profile for Authorization", Attribute Certificate Profile for Authorization",
RFC 5755, DOI 10.17487/RFC5755, January 2010, RFC 5755, DOI 10.17487/RFC5755, January 2010,
<http://www.rfc-editor.org/info/rfc5755>. <http://www.rfc-editor.org/info/rfc5755>.
[RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T. [RFC5758] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and T.
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,
<http://www.rfc-editor.org/info/rfc5758>. <http://www.rfc-editor.org/info/rfc5758>.
[SMIMEv3.5] [RFC6979] Pornin, T., "Deterministic Usage of the Digital Signature
"S/MIME version 3.5". Algorithm (DSA) and Elliptic Curve Digital Signature
Algorithm (ECDSA)", RFC 6979, DOI 10.17487/RFC6979, August
2013, <http://www.rfc-editor.org/info/rfc6979>.
This group of documents represents S/MIME version 3.5. [SMIMEv3.2]
"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]
"S/MIME version 4.0".
This group of documents represents S/MIME version 4.0.
This set of documents are [RFC2634],
[I-D.ietf-lamps-rfc5751-bis], [[This Document]],
[RFC5652], and [RFC5035].
[X.680] "Information Technology - Abstract Syntax Notation One [X.680] "Information Technology - Abstract Syntax Notation One
(ASN.1): Specification of basic notation. ITU-T (ASN.1): Specification of basic notation. ITU-T
Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.". Recommendation X.680 (2002) | ISO/IEC 8824-1:2002.".
6.2. Informational References 6.2. Informational References
[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]
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.
[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 [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,
<http://www.rfc-editor.org/info/rfc2311>. <http://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,
"S/MIME Version 2 Certificate Handling", RFC 2312, "S/MIME Version 2 Certificate Handling", RFC 2312,
skipping to change at page 20, line 36 skipping to change at page 22, line 14
[RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail [RFC3851] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Message Specification", Extensions (S/MIME) Version 3.1 Message Specification",
RFC 3851, DOI 10.17487/RFC3851, July 2004, RFC 3851, DOI 10.17487/RFC3851, July 2004,
<http://www.rfc-editor.org/info/rfc3851>. <http://www.rfc-editor.org/info/rfc3851>.
[RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)", [RFC3852] Housley, R., "Cryptographic Message Syntax (CMS)",
RFC 3852, DOI 10.17487/RFC3852, July 2004, RFC 3852, DOI 10.17487/RFC3852, July 2004,
<http://www.rfc-editor.org/info/rfc3852>. <http://www.rfc-editor.org/info/rfc3852>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011,
<http://www.rfc-editor.org/info/rfc6090>.
[RFC6151] Turner, S. and L. Chen, "Updated Security Considerations [RFC6151] Turner, S. and L. Chen, "Updated Security Considerations
for the MD5 Message-Digest and the HMAC-MD5 Algorithms", for the MD5 Message-Digest and the HMAC-MD5 Algorithms",
RFC 6151, DOI 10.17487/RFC6151, March 2011, RFC 6151, DOI 10.17487/RFC6151, March 2011,
<http://www.rfc-editor.org/info/rfc6151>. <http://www.rfc-editor.org/info/rfc6151>.
[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,
<http://www.rfc-editor.org/info/rfc6194>. <http://www.rfc-editor.org/info/rfc6194>.
skipping to change at page 22, line 19 skipping to change at page 23, line 49
- Hash functions used to validate signatures on historic messages - Hash functions used to validate signatures on historic messages
may longer be considered to be secure (see below). While there may longer be considered to be secure (see below). While there
are not currently any known practical pre-image or second pre- are not currently any known practical pre-image or second pre-
image attacks against MD5 or SHA-1, the fact they are no longer image attacks against MD5 or SHA-1, the fact they are no longer
considered to be collision resistent the security levels of the considered to be collision resistent the security levels of the
signatures are generally considered suspect. signatures are generally considered suspect.
The following algorithms have been called out for some level of The following algorithms have been called out for some level of
support by previous S/MIME specifications: support by previous S/MIME specifications:
- RSA with MD5 was dropped in [SMIMEv3.5]. MD5 is no longer - RSA with MD5 was dropped in [SMIMEv4.0]. MD5 is no longer
considered to be secure as it is no longer collision-resistant. considered to be secure as it is no longer collision-resistant.
Details can be found in [RFC6151]. Details can be found in [RFC6151].
- RSA and DSA with SHA-1 were dropped in [SMIMEv3.5]. SHA-1 is - RSA and DSA with SHA-1 were dropped in [SMIMEv4.0]. SHA-1 is
nolonger considered to be secure as it is no longer collision- nolonger considered to be secure as it is no longer collision-
resistant. The IETF statement on SHA-1 can be found in [RFC6194] resistant. The IETF statement on SHA-1 can be found in [RFC6194]
but it is out-of-date relative to the most recent advances. but it is out-of-date relative to the most recent advances.
- SHOULD+ support DSA with SHA-256 - DSA with SHA-256 support was dropped in [SMIMEv4.0]. DSA was
dropped as part of a general movement from discrete logarithms to
elliptic curves. Issues have come up dealing with small group
attacks and with non-deterministic generation of the parameter 'k'
(see [RFC6979]).
For 512-bit RSA with SHA-1 see [RFC3279] and [FIPS186-2] without
Change Notice 1, for 512-bit RSA with SHA-256 see [RFC4055] and
[FIPS186-2] without Change Notice 1.
For 512-bit DSA with SHA-1 see [RFC3279] and [FIPS186-2] without
Change Notice 1, for 512-bit DSA with SHA-256 see [RFC5758] and
[FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see
[RFC3279] and [FIPS186-2] with Change Notice 1, for 1024-bit through
3072 DSA with SHA-256 see [RFC5758] and [FIPS186-3]. In either case,
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 Appendix B. Moving S/MIME v2 Certificate Handling to Historic Status
The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document) The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], v3.2 [SMIMEv3.2], and v4.0
are backwards compatible with the S/MIME v2 Certificate Handling (this document) are backwards compatible with the S/MIME v2
Specification [SMIMEv2], with the exception of the algorithms Certificate Handling Specification [SMIMEv2], with the exception of
(dropped RC2/40 requirement and added DSA and RSASSA-PSS the algorithms (dropped RC2/40 requirement and added DSA and RSASSA-
requirements). Therefore, it is recommended that RFC 2312 [SMIMEv2] PSS requirements). Therefore, it is recommended that RFC 2312
be moved to Historic status. [SMIMEv2] be moved to Historic status.
Appendix C. Acknowledgments Appendix C. Acknowledgments
Many thanks go out to the other authors of the S/MIME v2 RFC: Steve 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 Dusse, Paul Hoffman, and Jeff Weinstein. Without v2, there wouldn't
be a v3, v3.1, or v3.2. be a v3, v3.1, or v3.2.
A number of the members of the S/MIME Working Group have also worked 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 very hard and contributed to this document. Any list of people is
doomed to omission, and for that I apologize. In alphabetical order, doomed to omission, and for that I apologize. In alphabetical order,
the following people stand out in my mind because they made direct the following people stand out in my mind because they made direct
contributions to this document. contributions to this document.
Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Alfred Hoenes, Paul Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Alfred Hoenes, Paul
Hoffman, Russ Housley, David P. Kemp, Michael Myers, John Pawling, Hoffman, Russ Housley, David P. Kemp, Michael Myers, John Pawling,
Denis Pinkas, and Jim Schaad. and Denis Pinkas.
Authors' Addresses Authors' Addresses
Jim Schaad Jim Schaad
August Cellars August Cellars
Email: ietf@augustcellars.com Email: ietf@augustcellars.com
Blake Ramsdell Blake Ramsdell
Brute Squad Labs, Inc. Brute Squad Labs, Inc.
 End of changes. 38 change blocks. 
121 lines changed or deleted 209 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/