< draft-ietf-smime-3850bis-04.txt   draft-ietf-smime-3850bis-05.txt >
S/MIME WG Blake Ramsdell, SendMail S/MIME WG Blake Ramsdell, SendMail
Internet Draft Sean Turner, IECA Internet Draft Sean Turner, IECA
Intended Status: Standard Track June 30, 2008 Intended Status: Standard Track August 20, 2008
Obsoletes: 3850 (once approved) Obsoletes: 3850 (once approved)
Expires: December 30, 2008 Expires: February 20, 2009
Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2
Certificate Handling Certificate Handling
draft-ietf-smime-3850bis-04.txt draft-ietf-smime-3850bis-05.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
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."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 30, 2008. This Internet-Draft will expire on February 20, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
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) agents. S/MIME Secure/Multipurpose Internet Mail Extensions (S/MIME) agents. S/MIME
provides a method to send and receive secure MIME messages, and provides a method to send and receive secure MIME messages, and
skipping to change at page 2, line 23 skipping to change at page 2, line 23
subscribe, send a message to ietf-smime-request@imc.org with the subscribe, send a message to ietf-smime-request@imc.org with the
single word subscribe in the body of the message. There is a Web site single word subscribe in the body of the message. There is a Web site
for the mailing list at <http://www.imc.org/ietf-smime/>. for the mailing list at <http://www.imc.org/ietf-smime/>.
Table of Contents Table of Contents
1. Introduction...................................................2 1. Introduction...................................................2
1.1. Definitions...............................................3 1.1. Definitions...............................................3
1.2. Conventions used in this document.........................4 1.2. Conventions used in this document.........................4
1.3. Compatibility with Prior Practice S/MIME..................4 1.3. Compatibility with Prior Practice S/MIME..................4
1.4. Changes Since S/MIME v3.1.................................4 1.4. Changes From S/MIME v3 to S/MIME v3.1.....................4
1.5. Changes Since S/MIME v3.1.................................5
2. CMS Options....................................................5 2. CMS Options....................................................5
2.1. Certificate Revocation Lists..............................5 2.1. Certificate Revocation Lists..............................6
2.2. Certificate Choices.......................................5 2.2. Certificate Choices.......................................6
2.3. CertificateSet............................................6 2.2.1. Historical Note About CMS Certificates...............6
3. Using Distinguished Names For Internet Mail....................7 2.3. CertificateSet............................................7
4. Certificate Processing.........................................8 3. Using Distinguished Names For Internet Mail....................8
4.1. Certificate Revocation Lists..............................9 4. Certificate Processing.........................................9
4.2. Certificate Path Validation...............................9 4.1. Certificate Revocation Lists.............................10
4.3. Certificate and CRL Signing Algorithms and Key Sizes.....10 4.2. Certificate Path Validation..............................10
4.3. Certificate and CRL Signing Algorithms and Key Sizes.....11
4.4. PKIX Certificate Extensions..............................11 4.4. PKIX Certificate Extensions..............................11
5. IANA Considerations...........................................13 5. IANA Considerations...........................................14
6. Security Considerations.......................................13 6. Security Considerations.......................................14
7. References....................................................14 7. References....................................................16
7.1. Normative References.....................................14 7.1. Normative References.....................................16
7.2. Informative References...................................15 7.2. Informative References...................................17
Appendix A. Moving S/MIME v2 Certificate Handling to Historic Appendix A. Moving S/MIME v2 Certificate Handling to Historic
Status...............................................18 Status...............................................19
Appendix B. Acknowledgements.....................................19 Appendix B. Acknowledgements.....................................19
1. Introduction 1. Introduction
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a method to send and receive secure MIME [SMIME-MSG], provides a method to send and receive secure MIME
messages. Before using a public key to provide security services, messages. Before using a public key to provide security services,
the S/MIME agent MUST verify that the public key is valid. S/MIME the S/MIME agent MUST verify that the public key is valid. S/MIME
agents MUST use PKIX certificates to validate public keys as agents MUST use PKIX certificates to validate public keys as
described in the Internet X.509 Public Key Infrastructure (PKIX) described in the Internet X.509 Public Key Infrastructure (PKIX)
skipping to change at page 3, line 17 skipping to change at page 3, line 19
This specification is compatible with the Cryptographic Message This specification is compatible with the Cryptographic Message
Syntax [CMS] in that it uses the data types defined by CMS. It also Syntax [CMS] in that it uses the data types defined by CMS. It also
inherits all the varieties of architectures for certificate-based key inherits all the varieties of architectures for certificate-based key
management supported by CMS. management supported by CMS.
1.1. Definitions 1.1. Definitions
For the purposes of this document, the following definitions apply. For the purposes of this document, the following definitions apply.
ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.208 ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680
[X.208-88]. [X.680].
Attribute Certificate (AC): An X.509 AC is a separate structure from Attribute Certificate (AC): An X.509 AC is a separate structure from
a subject's public key X.509 Certificate. A subject may have a subject's public key X.509 Certificate. A subject may have
multiple X.509 ACs associated with each of its public key X.509 multiple X.509 ACs associated with each of its public key X.509
Certificates. Each X.509 AC binds one or more Attributes with one of Certificates. Each X.509 AC binds one or more Attributes with one of
the subject's public key X.509 Certificates. The X.509 AC syntax is the subject's public key X.509 Certificates. The X.509 AC syntax is
defined in [ACAUTH]. defined in [ACAUTH].
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
skipping to change at page 4, line 38 skipping to change at page 4, line 41
1.3. Compatibility with Prior Practice S/MIME 1.3. Compatibility with Prior Practice S/MIME
S/MIME version 3.2 agents should attempt to have the greatest S/MIME version 3.2 agents should 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 [SMIMEv3], and S/MIME version 3.1 is described in RFC 3850 inclusive [SMIMEv3], and S/MIME version 3.1 is described in RFC 3850
through RFC 3852 and RFC 2634 [SMIMEv3.1]. RFC 2311 also has through RFC 3852 and RFC 2634 [SMIMEv3.1]. RFC 2311 also has
historical information about the development of S/MIME. historical information about the development of S/MIME.
1.4. Changes Since 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.
Multiple CA certificates with the same subject and public key, but
with overlapping validity periods, MUST be supported.
Version 2 attribute certificates SHOULD be supported, and version 1
attributes certificates MUST NOT be used.
The use of the MD2 digest algorithm for certificate signatures is
discouraged and security language added.
Clarified use of email address use in certificates. Certificates
that do not contain an email address have no requirements for
verifying the email address associated with the certificate.
Receiving agents SHOULD display certificate information when
displaying the results of signature verification.
Receiving agents MUST NOT accept a signature made with a certificate
that does not have the digitalSignature or nonRepudiation bit set.
Clarifications for the interpretation of the key usage and extended
key usage extensions.
1.5. Changes Since S/MIME v3.1
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-.
Sec 1.2: Updated ASN.1 definition and reference.
Sec 1.3: Added text about v3.1 RFCs. Sec 1.3: Added text about v3.1 RFCs.
Sec 3: Updated note to indicate emailAddress IA5String upper bound is Sec 3: Updated note to indicate emailAddress IA5String upper bound is
255 characters. 255 characters.
Sec 4.3: RSA with SHA-256 (PKCS #1 v1.5) added as MUST, RSA with SHA- Sec 4.3: RSA with SHA-256 (PKCS #1 v1.5) added as MUST, DSA with SHA-
1 changed to MUST-, DSA with SHA-1, and RSA with MD5 changed to 256 added as SHOULD, RSA with SHA-1 changed to SHOULD-, DSA with SHA-
SHOULD-, and RSA-PSS with SHA-256. Updated key sizes. 1, and RSA with MD5 changed to SHOULD-, and RSA-PSS with SHA-256.
Updated key sizes and changed pointer from [KEYM] to [KEYMALG].
Sec 7: Moved references from Appendix B to this section. Updated Sec 4.4.1: Clarified which extension is used to constrain EEs from
references to latest versions of PKIX profile and S/MIME Message using their keys to perform issuing authority operations.
Specification. Changed reference from KEYMALG to KEYM.
App A: Added Appendix B to move S/MIME v2 Certificate Handling to Sec 7: Moved references from Appendix B to section 7. Updated the
Historic Status. references.
Appendix A: Moved Appendix A to Appendix B. Added Appendix A to move
S/MIME v2 Certificate Handling to Historic Status.
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 [SMIME-MSG]. the CMS format for S/MIME messages is defined in [SMIME-MSG].
2.1. Certificate Revocation Lists 2.1. Certificate Revocation Lists
skipping to change at page 10, line 23 skipping to change at page 11, line 14
cache SHOULD be used to augment any other certificate and CRL cache SHOULD be used to augment any other certificate and CRL
retrieval mechanisms for path validation on incoming signed messages. retrieval mechanisms for path validation on incoming signed messages.
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 RSA with SHA-256, as specified in [CMS-SHA2] - MUST support RSA with SHA-256, as specified in [CMS-SHA2]
- MUST- support RSA with SHA-1, as specified in [CMSALG] - SHOULD+ support DSA with SHA-256, as specified in [CMS-SHA2]
- SHOULD+ support RSA-PSS with SHA-256, as specified in [RSAPSS] - SHOULD+ support RSA-PSS with SHA-256, as specified in [RSAPSS]
- SHOULD- support DSA with SHA-1, as specified in [CMSALG]. - SHOULD- support RSA with SHA-1, as specified in [CMSALG]
- SHOULD- support RSA with MD5, as specified in [CMSALG]. - SHOULD- support DSA with SHA-1, as specified in [CMSALG]
The following are the RSA and DSA key size requirements for S/MIME - SHOULD- support RSA with MD5, as specified in [CMSALG]
receiving agents during certificate and CRL signature verification:
0 < key size < 512 : MAY (see Section 6) The following are the RSA key size requirements for S/MIME receiving
512 <= key size <= 2048 : MUST (see Section 6) agents during certificate and CRL signature verification:
2048 < key size <= 4096 : MAY (see Section 6)
0 < key size < 512 : MAY (see Section 6 [SMIME-MSG])
512 <= key size <= 4096 : MUST (see Section 6 [SMIME-MSG])
4096 < key size : MAY (see Section 6 [SMIME-MSG])
The following are the RSA key size requirements for S/MIME receiving
agents during certificate and CRL signature verification:
512 <= key size <= 1024 : MAY (see Section 6 [SMIME-MSG])
4.4. PKIX Certificate Extensions 4.4. PKIX Certificate Extensions
PKIX describes an extensible framework in which the basic certificate PKIX describes an extensible framework in which the basic certificate
information can be extended and describes how such extensions can be information can be extended and describes how such extensions can be
used to control the process of issuing and validating certificates. used to control the process of issuing and validating certificates.
The PKIX Working Group has ongoing efforts to identify and create The PKIX Working Group has ongoing efforts to identify and create
extensions which have value in particular certification environments. extensions which 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
skipping to change at page 11, line 44 skipping to change at page 12, line 28
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 constraint extension that identifies them as issuing authority
certificates. End-entity certificates contain an extension that certificates. End-entity certificates contain the key usage
constrains the certificate from being an issuing authority extension which restrains EEs from using the key to performing
certificate (see Section 4.4.2). issuing authority operations (see Section 4.4.2).
Certificates SHOULD contain a basicConstraints extension in CA Certificates SHOULD contain a basicConstraints extension in CA
certificates, and SHOULD NOT contain that extension in end entity certificates, and SHOULD NOT contain that extension in end entity
certificates. 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. Issuing which a public key listed in a valid certificate may be used. Issuing
authority certificates may contain a key usage extension that authority certificates may contain a key usage extension that
skipping to change at page 14, line 34 skipping to change at page 15, line 22
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. Unless it is from a
trusted agent, this time MUST NOT be the SigningTime attribute found trusted agent, this time MUST NOT be the SigningTime attribute found
in an S/MIME message. For most sending agents, the SigningTime in an S/MIME message. For most sending agents, the SigningTime
attribute could be deliberately set to direct the receiving agent to attribute could be deliberately set to direct the receiving agent to
check a CRL that could have out-of-date revocation status for a check a CRL that could have out-of-date revocation status for a
certificate, or cause an improper result when checking the Validity certificate, or cause an improper result when checking the Validity
field of a certificate. field of a certificate.
In addition to the Security Considerations identified in [KEYM],
caution should be taken when processing certificates which have not
first been validated to a trust anchor. Certificates could be
manufactured by untrusted sources for the purpose of mounting denial
of service or other attacks. For example, keys selected to require
excessive cryptographic processing, or extensive lists of CDP and/or
AIA addresses in the certificate, could be used to mount denial of
service attacks. Similarly, originator-specified CDP and/or AIA
addresses could be inserted into bogus certificates to allow the
originator to detect receipt of the message even if signature
verification fails.
In addition to the Security Considerations identified in [KEYM],
caution should be taken when processing certificates which have not
first been validated to a trust anchor. Certificates could be
manufactured by untrusted sources for the purpose of mounting denial
of service or other attacks. For example, keys selected to require
excessive cryptographic processing, or extensive lists of CDP and/or
AIA addresses in the certificate, could be used to mount denial of
service attacks. Similarly, attacker-specified CRL distribution
point and/or authority information access addresses could be included
into fake certificates to allow the originator to detect receipt of
the message even if signature verification fails.
7. References 7. References
7.1. Normative References 7.1. Normative References
[ACAUTH] Farrell, S. and R. Housley, "An Internet Attribute [ACAUTH] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April Certificate Profile for Authorization", RFC 3281, April
2002. 2002.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004. 3852, July 2004.
skipping to change at page 15, line 13 skipping to change at page 16, line 30
Algorithms", RFC 3370, August 2002. Algorithms", RFC 3370, August 2002.
[CMS-SHA2] Turner. S., "Using SHA2 Algorithms with Cryptographic [CMS-SHA2] Turner. S., "Using SHA2 Algorithms with Cryptographic
Message Syntax", work in progress. Message Syntax", work in progress.
[KEYM] Cooper, D., Santesson, S., Farrell, S., Boeyen, S. [KEYM] 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 Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 5280, May 2008. List (CRL) Profile", RFC 5280, May 2008.
[KEYMALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3279, April 2002.
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[PKCS9] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object [PKCS9] 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,
November 2000. November 2000.
[IMF] Resnick, P., "Internet Message Format", work-in- [IMF] Resnick, P., "Internet Message Format", work-in-
progress. progress.
[RSAPSS] Schaad, J., "Use of RSASA-PSS Signature Algorithm in [RSAPSS] Schaad, J., "Use of RSASA-PSS Signature Algorithm in
Cryptographic Message Syntax (CMS)", RFC 4056, June Cryptographic Message Syntax (CMS)", RFC 4056, June
2005. 2005.
[SMIME-MSG] Ramsdell, B., and S. Turner, "S/MIME Version 3.2 [SMIME-MSG] Ramsdell, B., and S. Turner, "S/MIME Version 3.2
Message Specification", work in progress. Message Specification", work in progress.
[X.208-88] ITU-T Recommendation X.208 (1988) | ISO/IEC ISO/IEC [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-
8824-1:1988. Specification of Abstract Syntax Notation 1:2002. Information Technology - Abstract Syntax
One (ASN.1). Notation One (ASN.1): Specification of basic notation.
7.2. Informative References 7.2. Informative References
[PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax [PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax
Standard", November 1993. Standard", November 1993.
[SECLABEL] Nicolls, W., "Implementing Company Classification [SECLABEL] Nicolls, W., "Implementing Company Classification
Policy with the S/MIME Security Label", RFC 3114, May Policy with the S/MIME Security Label", RFC 3114, May
2002. 2002.
skipping to change at page 19, line 17 skipping to change at page 19, line 26
Many thanks go out to the other authors of the S/MIME v2 RFC: Steve Many thanks go out to the other authors of the S/MIME v2 RFC: Steve
Dusse, Paul Hoffman and Jeff Weinstein. Without v2, there wouldn't Dusse, Paul Hoffman and Jeff Weinstein. Without v2, there wouldn't
be a v3, v3.1 or v3.2. be a v3, v3.1 or v3.2.
A number of the members of the S/MIME Working Group have also worked A number of the members of the S/MIME Working Group have also worked
very hard and contributed to this document. Any list of people is very hard and contributed to this document. Any list of people is
doomed to omission and for that I apologize. In alphabetical order, doomed to omission and for that I apologize. In alphabetical order,
the following people stand out in my mind due to the fact that they the following people stand out in my mind due to the fact that they
made direct contributions to this document. made direct contributions to this document.
Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Paul Hoffman, Russ Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Alfred Hoenes, Paul
Housley, David P. Kemp, Michael Myers, John Pawling, Denis Pinkas, Hoffman, Russ Housley, David P. Kemp, Michael Myers, John Pawling,
Jim Schaad, and Alfred Hoenes. Denis Pinkas, and Jim Schaad.
Author's Addresses Author's Addresses
Blake Ramsdell Blake Ramsdell
SendMail SendMail
Email: blake@sendmail.com Email: blake@sendmail.com
Sean Turner Sean Turner
 End of changes. 24 change blocks. 
47 lines changed or deleted 116 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/