draft-ietf-lamps-rfc5750-bis-04.txt   draft-ietf-lamps-rfc5750-bis-05.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 9, 2017 S. Turner Expires: October 15, 2018 S. Turner
sn3rd sn3rd
April 7, 2017 April 13, 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-04 draft-ietf-lamps-rfc5750-bis-05
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 1, line 43 skipping to change at page 1, line 43
be discussed on the LAMPS mailing list. be discussed on the LAMPS mailing list.
Status of This Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 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 9, 2017. This Internet-Draft will expire on October 15, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2017 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
(http://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
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 This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this 10, 2008. The person(s) controlling the copyright in some of this
skipping to change at page 2, line 50 skipping to change at page 2, line 50
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 . . . . . . . . . . . . . . . . 6
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 . . . . . . . 7
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 . . . . . . . . . . . . . . . 11 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 . . 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. 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 . . . . . . . . . . . . . . . . 20 7.2. Informational References . . . . . . . . . . . . . . . . 21
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 . . . . . . . . . . . . . . . . . . . . . . . 25
Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 24 Appendix C. Acknowledgments . . . . . . . . . . . . . . . . . . 25
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25
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
skipping to change at page 5, line 22 skipping to change at page 5, line 22
S/MIME version 4.0 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 Appendix A contains information about algorithms that were used for
prior versions of S/MIME but are no longer considered to meet modern prior versions of S/MIME but are no longer considered to meet modern
security standards. Support of these algorithms may be needed to security standards. Support of these algorithms may be needed to
support historic S/MIME messages but SHOULD NOT be used for new mail. 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
skipping to change at page 5, line 49 skipping to change at page 5, line 49
discouraged, and security language was added. discouraged, and security language was added.
Clarified use of email address use in certificates. Certificates Clarified use of email address use in certificates. Certificates
that do not contain an email address have no requirements for that do not contain an email address have no requirements for
verifying the email address associated with the certificate. verifying the email address associated with the certificate.
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 at least one of the the digitalSignature or
nonRepudiation bits 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 from S/MIME v3.1 to S/MIME v3.2 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.
skipping to change at page 7, line 18 skipping to change at page 7, line 21
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
Receiving agents MUST support the Certificate Revocation List (CRL) Receiving agents MUST support the Certificate Revocation List (CRL)
format defined in [RFC5280]. If sending agents include CRLs in format defined in [RFC5280]. If sending agents include CRLs in
outgoing messages, the CRL format defined in [RFC5280] MUST be used. outgoing messages, the CRL format defined in [RFC5280] MUST be used.
In all cases, both v1 and v2 CRLs MUST be supported. Receiving agents MUST support both v1 and v2 CRLs.
All agents MUST be capable of performing revocation checks using CRLs All agents MUST be capable of performing revocation checks using CRLs
as specified in [RFC5280]. All agents MUST perform revocation status as specified in [RFC5280]. All agents MUST perform revocation status
checking in accordance with [RFC5280]. Receiving agents MUST checking in accordance with [RFC5280]. Receiving agents MUST
recognize CRLs in received S/MIME messages. recognize CRLs in received S/MIME messages.
Agents SHOULD store CRLs received in messages for use in processing Agents SHOULD store CRLs received in messages for use in processing
later messages. later messages.
2.2. Certificate Choices 2.2. Certificate Choices
skipping to change at page 7, line 48 skipping to change at page 7, line 51
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
extended certificates.
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 9, line 11 skipping to change at page 9, line 18
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 7-bit ASCII characters are encoded as addresses restricted to 7-bit ASCII characters use the pkcs-9-at-
described in Section 4.2.1.6 of [RFC5280]. Internationalized Email emailAddress OID (see below) and are encoded as described in
address names are encoded as described in Section 4.2.1.6 of [RFC5280]. Internationalized Email address names
[I-D.ietf-lamps-eai-addresses]. The email address SHOULD be in the use the OID defined in [I-D.ietf-lamps-eai-addresses] and are encoded
as described there. The email address SHOULD be in the
subjectAltName extension, and SHOULD NOT be in the subject subjectAltName extension, and SHOULD NOT be in the subject
distinguished name. 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 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
skipping to change at page 10, line 4 skipping to change at page 10, line 11
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
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 in the signer's certificate, if mail addresses are present in address in the signer's certificate, if mail addresses are present in
the certificate. A receiving agent SHOULD provide some explicit the certificate. A receiving agent SHOULD provide some explicit
alternate processing of the message if this comparison fails, which alternate processing of the message if this comparison fails, this
may be to display a message that shows the recipient the addresses in might be done by displaying or logging a message that shows the
the certificate or other certificate details. recipient the mail addresses in 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 10, line 45 skipping to change at page 11, line 4
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
its simplest form, a certificate database would be local to a its simplest form, a certificate database would be local to a
particular user and would function in a similar way as an "address particular user and would function in a similar way as an "address
book" that stores a user's frequent correspondents. In this way, the book" that stores a user's frequent correspondents. In this way, the
certificate retrieval mechanism would be limited to the certificates certificate retrieval mechanism would be limited to the certificates
that a user has stored (presumably from incoming messages). A that a user has stored (presumably from incoming messages). A
comprehensive certificate retrieval/storage solution may combine two comprehensive certificate retrieval/storage solution might combine
or more mechanisms to allow the greatest flexibility and utility to two or more mechanisms to allow the greatest flexibility and utility
the user. For instance, a secure Internet mail agent may resort to to the user. For instance, a secure Internet mail agent might resort
checking a centralized certificate retrieval mechanism for a to checking a centralized certificate retrieval mechanism for a
certificate if it cannot be found in a user's local certificate certificate if it cannot be found in a user's local certificate
storage/retrieval database. storage/retrieval database.
Receiving and sending agents SHOULD provide a mechanism for the Receiving and sending agents SHOULD provide a mechanism for the
import and export of certificates, using a CMS certs-only message. import and export of certificates, using a CMS certs-only message.
This allows for import and export of full certificate chains as This allows for import and export of full certificate chains as
opposed to just a single certificate. This is described in opposed to just a single certificate. This is described in
[RFC5751]. [RFC5751].
Agents MUST handle multiple valid certification authority (CA) Agents MUST handle multiple valid certification authority (CA)
skipping to change at page 12, line 42 skipping to change at page 13, line 5
4.3. Certificate and CRL Signing Algorithms and Key Sizes 4.3. Certificate and CRL Signing Algorithms and Key Sizes
Certificates and Certificate Revocation Lists (CRLs) are signed by Certificates and Certificate Revocation Lists (CRLs) are signed by
the certificate issuer. Receiving agents: the certificate issuer. Receiving agents:
- 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 PKCS#1 v1.5 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.
Implementations SHOULD use deterministic generation for the parameter Implementations SHOULD use deterministic generation for the parameter
'k' for ECDSA as outlined in [RFC6979]. EdDSA is defined to generate 'k' for ECDSA as outlined in [RFC6979]. EdDSA is defined to generate
this parameter deterministically. 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)
skipping to change at page 14, line 25 skipping to change at page 14, line 32
Interpretation and syntax for all extensions MUST follow [RFC5280], Interpretation and syntax for all extensions MUST follow [RFC5280],
unless otherwise specified here. unless otherwise specified here.
4.4.1. Basic Constraints 4.4.1. Basic Constraints
The basic constraints extension serves to delimit the role and The basic constraints extension serves to delimit the role and
position that an issuing authority or end-entity certificate plays in position that an issuing authority or end-entity certificate plays in
a certification path. a certification path.
For example, certificates issued to CAs and subordinate CAs contain a For example, certificates issued to CAs and subordinate CAs contain a
basic constraint extension that identifies them as issuing authority basic constraints extension that identifies them as issuing authority
certificates. End-entity certificates contain the key usage certificates. End-entity certificates contain the key usage
extension that restrains end entities from using the key when extension that restrains end-entities from using the key when
performing issuing authority operations (see Section 4.4.2). performing issuing authority operations (see Section 4.4.2).
As per [RFC5280], certificates MUST contain a basicConstraints As per [RFC5280], certificates MUST contain a basicConstraints
extension in CA certificates, and SHOULD NOT contain that extension extension in CA certificates, and SHOULD NOT contain that extension
in end- entity certificates. in end-entity certificates.
4.4.2. Key Usage Certificate Extension 4.4.2. Key Usage Certificate Extension
The key usage extension serves to limit the technical purposes for The key usage extension serves to limit the technical purposes for
which a public key listed in a valid certificate may be used. which a public key listed in a valid certificate may be used.
Issuing authority certificates may contain a key usage extension that Issuing authority certificates may contain a key usage extension that
restricts the key to signing certificates, certificate revocation restricts the key to signing certificates, certificate revocation
lists, and other data. lists, and other data.
For example, a certification authority may create subordinate issuer For example, a certification authority may create subordinate issuer
certificates that contain a key usage extension that specifies that certificates that contain a key usage extension that specifies that
the corresponding public key can be used to sign end user the corresponding public key can be used to sign end user
certificates and sign CRLs. certificates and sign CRLs.
If a key usage extension is included in a PKIX certificate, then it If a key usage extension is included in a PKIX certificate, then it
MUST be marked as critical. MUST be marked as critical.
S/MIME receiving agents MUST NOT accept the signature of a message if S/MIME receiving agents MUST NOT accept the signature of a message if
it was verified using a certificate that contains the key usage it was verified using a certificate that contains the key usage
extension without either the digitalSignature or nonRepudiation bit extension without at least one of the digitalSignature or
set. Sometimes S/MIME is used as a secure message transport for nonRepudiation bits set. Sometimes S/MIME is used as a secure
applications beyond interpersonal messaging. In such cases, the message transport for applications beyond interpersonal messaging; in
S/MIME-enabled application can specify additional requirements such cases, the S/MIME-enabled application can specify additional
concerning the digitalSignature or nonRepudiation bits within this requirements concerning the digitalSignature or nonRepudiation bits
extension. within this 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 both 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 ASCII email addresses present the entity for this certificate. If the local portion of the email
MUST be encoded using the rfc822Name CHOICE of the GeneralName type address is ASCII, it MUST be encoded using the rfc822Name CHOICE of
as described in [RFC5280], Section 4.2.1.6. Any internationalized the GeneralName type as described in [RFC5280], Section 4.2.1.6. If
email addresses present MUST be encoded using the otherName CHOICE of the local portion of the email address is not ASCII, it MUST be
the GeneralName type as described in [I-D.ietf-lamps-eai-addresses], encoded using the otherName CHOICE of the GeneralName type as
Section 3. Since the SubjectAltName type is a SEQUENCE OF described in [I-D.ietf-lamps-eai-addresses], Section 3. Since the
GeneralName, multiple email addresses MAY be present. SubjectAltName type is a SEQUENCE OF GeneralName, multiple email
addresses MAY be 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 17, line 14 skipping to change at page 17, line 18
It is possible for there to be multiple unexpired CRLs for a CA. If It is possible for there to be multiple unexpired CRLs for a CA. If
an agent is consulting CRLs for certificate validation, it SHOULD an agent is consulting CRLs for certificate validation, it SHOULD
make sure that the most recently issued CRL for that CA is consulted, make sure that the most recently issued CRL for that CA is consulted,
since an S/MIME message sender could deliberately include an older since an S/MIME message sender could deliberately include an older
unexpired CRL in an S/MIME message. This older CRL might not include unexpired CRL in an S/MIME message. This older CRL might not include
recently revoked certificates, which might lead an agent to accept a recently revoked certificates, which might lead an agent to accept a
certificate that has been revoked in a subsequent CRL. certificate that has been revoked in a subsequent CRL.
When determining the time for a certificate validity check, agents When determining the time for a certificate validity check, agents
have to be careful to use a reliable time. Unless it is from a have to be careful to use a reliable time. In most cases the time
trusted agent, this time MUST NOT be the SigningTime attribute found used SHOULD be the current time, some exceptions to this would be:
in an S/MIME message. For most sending agents, the SigningTime
attribute could be deliberately set to direct the receiving agent to - The time the message was received is stored in a secure manner and
check a CRL that could have out-of-date revocation status for a is used at a later time to validate the message.
certificate, or cause an improper result when checking the Validity
field of a certificate. - The time in a SigningTime attribute found in a counter signature
attribute which has been successfully validated.
The SigningTime attribute could be deliberately set to direct the
receiving agent to check a CRL that could have out-of-date revocation
status for a certificate, or cause an improper result when checking
the Validity field of a certificate. This could be done either by
the sender of the message, or an attacker which has compromised the
key of the sender.
In addition to the Security Considerations identified in [RFC5280], In addition to the Security Considerations identified in [RFC5280],
caution should be taken when processing certificates that have not caution should be taken when processing certificates that have not
first been validated to a trust anchor. Certificates could be first been validated to a trust anchor. Certificates could be
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.
RSA keys of less than 2048 bits are now considered by many experts to RSA keys of less than 2048 bits are now considered by many experts to
be cryptographically insecure (due to advances in computing power), be cryptographically insecure (due to advances in computing power),
and should no longer be used to sign certificates or CRLs. Such keys and SHOULD no longer be used to sign certificates or CRLs. Such keys
were previously considered secure, so processing previously received were previously considered secure, so processing previously received
signed and encrypted mail may require processing certificates or CRLs signed and encrypted mail may require processing certificates or CRLs
signed with weak keys. Implementations that wish to support previous signed with weak keys. Implementations that wish to support previous
versions of S/MIME or process old messages need to consider the versions of S/MIME or process old messages need to consider the
security risks that result from accepting certificates and CRLs with security risks that result from accepting certificates and CRLs with
smaller key sizes (e.g., spoofed certificates) versus the costs of smaller key sizes (e.g., spoofed certificates) versus the costs of
denial of service. If an implementation supports verification of denial of service. If an implementation supports verification of
certificates or CRLs generated with RSA and DSA keys of less than certificates or CRLs generated with RSA and DSA keys of less than
2048 bits, it MUST warn the user. Implementers should consider 2048 bits, it MUST warn the user. Implementers should consider
providing a stronger warning for weak signatures on certificates and providing a stronger warning for weak signatures on certificates and
skipping to change at page 18, line 27 skipping to change at page 18, line 40
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-08 (work in progress), March 2017. 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-04 Message Specification", draft-ietf-lamps-rfc5751-bis-06
(work in progress), March 2017. (work in progress), April 2017.
[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>. <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,
<http://www.rfc-editor.org/info/rfc2634>. <https://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
Classes and Attribute Types Version 2.0", RFC 2985, Classes and Attribute Types Version 2.0", RFC 2985,
DOI 10.17487/RFC2985, November 2000, DOI 10.17487/RFC2985, November 2000,
<http://www.rfc-editor.org/info/rfc2985>. <https://www.rfc-editor.org/info/rfc2985>.
[RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and [RFC3279] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April (CRL) Profile", RFC 3279, DOI 10.17487/RFC3279, April
2002, <http://www.rfc-editor.org/info/rfc3279>. 2002, <https://www.rfc-editor.org/info/rfc3279>.
[RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography [RFC3447] Jonsson, J. and B. Kaliski, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February Version 2.1", RFC 3447, DOI 10.17487/RFC3447, February
2003, <http://www.rfc-editor.org/info/rfc3447>. 2003, <https://www.rfc-editor.org/info/rfc3447>.
[RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional [RFC4055] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use in Algorithms and Identifiers for RSA Cryptography for use in
the Internet X.509 Public Key Infrastructure Certificate the Internet X.509 Public Key Infrastructure Certificate
and Certificate Revocation List (CRL) Profile", RFC 4055, and Certificate Revocation List (CRL) Profile", RFC 4055,
DOI 10.17487/RFC4055, June 2005, DOI 10.17487/RFC4055, June 2005,
<http://www.rfc-editor.org/info/rfc4055>. <https://www.rfc-editor.org/info/rfc4055>.
[RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in [RFC4056] Schaad, J., "Use of the RSASSA-PSS Signature Algorithm in
Cryptographic Message Syntax (CMS)", RFC 4056, Cryptographic Message Syntax (CMS)", RFC 4056,
DOI 10.17487/RFC4056, June 2005, DOI 10.17487/RFC4056, June 2005,
<http://www.rfc-editor.org/info/rfc4056>. <https://www.rfc-editor.org/info/rfc4056>.
[RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update: [RFC5035] Schaad, J., "Enhanced Security Services (ESS) Update:
Adding CertID Algorithm Agility", RFC 5035, Adding CertID Algorithm Agility", RFC 5035,
DOI 10.17487/RFC5035, August 2007, DOI 10.17487/RFC5035, August 2007,
<http://www.rfc-editor.org/info/rfc5035>. <https://www.rfc-editor.org/info/rfc5035>.
[RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S.,
Housley, R., and W. Polk, "Internet X.509 Public Key Housley, R., and W. Polk, "Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation List Infrastructure Certificate and Certificate Revocation List
(CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008,
<http://www.rfc-editor.org/info/rfc5280>. <https://www.rfc-editor.org/info/rfc5280>.
[RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70,
RFC 5652, DOI 10.17487/RFC5652, September 2009, RFC 5652, DOI 10.17487/RFC5652, September 2009,
<http://www.rfc-editor.org/info/rfc5652>. <https://www.rfc-editor.org/info/rfc5652>.
[RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5750] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Certificate Mail Extensions (S/MIME) Version 3.2 Certificate
Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010, Handling", RFC 5750, DOI 10.17487/RFC5750, January 2010,
<http://www.rfc-editor.org/info/rfc5750>. <https://www.rfc-editor.org/info/rfc5750>.
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet [RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
Mail Extensions (S/MIME) Version 3.2 Message Mail Extensions (S/MIME) Version 3.2 Message
Specification", RFC 5751, DOI 10.17487/RFC5751, January Specification", RFC 5751, DOI 10.17487/RFC5751, January
2010, <http://www.rfc-editor.org/info/rfc5751>. 2010, <https://www.rfc-editor.org/info/rfc5751>.
[RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet [RFC5755] Farrell, S., Housley, R., and S. Turner, "An Internet
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>. <https://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>. <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, <http://www.rfc-editor.org/info/rfc6979>. 2013, <https://www.rfc-editor.org/info/rfc6979>.
[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 20, line 44 skipping to change at page 21, line 9
[RFC5652], and [RFC5035]. [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.".
7.2. Informational References 7.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 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-04 (work in progress), March 2017. pkix-07 (work in progress), November 2017.
[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>. <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,
"S/MIME Version 2 Certificate Handling", RFC 2312, "S/MIME Version 2 Certificate Handling", RFC 2312,
DOI 10.17487/RFC2312, March 1998, DOI 10.17487/RFC2312, March 1998,
<http://www.rfc-editor.org/info/rfc2312>. <https://www.rfc-editor.org/info/rfc2312>.
[RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", [RFC2313] Kaliski, B., "PKCS #1: RSA Encryption Version 1.5",
RFC 2313, DOI 10.17487/RFC2313, March 1998, RFC 2313, DOI 10.17487/RFC2313, March 1998,
<http://www.rfc-editor.org/info/rfc2313>. <https://www.rfc-editor.org/info/rfc2313>.
[RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax [RFC2314] Kaliski, B., "PKCS #10: Certification Request Syntax
Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998, Version 1.5", RFC 2314, DOI 10.17487/RFC2314, March 1998,
<http://www.rfc-editor.org/info/rfc2314>. <https://www.rfc-editor.org/info/rfc2314>.
[RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax [RFC2315] Kaliski, B., "PKCS #7: Cryptographic Message Syntax
Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998, Version 1.5", RFC 2315, DOI 10.17487/RFC2315, March 1998,
<http://www.rfc-editor.org/info/rfc2315>. <https://www.rfc-editor.org/info/rfc2315>.
[RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630, [RFC2630] Housley, R., "Cryptographic Message Syntax", RFC 2630,
DOI 10.17487/RFC2630, June 1999, DOI 10.17487/RFC2630, June 1999,
<http://www.rfc-editor.org/info/rfc2630>. <https://www.rfc-editor.org/info/rfc2630>.
[RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method", [RFC2631] Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, DOI 10.17487/RFC2631, June 1999, RFC 2631, DOI 10.17487/RFC2631, June 1999,
<http://www.rfc-editor.org/info/rfc2631>. <https://www.rfc-editor.org/info/rfc2631>.
[RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate [RFC2632] Ramsdell, B., Ed., "S/MIME Version 3 Certificate
Handling", RFC 2632, DOI 10.17487/RFC2632, June 1999, Handling", RFC 2632, DOI 10.17487/RFC2632, June 1999,
<http://www.rfc-editor.org/info/rfc2632>. <https://www.rfc-editor.org/info/rfc2632>.
[RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message [RFC2633] Ramsdell, B., Ed., "S/MIME Version 3 Message
Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999, Specification", RFC 2633, DOI 10.17487/RFC2633, June 1999,
<http://www.rfc-editor.org/info/rfc2633>. <https://www.rfc-editor.org/info/rfc2633>.
[RFC3114] Nicolls, W., "Implementing Company Classification Policy [RFC3114] Nicolls, W., "Implementing Company Classification Policy
with the S/MIME Security Label", RFC 3114, with the S/MIME Security Label", RFC 3114,
DOI 10.17487/RFC3114, May 2002, DOI 10.17487/RFC3114, May 2002,
<http://www.rfc-editor.org/info/rfc3114>. <https://www.rfc-editor.org/info/rfc3114>.
[RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail [RFC3850] Ramsdell, B., Ed., "Secure/Multipurpose Internet Mail
Extensions (S/MIME) Version 3.1 Certificate Handling", Extensions (S/MIME) Version 3.1 Certificate Handling",
RFC 3850, DOI 10.17487/RFC3850, July 2004, RFC 3850, DOI 10.17487/RFC3850, July 2004,
<http://www.rfc-editor.org/info/rfc3850>. <https://www.rfc-editor.org/info/rfc3850>.
[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>. <https://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>. <https://www.rfc-editor.org/info/rfc3852>.
[RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic [RFC6090] McGrew, D., Igoe, K., and M. Salter, "Fundamental Elliptic
Curve Cryptography Algorithms", RFC 6090, Curve Cryptography Algorithms", RFC 6090,
DOI 10.17487/RFC6090, February 2011, DOI 10.17487/RFC6090, February 2011,
<http://www.rfc-editor.org/info/rfc6090>. <https://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>. <https://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>. <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,
<http://www.rfc-editor.org/info/rfc8032>. <https://www.rfc-editor.org/info/rfc8032>.
[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
skipping to change at page 24, line 4 skipping to change at page 24, line 16
messages) versus the costs of denial of service. messages) versus the costs of denial of service.
[SMIMEv3.1] set the lower limit on suggested key sizes for [SMIMEv3.1] set the lower limit on suggested key sizes for
creating and validation at 1024 bits. Prior to that the lower creating and validation at 1024 bits. Prior to that the lower
bound on key sizes was 512 bits. bound on key sizes was 512 bits.
- 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 resistant 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 [SMIMEv4.0]. 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 [SMIMEv4.0]. SHA-1 is - RSA and DSA with SHA-1 were dropped in [SMIMEv4.0]. SHA-1 is no
nolonger considered to be secure as it is no longer collision- longer 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.
- DSA with SHA-256 support was dropped in [SMIMEv4.0]. DSA was - DSA with SHA-256 support was dropped in [SMIMEv4.0]. DSA was
dropped as part of a general movement from discrete logarithms to dropped as part of a general movement from finite fields to
elliptic curves. Issues have come up dealing with small group elliptic curves. Issues have come up dealing with non-
attacks and with non-deterministic generation of the parameter 'k' deterministic generation of the parameter 'k' (see [RFC6979]).
(see [RFC6979]).
For 512-bit RSA with SHA-1 see [RFC3279] and [FIPS186-2] without 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 Change Notice 1, for 512-bit RSA with SHA-256 see [RFC4055] and
[FIPS186-2] without Change Notice 1. [FIPS186-2] without Change Notice 1.
For 512-bit DSA with SHA-1 see [RFC3279] and [FIPS186-2] without 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 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 [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 [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, 3072 DSA with SHA-256 see [RFC5758] and [FIPS186-3]. In either case,
the first reference provides the signature algorithm's object the first reference provides the signature algorithm's object
identifier and the second provides the signature algorithm's identifier and the second provides the signature algorithm's
definition. 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], v3.2 [SMIMEv3.2], and v4.0 The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], v3.2 [SMIMEv3.2], and v4.0
(this document) are backwards compatible with the S/MIME v2 (this document) are backward compatible with the S/MIME v2
Certificate Handling Specification [SMIMEv2], with the exception of Certificate Handling Specification [SMIMEv2], with the exception of
the algorithms (dropped RC2/40 requirement and added DSA and RSASSA- the algorithms (dropped RC2/40 requirement and added DSA and RSASSA-
PSS requirements). Therefore, it is recommended that RFC 2312 PSS requirements). Therefore, it is recommended that RFC 2312
[SMIMEv2] 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, v3.2 or v4.0. be a v3, v3.1, v3.2 or v4.0.
 End of changes. 67 change blocks. 
98 lines changed or deleted 110 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/