draft-ietf-lamps-rfc5750-bis-07.txt   draft-ietf-lamps-rfc5750-bis-08.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: December 23, 2018 S. Turner Expires: March 8, 2019 S. Turner
sn3rd sn3rd
June 21, 2018 September 4, 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-07 draft-ietf-lamps-rfc5750-bis-08
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 December 23, 2018. This Internet-Draft will expire on March 8, 2019.
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 48 skipping to change at page 2, line 48
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 . . . . . . . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . 11 4. Certificate Processing . . . . . . . . . . . . . . . . . . . 10
4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 11 4.1. Certificate Revocation Lists . . . . . . . . . . . . . . 11
4.2. Certificate Path Validation . . . . . . . . . . . . . . . 12 4.2. Certificate Path Validation . . . . . . . . . . . . . . . 12
4.3. Certificate and CRL Signing Algorithms and Key Sizes . . 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 4, line 18 skipping to change at page 4, line 18
Certificate: A type that binds an entity's name to a public key with Certificate: A type that binds an entity's name to a public key with
a digital signature. This type is defined in the Internet X.509 a digital signature. This type is defined in the Internet X.509
Public Key Infrastructure (PKIX) Certificate and CRL Profile Public Key Infrastructure (PKIX) Certificate and CRL Profile
[RFC5280]. This type also contains the distinguished name of the [RFC5280]. This type also contains the distinguished name of the
certificate issuer (the signer), an issuer-specific serial number, certificate issuer (the signer), an issuer-specific serial number,
the issuer's signature algorithm identifier, a validity period, and the issuer's signature algorithm identifier, a validity period, and
extensions also defined in that document. extensions also defined in that document.
Certificate Revocation List (CRL): A type that contains information Certificate Revocation List (CRL): A type that contains information
about certificates whose validity an issuer has prematurely revoked. about certificates whose validity an issuer has revoked. The
The information consists of an issuer name, the time of issue, the information consists of an issuer name, the time of issue, the next
next scheduled time of issue, a list of certificate serial numbers scheduled time of issue, a list of certificate serial numbers and
and their associated revocation times, and extensions as defined in their associated revocation times, and extensions as defined in
[RFC5280]. The CRL is signed by the issuer. The type intended by [RFC5280]. The CRL is signed by the issuer. The type intended by
this specification is the one defined in [RFC5280]. this specification is the one defined in [RFC5280].
Receiving agent: Software that interprets and processes S/MIME CMS Receiving agent: Software that interprets and processes S/MIME CMS
objects, MIME body parts that contain CMS objects, or both. objects, MIME body parts that contain CMS objects, or both.
Sending agent: Software that creates S/MIME CMS objects, MIME body Sending agent: Software that creates S/MIME CMS objects, MIME body
parts that contain CMS objects, or both. parts that contain CMS objects, or both.
S/MIME agent: User software that is a receiving agent, a sending S/MIME agent: User software that is a receiving agent, a sending
skipping to change at page 10, line 14 skipping to change at page 10, line 14
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
addresses in the Distinguished Name field in the PKCS #9 [RFC2985] addresses in the Distinguished Name field in the PKCS #9 [RFC2985]
emailAddress attribute: emailAddress attribute:
pkcs-9-at-emailAddress OBJECT IDENTIFIER ::= pkcs-9-at-emailAddress OBJECT IDENTIFIER ::=
{ iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 } { iso(1) member-body(2) us(840) rsadsi(113549) pkcs(1) pkcs-9(9) 1 }
Note that this attribute MUST be encoded as IA5String and has an Note that this attribute MUST be encoded as IA5String and has an
upper bound of 255 characters. The right side of the email address upper bound of 255 characters. Comparing of email addresses is
SHOULD be treated as ASCII-case-insensitive. fraught with peril. [I-D.ietf-lamps-eai-addresses] defines the
procedure for doing comparison of Internationalized email addresses.
Comparing of email addresses is fraught with peril. For ASCII email addresses the domain component (right-hand side of
[I-D.ietf-lamps-eai-addresses] defines the procedure for doing the '@') MUST be compared using a case-insensitive function. The
comparison of Internationalized email addresses. For ASCII email local name component (left-hand side of the '@') SHOULD be compared
addresses the domain component (right-hand side of the '@') MUST be using a case-insensitive function. Some localities may perform other
compared using a case-insensitive function. The local name component
(left-hand side of the '@') SHOULD be compared using a case-
insensitive function. Some localities may perform other
transformations on the local name component before doing the 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
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-10 Message Specification", draft-ietf-lamps-rfc5751-bis-11
(work in progress), June 2018. (work in progress), July 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 24, line 40 skipping to change at page 24, line 40
of weak keys. Implementations that wish to support previous of 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 smaller key sizes (e.g., spoofed security risks that result from smaller key sizes (e.g., spoofed
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 no 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 implies that the security considered to be collision resistant implies that the security
level of any signature that is created with that these hash level of any signature that is created with that these hash
algorithms should also be considered as suspect. 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
skipping to change at page 25, line 34 skipping to change at page 25, line 34
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 backward 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, RFC 2312 [SMIMEv2] was moved to
[SMIMEv2] be moved to Historic status. 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.
A number of the members of the S/MIME Working Group have also worked A number of the members of the S/MIME Working Group have also worked
very hard and contributed to this document. Any list of people is very hard and contributed to this document. Any list of people is
doomed to omission, and for that I apologize. In alphabetical order, doomed to omission, and for that I apologize. In alphabetical order,
 End of changes. 10 change blocks. 
24 lines changed or deleted 21 lines changed or added

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