< draft-ietf-smime-3850bis-00.txt   draft-ietf-smime-3850bis-01.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 November 5, 2007 Intended Status: Standard Track February 21, 2008
Expires: April 5, 2008 Obsoletes: 3850 (once approved)
Expires: August 21, 2008
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-00.txt draft-ietf-smime-3850bis-01.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 34 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 April 5, 2007. This Internet-Draft will expire on August 21, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). 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
certificates are an integral part of S/MIME agent processing. S/MIME certificates are an integral part of S/MIME agent processing. S/MIME
agents validate certificates as described in RFC 3280bis, the agents validate certificates as described in RFC 3280bis, the
Internet X.509 Public Key Infrastructure Certificate and CRL Profile. Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
S/MIME agents must meet the certificate processing requirements in S/MIME agents must meet the certificate processing requirements in
this document as well as those in RFC 3280bis. This document this document as well as those in RFC 3280bis. This document
obsoletes RFC 3850. obsoletes RFC 3850.
Conventions used in this document Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [MUSTSHOULD]. document are to be interpreted as described in [MUSTSHOULD].
We define some additional terms here:
SHOULD+ This term means the same as SHOULD. However, it is likely
that an algorithm marked as SHOULD+ will be promoted at some
future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, an algorithm
marked as SHOULD- may be deprecated to a MAY in a future version
of this document.
MUST- This term means the same as MUST. However, we expect at some
point that this algorithm will no longer be a MUST in a future
document. Although its status will be determined at a later
time, it is reasonable to expect that if a future revision of a
document alters the status of a MUST- algorithm, it will remain
at least a SHOULD or a SHOULD-.
Discussion Discussion
This draft is being discussed on the 'ietf-smime' mailing list. To This draft is being discussed on the 'ietf-smime' mailing list. To
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...................................................3
1.1. Definitions...............................................3 1.1. Definitions...............................................3
1.2. Compatibility with Prior Practice S/MIME..................4 1.2. Compatibility with Prior Practice S/MIME..................4
1.3. Changes Since S/MIME V3.1 (RFC 3850)......................4 1.3. Changes Since S/MIME V3.1 (RFC 3850)......................4
2. CMS Options....................................................4 2. CMS Options....................................................5
2.1. Certificate Revocation Lists..............................4 2.1. Certificate Revocation Lists..............................5
2.2. Certificate Choices.......................................5 2.2. Certificate Choices.......................................5
2.2.1. Historical Note About CMS Certificates...............5 2.2.1. Historical Note About CMS Certificates...............5
2.3. CertificateSet............................................5 2.3. CertificateSet............................................6
3. Using Distinguished Names For Internet Mail....................6
4. Certificate Processing.........................................7 3. Using Distinguished Names For Internet Mail....................7
4.1. Certificate Revocation Lists..............................8 4. Certificate Processing.........................................8
4.1. Certificate Revocation Lists..............................9
4.2. Certificate Path Validation...............................9 4.2. Certificate Path Validation...............................9
4.3. Certificate and CRL Signing Algorithms...................10 4.3. Certificate and CRL Signing Algorithms...................10
4.4. PKIX Certificate Extensions..............................10 4.4. PKIX Certificate Extensions..............................10
4.4.1. Basic Constraints...................................11 4.4.1. Basic Constraints...................................11
4.4.2. Key Usage Certificate Extension.....................11 4.4.2. Key Usage Certificate Extension.....................11
4.4.3. Subject Alternative Name............................12 4.4.3. Subject Alternative Name............................12
4.4.4. Extended Key Usage Extension........................12 4.4.4. Extended Key Usage Extension........................12
5. IANA Considerations...........................................12 5. IANA Considerations...........................................12
6. Security Considerations.......................................12 6. Security Considerations.......................................13
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)
Certificate and CRL Profile [KEYM]. S/MIME agents MUST meet the Certificate and CRL Profile [KEYM]. S/MIME agents MUST meet the
skipping to change at page 4, line 20 skipping to change at page 4, line 39
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
S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive, S/MIME version 3 is described in RFC 2630 through RFC 2634 inclusive,
and S/MIME version 3.1 is described in RFC 3850 through 3851 and S/MIME version 3.1 is described in RFC 3850 through 3851
inclusive and RFC 2634. RFC 2311 also has historical information inclusive and RFC 2634. RFC 2311 also has historical information
about the development of S/MIME. about the development of S/MIME.
1.3. Changes Since S/MIME V3.1 (RFC 3850) 1.3. Changes Since S/MIME V3.1 (RFC 3850)
Conventions Used in This Document: Added definitions for SHOULD+,
SHOULD-, and MUST-.
Sec 1.2: Added text about v3.1 RFCs. Sec 1.2: 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, RSA with SHA-
1 changed to MUST-, DSA with SHA-1, and RSA with MD5 changed to 1 changed to MUST-, DSA with SHA-1, and RSA with MD5 changed to
SHOULD-, and RSA-PS with SHA-256, ECDSA with SHA-256 added as SHOULD-, and RSA-PS with SHA-256. Updated key sizes.
SHOULD+.
Sec A.1: Updated references to latest versions of PKIX profile and Sec A.1: Updated references to latest versions of PKIX profile and
S/MIME Message Specification. S/MIME Message Specification.
Sec A.1: Changed reference from KEYMALG to KEYM. Sec A.1: Changed reference from KEYMALG to KEYM.
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
skipping to change at page 10, line 16 skipping to change at page 10, line 27
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] - MUST- support RSA with SHA-1, as specified in [CMSALG]
- SHOULD+ support RSA-PSS with SHA-256, as specified in [RSAPSS] - SHOULD+ support RSA-PSS with SHA-256, as specified in [RSAPSS]
- SHOULD+ support ECDSA with SHA-256, as specified in [CMS-SHA2]
- SHOULD- support DSA with SHA-1, as specified in [CMSALG]. - SHOULD- support DSA with SHA-1, as specified in [CMSALG].
- SHOULD- support RSA with MD5, as specified in [CMSALG]. - SHOULD- support RSA with MD5, as specified in [CMSALG].
Key sizes from 512 bits to 2048 bits MUST be supported. Key sizes from 1024 bits to 2048 bits MUST be supported.
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 how such extensions can be used to information can be extended and how such extensions can be used to
control the process of issuing and validating certificates. The PKIX control the process of issuing and validating certificates. The PKIX
Working Group has ongoing efforts to identify and create extensions Working Group has ongoing efforts to identify and create extensions
which have value in particular certification environments. Further, which have value in particular certification environments. Further,
there are active efforts underway to issue PKIX certificates for there are active efforts underway to issue PKIX certificates for
business purposes. This document identifies the minimum required set business purposes. This document identifies the minimum required set
skipping to change at page 15, line 40 skipping to change at page 15, line 40
[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.
[RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April [RFC-2822] Resnick, P., "Internet Message Format", RFC 2822, April
2001. 2001.
[RSAPSS] Schaad, J., "Use of RSASA-PSS Signature Algorithm in
Cryptographic Message Syntax (CMS)", RFC 4056, June
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: Specification of Abstract [X.208-88] ITU-T. Recommendation X.208: Specification of Abstract
Syntax Notation One (ASN.1). 1988. Syntax Notation One (ASN.1). 1988.
A.2. Informative References A.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.
skipping to change at page 17, line 26 skipping to change at page 17, line 26
Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Paul Hoffman, Russ Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Paul Hoffman, Russ
Housley, David P. Kemp, Michael Myers, John Pawling, Denis Pinkas, Housley, David P. Kemp, Michael Myers, John Pawling, Denis Pinkas,
Jim Schaad. Jim Schaad.
Author's Addresses Author's Addresses
Blake Ramsdell Blake Ramsdell
SendMail SendMail
Email: ramsdell (at) sendmail (dot) com Email: ramsdell@sendmail.com
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
3057 Nutley Street, Suite 106
Fairfax, VA 22031
USA
Email: turners (at) ieca (dot) com Email: turners@ieca.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
skipping to change at page 18, line 42 skipping to change at page 18, line 42
Copies of IPR disclosures made to the IETF Secretariat and any Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf- this standard. Please address the information to the IETF at
ipr@ietf.org. ietf-ipr@ietf.org.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is provided by the IETF Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA). Administrative Support Activity (IASA).
 End of changes. 20 change blocks. 
23 lines changed or deleted 50 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/