< draft-ietf-smime-3850bis-02.txt   draft-ietf-smime-3850bis-03.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 May 12, 2008 Intended Status: Standard Track June 3, 2008
Obsoletes: 3850 (once approved) Obsoletes: 3850 (once approved)
Expires: November 12, 2008 Expires: December 3, 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-02.txt draft-ietf-smime-3850bis-03.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 November 12, 2008. This Internet-Draft will expire on December 3, 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
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
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
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...................................................3 1. Introduction...................................................2
1.1. Definitions...............................................3 1.1. Definitions...............................................3
1.2. Compatibility with Prior Practice S/MIME..................4 1.2. Conventions used in this document.........................4
1.3. Changes Since S/MIME V3.1 (RFC 3850)......................4 1.3. Compatibility with Prior Practice S/MIME..................4
1.4. Changes Since S/MIME V3.1 (RFC 3850)......................4
2. CMS Options....................................................5 2. CMS Options....................................................5
2.1. Certificate Revocation Lists..............................5 2.1. Certificate Revocation Lists..............................5
2.2. Certificate Choices.......................................5 2.2. Certificate Choices.......................................5
2.2.1. Historical Note About CMS Certificates...............6 2.2.1. Historical Note About CMS Certificates...............5
2.3. CertificateSet............................................6 2.3. CertificateSet............................................6
3. Using Distinguished Names For Internet Mail....................7 3. Using Distinguished Names For Internet Mail....................7
4. Certificate Processing.........................................8 4. Certificate Processing.........................................8
4.1. Certificate Revocation Lists..............................9 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 and Key Sizes.....10
4.4. PKIX Certificate Extensions..............................10 4.4. PKIX Certificate Extensions..............................11
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.....................12
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...........................................13 5. IANA Considerations...........................................13
6. Security Considerations.......................................13 6. Security Considerations.......................................13
Appendix A. References...........................................15
A.1. Normative References.....................................15
A.2. Informative References...................................16
Appendix B. Acknowledgements.....................................17
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 37 skipping to change at page 4, line 8
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
agent, or both. agent, or both.
1.2. Compatibility with Prior Practice S/MIME 1.2. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [MUSTSHOULD].
We define some additional terms here:
SHOULD+ This term means the same as SHOULD. However, the authors
expect that a requirement marked as SHOULD+ will be promoted at
some future time to be a MUST.
SHOULD- This term means the same as SHOULD. However, the authors
expect a requirement marked as SHOULD- will be demoted to a MAY
in a future version of this document.
MUST- This term means the same as MUST. However, the authors
expect that this requirement 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- requirement, it will remain
at least a SHOULD or a SHOULD-.
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
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.4. Changes Since S/MIME V3.1 (RFC 3850)
Conventions Used in This Document: Added definitions for SHOULD+, Conventions Used in This Document: Moved to section 1.2. Added
SHOULD-, and MUST-. 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. Updated key sizes. SHOULD-, and RSA-PS with SHA-256. Updated key sizes.
skipping to change at page 7, line 30 skipping to change at page 7, line 22
Receiving agents SHOULD support the decoding of X.509 attribute Receiving agents SHOULD support the decoding of X.509 attribute
certificates included in CMS objects. All other issues regarding the certificates included in CMS objects. All other issues regarding the
generation and use of X.509 attribute certificates are outside of the generation and use of X.509 attribute certificates are outside of the
scope of this specification. One specification that addresses scope of this specification. One specification that addresses
attribute certificate use is defined in [SECLABEL]. attribute certificate use is defined in [SECLABEL].
3. Using Distinguished Names For Internet Mail 3. Using Distinguished Names For Internet Mail
End-entity certificates MAY contain an Internet mail address as End-entity certificates MAY contain an Internet mail address as
described in [RFC-2822]. The address must be an "addr-spec" as described in [IMF]. The address must be an "addr-spec" as defined in
defined in Section 3.4.1 of that specification. The email address Section 3.4.1 of that specification. The email address SHOULD be in
SHOULD be in the subjectAltName extension, and SHOULD NOT be in the the subjectAltName extension, and SHOULD NOT be in the subject
subject distinguished name. distinguished name.
Receiving agents MUST recognize and accept certificates that contain Receiving agents MUST recognize and accept certificates that contain
no email address. Agents are allowed to provide an alternative no email address. Agents are allowed to provide an alternative
mechanism for associating an email address with a certificate that mechanism for associating an email address with a certificate that
does not contain an email address, such as through the use of the does not contain an email address, such as through the use of the
agent's address book, if available. Receiving agents MUST recognize agent's address book, if available. Receiving agents MUST recognize
email addresses in the subjectAltName field. Receiving agents MUST email addresses in the subjectAltName field. Receiving agents MUST
recognize email addresses in the Distinguished Name field in the PKCS recognize email addresses in the Distinguished Name field in the PKCS
#9 [PKCS9] emailAddress attribute: #9 [PKCS9] 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 bounds of 255 characters. upper bound of 255 characters.
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, if present, in the signer's certificate, if mail addresses address, if present, in the signer's certificate, if mail addresses
are present in the certificate. A receiving agent SHOULD provide are present in the certificate. A receiving agent SHOULD provide
some explicit alternate processing of the message if this comparison some explicit alternate processing of the message if this comparison
fails, which may be to display a message that shows the recipient the fails, which may be to display a message that shows the recipient the
addresses in the certificate or other certificate details. addresses in the certificate or other certificate details.
skipping to change at page 10, line 23 skipping to change at page 10, line 16
procedure in two ways: a) incoming messages, and b) certificate and procedure in two ways: a) incoming messages, and b) certificate and
CRL retrieval mechanisms. Certificates and CRLs in incoming messages CRL retrieval mechanisms. Certificates and CRLs in incoming messages
are not required to be in any particular order nor are they required are not required to be in any particular order nor are they required
to be in any way related to the sender or recipient of the message to be in any way related to the sender or recipient of the message
(although in most cases they will be related to the sender). Incoming (although in most cases they will be related to the sender). Incoming
certificates and CRLs SHOULD be cached for use in path validation and certificates and CRLs SHOULD be cached for use in path validation and
optionally stored for later use. This temporary certificate and CRL optionally stored for later use. This temporary certificate and CRL
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 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] - 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 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].
A receiving agent MUST be capable of verifying the signatures on The following RSA and DSA key size requirements for S/MIME receiving
certificates and CRLs with key sizes from 512 bits to 2048 bits. agents during certificate and CRL signature verification:
0 < key size < 512 : MAY (see Section 6)
512 <= key size <= 2048 : MUST (see Section 6)
2048 < key size <= 4096 : MAY (see Section 6)
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 13, line 41 skipping to change at page 14, line 4
Some of the many places where signature and certificate checking Some of the many places where signature and certificate checking
might fail include: might fail include:
- no Internet mail addresses in a certificate matches the sender of - no Internet mail addresses in a certificate matches the sender of
a message, if the certificate contains at least one mail address a message, if the certificate contains at least one mail address
- no certificate chain leads to a trusted CA - no certificate chain leads to a trusted CA
- no ability to check the CRL for a certificate - no ability to check the CRL for a certificate
- an invalid CRL was received - an invalid CRL was received
- the CRL being checked is expired - the CRL being checked is expired
- the certificate is expired - the certificate is expired
- the certificate has been revoked - the certificate has been revoked
There are certainly other instances where a certificate may be There are certainly other instances where a certificate may be
invalid, and it is the responsibility of the processing software to invalid, and it is the responsibility of the processing software to
check them all thoroughly, and to decide what to do if the check check them all thoroughly, and to decide what to do if the check
fails. fails.
At the Selected Areas in Cryptography '95 conference in May 1995,
Rogier and Chauvaud presented an attack on MD2 that can nearly find
collisions [RC95]. Collisions occur when one can find two different
messages that generate the same message digest. A checksum operation
in MD2 is the only remaining obstacle to the success of the attack.
For this reason, the use of MD2 for new applications is discouraged.
It is still reasonable to use MD2 to verify existing signatures, as
the ability to find collisions in MD2 does not enable an attacker to
find new messages having a previously computed hash value.
It is possible for there to be multiple unexpired CRLs for a CA. If It is possible for there to be multiple unexpired CRLs for a CA. If
an agent is consulting CRLs for certificate validation, it SHOULD an agent is consulting CRLs for certificate validation, it SHOULD
make sure that the most recently issued CRL for that CA is consulted, make sure that the most recently issued CRL for that CA is consulted,
since an S/MIME message sender could deliberately include an older since an S/MIME message sender could deliberately include an older
unexpired CRL in an S/MIME message. This older CRL might not include unexpired CRL in an S/MIME message. This older CRL might not include
recent revoked certificates, which might lead an agent to accept a recent revoked certificates, which might lead an agent to accept a
certificate that has been revoked in a subsequent CRL. certificate that has been revoked in a subsequent CRL.
When determining the time for a certificate validity check, agents When determining the time for a certificate validity check, agents
have to be careful to use a reliable time. Unless it is from a have to be careful to use a reliable time. Unless it is from a
skipping to change at page 15, line 28 skipping to change at page 15, line 28
[CMSALG] Housley, R., "Cryptographic Message Syntax (CMS) [CMSALG] Housley, R., "Cryptographic Message Syntax (CMS)
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", work in progress. List (CRL) Profile", RFC 5280, May 2008.
[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 [IMF] Resnick, P., "Internet Message Format", work-in-
2001. 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: 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.
 End of changes. 23 change blocks. 
62 lines changed or deleted 59 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/