< draft-ietf-lamps-rfc5750-bis-06.txt   draft-ietf-lamps-rfc5750-bis-07.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: November 3, 2018 S. Turner Expires: December 23, 2018 S. Turner
sn3rd sn3rd
May 2, 2018 June 21, 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-06 draft-ietf-lamps-rfc5750-bis-07
Abstract Abstract
This document specifies conventions for X.509 certificate usage by This document specifies conventions for X.509 certificate usage by
Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents. Secure/Multipurpose Internet Mail Extensions (S/MIME) v4.0 agents.
S/MIME provides a method to send and receive secure MIME messages, S/MIME provides a method to send and receive secure MIME messages,
and certificates are an integral part of S/MIME agent processing. and certificates are an integral part of S/MIME agent processing.
S/MIME agents validate certificates as described in RFC 5280, the S/MIME agents validate certificates as described in RFC 5280, the
Internet X.509 Public Key Infrastructure Certificate and CRL Profile. Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
S/MIME agents must meet the certificate processing requirements in S/MIME agents must meet the certificate processing requirements in
skipping to change at page 2, line 4 skipping to change at page 2, line 4
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 3, 2018. This Internet-Draft will expire on December 23, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 44 skipping to change at page 2, line 44
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Definitions . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Conventions Used in This Document . . . . . . . . . . . . 4 1.2. Conventions Used in This Document . . . . . . . . . . . . 4
1.3. Compatibility with Prior Practice S/MIME . . . . . . . . 5 1.3. Compatibility with Prior Practice S/MIME . . . . . . . . 5
1.4. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 5 1.4. Changes from S/MIME v3 to S/MIME v3.1 . . . . . . . . . . 5
1.5. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 6 1.5. Changes from S/MIME v3.1 to S/MIME v3.2 . . . . . . . . . 6
1.6. Changes since S/MIME 3.2 . . . . . . . . . . . . . . . . 7 1.6. Changes since S/MIME 3.2 . . . . . . . . . . . . . . . . 7
2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 7 2. CMS Options . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.1. Certificate Revocation Lists . . . . . . . . . . . . . . 7 2.1. Certificate Revocation Lists . . . . . . . . . . . . . . 7
2.2. Certificate Choices . . . . . . . . . . . . . . . . . . . 7 2.2. Certificate Choices . . . . . . . . . . . . . . . . . . . 8
2.2.1. Historical Note about CMS Certificates . . . . . . . 8 2.2.1. Historical Note about CMS Certificates . . . . . . . 8
2.3. CertificateSet . . . . . . . . . . . . . . . . . . . . . 8 2.3. CertificateSet . . . . . . . . . . . . . . . . . . . . . 8
3. Using Distinguished Names for Internet Mail . . . . . . . . . 9 3. Using Distinguished Names for Internet Mail . . . . . . . . . 9
4. Certificate Processing . . . . . . . . . . . . . . . . . . . 10 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 11
4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 11 4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 11
4.2. Certificate Path Validation . . . . . . . . . . . . . . . 12 4.2. Certificate Path Validation . . . . . . . . . . . . . . . 12
4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 13 4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 13
4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 14 4.4. PKIX Certificate Extensions . . . . . . . . . . . . . . . 14
4.4.1. Basic Constraints . . . . . . . . . . . . . . . . . . 14 4.4.1. Basic Constraints . . . . . . . . . . . . . . . . . . 14
4.4.2. Key Usage Certificate Extension . . . . . . . . . . . 15 4.4.2. Key Usage Certificate Extension . . . . . . . . . . . 15
4.4.3. Subject Alternative Name . . . . . . . . . . . . . . 15 4.4.3. Subject Alternative Name . . . . . . . . . . . . . . 15
4.4.4. Extended Key Usage Extension . . . . . . . . . . . . 16 4.4.4. Extended Key Usage Extension . . . . . . . . . . . . 16
5. IANA Considertions . . . . . . . . . . . . . . . . . . . . . 16 5. IANA Considertions . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
skipping to change at page 5, line 15 skipping to change at page 5, line 15
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-.
The term RSA in this document almost always refers to the PKCS#1 v1.5 The term RSA in this document almost always refers to the PKCS#1 v1.5
RSA signature algorithm even when not qualified as such. There are a RSA signature algorithm even when not qualified as such. There are a
couple of places where it refers to the general RSA cryptographic couple of places where it refers to the general RSA cryptographic
operation, these can be determined from the context where it is used. operation; these can be determined from the context where it is used.
1.3. Compatibility with Prior Practice S/MIME 1.3. Compatibility with Prior Practice S/MIME
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 that 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 artifacts such as messages or files, but
SHOULD NOT be used for new artifacts.
1.4. Changes from S/MIME v3 to S/MIME v3.1 1.4. Changes from S/MIME v3 to S/MIME v3.1
This section reflects the changes that were made when S/MIME v3.1 was
released. The RFC2119 langauage may have superceeded in later
versions.
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.
The use of the MD2 digest algorithm for certificate signatures is The use of the MD2 digest algorithm for certificate signatures is
skipping to change at page 6, line 17 skipping to change at page 6, line 21
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 at least one of the the digitalSignature or that does not have at least one of the the digitalSignature or
nonRepudiation bits set. 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
This section reflects the changes that were made when S/MIME v3.2 was
released. The RFC2119 langauage may have superceeded in later
versions.
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
characters. Added text about matching email addresses. characters. Added text about matching email addresses.
skipping to change at page 7, line 7 skipping to change at page 7, line 13
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 since S/MIME 3.2 1.6. Changes since S/MIME 3.2
This section reflects the changes that were made when S/MIME v4.0 was
released. The RFC2119 langauage may have superceeded in later
versions.
Section 3: Require support for internationalized email addresses. Section 3: Require support for internationalized email addresses.
Section 4.3: Mandated support for ECDSA with P-256 and Ed25519. Section 4.3: Mandated support for ECDSA with P-256 and Ed25519.
Moved algorithms with SHA-1 and MD5 to historical status. Moved algorithms with SHA-1 and MD5 to historical status.
Moved DSA support to historical status. Increased lower Moved DSA support to historical status. Increased lower
bounds on RSA key sizes. bounds on RSA key sizes.
Appendix A: Add a new appendix for algorithms that are now considered Appendix A: Add a new appendix for algorithms that are now considered
to be historical. to be historical.
2. CMS Options 2. CMS Options
The CMS message format allows for a wide variety of options in The CMS message format allows for a wide variety of options in
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
[I-D.ietf-lamps-rfc5751-bis].
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.
Receiving agents MUST support both v1 and v2 CRLs. 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
skipping to change at page 8, line 15 skipping to change at page 8, line 25
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 parser and process a message Receiving agents MUST be able to parse and process a message
containing PKCS #6 extended certificates although ignoring those containing PKCS #6 extended certificates although ignoring those
certificates is expected behavior. certificates is expected behavior.
X.509 version 1 attribute certificates are also not widely X.509 version 1 attribute certificates are also not widely
implemented, and have been superseded with version 2 attribute implemented, and have been superseded with version 2 attribute
certificates. Sending agents MUST NOT send version 1 attribute certificates. Sending agents MUST NOT send version 1 attribute
certificates. certificates.
2.3. CertificateSet 2.3. CertificateSet
skipping to change at page 8, line 45 skipping to change at page 9, line 6
key(s) and associated issuer certificates. This increases the key(s) and associated issuer certificates. This increases the
likelihood that the intended recipient can establish trust in the likelihood that the intended recipient can establish trust in the
originator's public key(s). This is especially important when originator's public key(s). This is especially important when
sending a message to recipients that may not have access to the sending a message to recipients that may not have access to the
sender's public key through any other means or when sending a signed sender's public key through any other means or when sending a signed
message to a new recipient. The inclusion of certificates in message to a new recipient. The inclusion of certificates in
outgoing messages can be omitted if S/MIME objects are sent within a outgoing messages can be omitted if S/MIME objects are sent within a
group of correspondents that has established access to each other's group of correspondents that has established access to each other's
certificates by some other means such as a shared directory or manual certificates by some other means such as a shared directory or manual
certificate distribution. Receiving S/MIME agents SHOULD be able to certificate distribution. Receiving S/MIME agents SHOULD be able to
handle messages without certificates using a database or directory handle messages without certificates by using a database or directory
lookup scheme. lookup scheme to find them.
A sending agent SHOULD include at least one chain of certificates up A sending agent SHOULD include at least one chain of certificates up
to, but not including, a certification authority (CA) that it to, but not including, a certification authority (CA) that it
believes that the recipient may trust as authoritative. A receiving believes that the recipient may trust as authoritative. A receiving
agent MUST be able to handle an arbitrarily large number of agent MUST be able to handle an arbitrarily large number of
certificates and chains. certificates and chains.
Agents MAY send CA certificates, that is, cross-certificates, self- Agents MAY send CA certificates, that is, cross-certificates, self-
issued certificates, and self-signed certificates. Note that issued certificates, and self-signed certificates. Note that
receiving agents SHOULD NOT simply trust any self-signed certificates receiving agents SHOULD NOT simply trust any self-signed certificates
skipping to change at page 10, line 26 skipping to change at page 10, line 34
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, this alternate processing of the message if this comparison fails; this
might be done by displaying or logging a message that shows the might be done by displaying or logging a message that shows the
recipient the mail addresses in the certificate or other certificate recipient the mail addresses in the certificate or other certificate
details. 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
skipping to change at page 11, line 39 skipping to change at page 11, line 51
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)
certificates containing the same subject name and the same public certificates containing the same subject name and the same public
keys but with overlapping validity intervals. keys but with overlapping validity intervals.
4.1. Certificate Revocation Lists 4.1. Certificate Revocation Lists
In general, it is always better to get the latest CRL information In general, it is always better to get the latest CRL information
from a CA than to get information stored away from incoming messages. from a CA than to get information stored in an incoming messages. A
A receiving agent SHOULD have access to some CRL retrieval mechanism receiving agent SHOULD have access to some CRL retrieval mechanism in
in order to gain access to certificate revocation information when order to gain access to certificate revocation information when
validating certification paths. A receiving or sending agent SHOULD validating certification paths. A receiving or sending agent SHOULD
also provide a mechanism to allow a user to store incoming also provide a mechanism to allow a user to store incoming
certificate revocation information for correspondents in such a way certificate revocation information for correspondents in such a way
so as to guarantee its later retrieval. so as to guarantee its later retrieval.
Receiving and sending agents SHOULD retrieve and utilize CRL Receiving and sending agents SHOULD retrieve and utilize CRL
information every time a certificate is verified as part of a information every time a certificate is verified as part of a
certification path validation even if the certificate was already certification path validation even if the certificate was already
verified in the past. However, in many instances (such as off-line verified in the past. However, in many instances (such as off-line
verification) access to the latest CRL information may be difficult verification) access to the latest CRL information may be difficult
skipping to change at page 12, line 18 skipping to change at page 12, line 29
associated with particular certification paths. associated with particular certification paths.
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.
4.2. Certificate Path Validation 4.2. Certificate Path Validation
In creating a user agent for secure messaging, certificate, CRL, and In creating a user agent for secure messaging, certificate, CRL, and
certification path validation SHOULD be highly automated while still certification path validation should be highly automated while still
acting in the best interests of the user. Certificate, CRL, and path acting in the best interests of the user. Certificate, CRL, and path
validation MUST be performed as per [RFC5280] when validating a validation MUST be performed as per [RFC5280] when validating a
correspondent's public key. This is necessary before using a public correspondent's public key. This is necessary before using a public
key to provide security services such as verifying a signature, key to provide security services such as verifying a signature,
encrypting a content-encryption key (e.g., RSA), or forming a encrypting a content-encryption key (e.g., RSA), or forming a
pairwise symmetric key (e.g., Diffie-Hellman) to be used to encrypt pairwise symmetric key (e.g., Diffie-Hellman) to be used to encrypt
or decrypt a content-encryption key. or decrypt a content-encryption key.
Certificates and CRLs are made available to the path validation Certificates and CRLs are made available to the path validation
procedure in two ways: a) incoming messages, and b) certificate and procedure in two ways: a) incoming messages, and b) certificate and
skipping to change at page 14, line 12 skipping to change at page 14, line 22
For EdDSA see [I-D.ietf-curdle-pkix] and [RFC8032]. The first For EdDSA see [I-D.ietf-curdle-pkix] and [RFC8032]. The first
reference provides the signature algorithm's object identifier and reference provides the signature algorithm's object identifier and
the second provides the signature algorithm's definition. Other the second provides the signature algorithm's definition. Other
curves than curve 25519 MAY be used as well. curves than curve 25519 MAY be used as well.
4.4. PKIX Certificate Extensions 4.4. PKIX Certificate Extensions
PKIX describes an extensible framework in which the basic certificate PKIX describes an extensible framework in which the basic certificate
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 LAMPS 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
S/MIME environment. The syntax and semantics of all the identified S/MIME environment. The syntax and semantics of all the identified
extensions are defined in [RFC5280]. extensions are defined in [RFC5280].
Sending and receiving agents MUST correctly handle the basic Sending and receiving agents MUST correctly handle the basic
constraints, key usage, authority key identifier, subject key constraints, key usage, authority key identifier, subject key
identifier, and subject alternative names certificate extensions when identifier, and subject alternative names certificate extensions when
skipping to change at page 19, line 18 skipping to change at page 19, line 18
Processing Standards Publication 186-3, June 2009. Processing Standards Publication 186-3, June 2009.
[I-D.ietf-lamps-eai-addresses] [I-D.ietf-lamps-eai-addresses]
Melnikov, A. and W. Chuang, "Internationalized Email Melnikov, A. and W. Chuang, "Internationalized Email
Addresses in X.509 certificates", draft-ietf-lamps-eai- Addresses in X.509 certificates", draft-ietf-lamps-eai-
addresses-18 (work in progress), March 2018. addresses-18 (work in progress), March 2018.
[I-D.ietf-lamps-rfc5751-bis] [I-D.ietf-lamps-rfc5751-bis]
Schaad, J., Ramsdell, B., and S. Turner, "Secure/ Schaad, J., Ramsdell, B., and S. Turner, "Secure/
Multipurpose Internet Mail Extensions (S/MIME) Version 4.0 Multipurpose Internet Mail Extensions (S/MIME) Version 4.0
Message Specification", draft-ietf-lamps-rfc5751-bis-08 Message Specification", draft-ietf-lamps-rfc5751-bis-10
(work in progress), May 2018. (work in progress), June 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME", [RFC2634] Hoffman, P., Ed., "Enhanced Security Services for S/MIME",
RFC 2634, DOI 10.17487/RFC2634, June 1999, RFC 2634, DOI 10.17487/RFC2634, June 1999,
<https://www.rfc-editor.org/info/rfc2634>. <https://www.rfc-editor.org/info/rfc2634>.
skipping to change at page 21, line 39 skipping to change at page 21, line 39
[ESS] "Enhanced Security Services for S/ MIME". [ESS] "Enhanced Security Services for S/ MIME".
This is the set of documents dealing with enhanced This is the set of documents dealing with enhanced
security services and refers to [RFC2634] and [RFC5035]. security services and refers to [RFC2634] and [RFC5035].
[I-D.ietf-curdle-pkix] [I-D.ietf-curdle-pkix]
Josefsson, S. and J. Schaad, "Algorithm Identifiers for Josefsson, S. and J. Schaad, "Algorithm Identifiers for
Ed25519, Ed448, X25519 and X448 for use in the Internet Ed25519, Ed448, X25519 and X448 for use in the Internet
X.509 Public Key Infrastructure", draft-ietf-curdle- X.509 Public Key Infrastructure", draft-ietf-curdle-
pkix-09 (work in progress), April 2018. pkix-10 (work in progress), May 2018.
[PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax [PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax
Standard", November 1993. Standard", November 1993.
[RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and [RFC2311] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L., and
L. Repka, "S/MIME Version 2 Message Specification", L. Repka, "S/MIME Version 2 Message Specification",
RFC 2311, DOI 10.17487/RFC2311, March 1998, RFC 2311, DOI 10.17487/RFC2311, March 1998,
<https://www.rfc-editor.org/info/rfc2311>. <https://www.rfc-editor.org/info/rfc2311>.
[RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein, [RFC2312] Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein,
skipping to change at page 24, line 43 skipping to change at page 24, line 43
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 resistant the security levels of the considered to be collision resistant implies that the security
signatures are generally considered suspect. level of any signature that is created with that these hash
algorithms should also be considered as suspect.
The following algorithms have been called out for some level of 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 no - RSA and DSA with SHA-1 were dropped in [SMIMEv4.0]. SHA-1 is no
longer considered to be secure as it is no longer collision- longer considered to be secure as it is no longer collision-
 End of changes. 21 change blocks. 
23 lines changed or deleted 38 lines changed or added

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