< draft-ietf-smime-3850bis-08.txt   draft-ietf-smime-3850bis-09.txt >
S/MIME WG Blake Ramsdell, Brute Squad Labs S/MIME WG Blake Ramsdell, Brute Squad Labs
Internet Draft Sean Turner, IECA Internet Draft Sean Turner, IECA
Intended Status: Standard Track October 2, 2008 Intended Status: Standard Track April 6, 2009
Obsoletes: 3850 (once approved) Obsoletes: 3850 (once approved)
Expires: April 2, 2009 Expires: October 6, 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-08.txt draft-ietf-smime-3850bis-09.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
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."
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 2, 2008. This Internet-Draft will expire on October 6, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
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) v3.2 agents.
provides a method to send and receive secure MIME messages, and S/MIME provides a method to send and receive secure MIME messages,
certificates are an integral part of S/MIME agent processing. S/MIME and certificates are an integral part of S/MIME agent processing.
agents validate certificates as described in RFC 5280, the Internet S/MIME agents validate certificates as described in RFC 5280, the
X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME Internet X.509 Public Key Infrastructure Certificate and CRL Profile.
agents must meet the certificate processing requirements in this S/MIME agents must meet the certificate processing requirements in
document as well as those in RFC 5280. This document obsoletes RFC this document as well as those in RFC 5280. This document obsoletes
3850. RFC 3850.
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. 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 From S/MIME v3 to S/MIME v3.1.....................4 1.4. Changes From S/MIME v3 to S/MIME v3.1.....................5
1.5. Changes Since S/MIME v3.1.................................5 1.5. Changes Since S/MIME v3.1.................................5
2. CMS Options....................................................6 2. CMS Options....................................................6
2.1. Certificate Revocation Lists..............................6 2.1. Certificate Revocation Lists..............................6
2.2. Certificate Choices.......................................6 2.2. Certificate Choices.......................................7
2.2.1. Historical Note About CMS Certificates...............6 2.2.1. Historical Note About CMS Certificates...............7
2.3. CertificateSet............................................7 2.3. CertificateSet............................................7
3. Using Distinguished Names For Internet Mail....................8 3. Using Distinguished Names For Internet Mail....................8
4. Certificate Processing.........................................9 4. Certificate Processing.........................................9
4.1. Certificate Revocation Lists.............................10 4.1. Certificate Revocation Lists.............................10
4.2. Certificate Path Validation..............................10 4.2. Certificate Path Validation..............................11
4.3. Certificate and CRL Signing Algorithms and Key Sizes.....11 4.3. Certificate and CRL Signing Algorithms and Key Sizes.....12
4.4. PKIX Certificate Extensions..............................12 4.4. PKIX Certificate Extensions..............................13
5. IANA Considerations...........................................14 5. IANA Considerations...........................................15
6. Security Considerations.......................................14 6. Security Considerations.......................................16
7. References....................................................16 7. References....................................................18
7.1. Normative References.....................................16 7.1. Normative References.....................................18
7.2. Informative References...................................18 7.2. Informative References...................................19
Appendix A. Moving S/MIME v2 Certificate Handling to Historic Appendix A. Moving S/MIME v2 Certificate Handling to Historic
Status...............................................20 Status...............................................22
Appendix B. Acknowledgements.....................................20 Appendix B. Acknowledgements.....................................22
1. Introduction 1. Introduction
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in S/MIME (Secure/Multipurpose Internet Mail Extensions) v3.2, described
[SMIME-MSG], provides a method to send and receive secure MIME in [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
certificate processing requirements documented in this document in certificate processing requirements documented in this document in
addition to those stated in [KEYM]. addition to those stated in [KEYM].
This specification is compatible with the Cryptographic Message This specification is compatible with the Cryptographic Message
Syntax (CMS) RFC 3852 and RFC 4853 [CMS] in that it uses the data Syntax (CMS) RFC 3852 and RFC 4853 [CMS] in that it uses the data
skipping to change at page 4, line 33 skipping to change at page 4, line 49
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 future expect that this requirement will no longer be a MUST in a future
document. Although its status will be determined at a later document. Although its status will be determined at a later
time, it is reasonable to expect that if a future revision of a time, it is reasonable to expect that if a future revision of a
document alters the status of a MUST- requirement, it will remain document alters the status of a MUST- requirement, it will remain
at least a SHOULD or a SHOULD-. at least a SHOULD or a SHOULD-.
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 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, RFC4853, and RFC 5035 in RFC 3850, RFC 3851, RFC 3852, RFC 2634, RFC4853, and RFC 5035
[SMIMEv3.1]. RFC 2311 also has historical information about the [SMIMEv3.1]. RFC 2311 also has historical information about the
development of S/MIME. development of S/MIME.
1.4. Changes From S/MIME v3 To 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. Version 1 and Version 2 CRLs MUST be supported.
skipping to change at page 5, line 30 skipping to change at page 5, line 47
1.5. Changes Since S/MIME v3.1 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.1: Updated ASN.1 definition and reference. Sec 1.1: 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: Aligned email address text with RFC 5280. Updated note to
255 characters. indicate emailAddress IA5String upper bound is 255 characters. Added
text about matching email addresses.
Sec 4.2: Added text to indicate how S/MIME agents locate the correct Sec 4.2: Added text to indicate how S/MIME agents locate the correct
user certificate. user certificate.
Sec 4.3: RSA with SHA-256 (PKCS #1 v1.5) added as MUST, DSA with SHA- Sec 4.3: RSA with SHA-256 (PKCS #1 v1.5) added as MUST, DSA with SHA-
256 added as SHOULD+, RSA with SHA-1, DSA with SHA-1, and RSA with 256 added as SHOULD+, RSA with SHA-1, DSA with SHA-1, and RSA with
MD5 changed to SHOULD-, and RSA-PSS with SHA-256 added as SHOULD+. MD5 changed to SHOULD-, and RSA-PSS with SHA-256 added as SHOULD+.
Updated key sizes and changed pointer to PKIX RFCs. Updated key sizes and changed pointer to PKIX RFCs.
Sec 4.4.1: Aligned with PKIX on use of basic constraints extension in Sec 4.4.1: Aligned with PKIX on use of basic constraints extension in
skipping to change at page 8, line 14 skipping to change at page 8, line 37
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 [IMF]. The address must be an "addr-spec" as defined in described in [KEYM] Section 4.2.1.6. The email address SHOULD be in
Section 3.4.1 of that specification. The email address SHOULD be in
the subjectAltName extension, and SHOULD NOT be in the subject the subjectAltName extension, and SHOULD NOT be in the 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 bound of 255 characters. upper bound of 255 characters. The right side of the email address
SHOULD be treated as ASCII-case-insensitive.
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 40 skipping to change at page 11, line 15
CRLs in received S/MIME messages. 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 [KEYM] when validating a validation MUST be performed as per [KEYM] 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 (ex: RSA); or forming a pairwise encrypting a content-encryption key (e.g., RSA); or forming a
symmetric key (ex: Diffie-Hellman) to be used to encrypt or decrypt a pairwise symmetric key (e.g., Diffie-Hellman) to be used to encrypt
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
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.
When verifying a signature and the certificates are included in the When verifying a signature and the certificates that are included in
message, if a signingCertificate attribute from RFC 2634 [ESS] or a the message, if a signingCertificate attribute from RFC 2634 [ESS] or
signingCertificateV2 attribute from RFC 5035 [ESS] is found in an a signingCertificateV2 attribute from RFC 5035 [ESS] is found in an
S/MIME message, it SHALL be used to identify the signer's S/MIME message, it SHALL be used to identify the signer's
certificate. Otherwise, the certificate is identified in an S/MIME certificate. Otherwise, the certificate is identified in an S/MIME
message, either using the issuerAndSerialNumber which identifies the message, either using the issuerAndSerialNumber which identifies the
signer's certificate by the issuer's distinguished name and the signer's certificate by the issuer's distinguished name and the
certificate serial number, or the subjectKeyIdentifier which certificate serial number, or the subjectKeyIdentifier which
identifies the signer's certificate by a key identifier. identifies the signer's certificate by a key identifier.
When decrypting an encrypted message, if a When decrypting an encrypted message, if a
SMIMEEncryptionKeyPreference attribute is found in an encapsulating SMIMEEncryptionKeyPreference attribute is found in an encapsulating
SignedData, it SHALL be used to identify the originator's certificate SignedData, it SHALL be used to identify the originator's certificate
skipping to change at page 11, line 43 skipping to change at page 12, line 25
- SHOULD- support RSA with SHA-1 - SHOULD- support RSA with SHA-1
- SHOULD- support DSA with SHA-1 - SHOULD- support DSA with SHA-1
- SHOULD- support RSA with MD5 - SHOULD- support RSA with MD5
The following are the RSA key size requirements for S/MIME receiving The following are the RSA key size requirements for S/MIME receiving
agents during certificate and CRL signature verification: agents during certificate and CRL signature verification:
0 < key size < 512 : MAY (see Section 6) key size <= 1023 : MAY (see Section 6)
512 <= key size <= 4096 : MUST (see Section 6) 1024 <= key size <= 4096 : MUST (see Section 6)
4096 < key size : MAY (see Section 6) 4096 < key size : MAY (see Section 6)
The following are the DSA key size requirements for S/MIME receiving The following are the DSA key size requirements for S/MIME receiving
agents during certificate and CRL signature verification: agents during certificate and CRL signature verification:
512 <= key size <= 1023 : MAY (see Section 6) key size <= 1023 : MAY (see Section 6)
1024 = key size : SHOULD- (see Section 6) 1024 = key size : SHOULD- (see Section 6)
For 512-bit RSA with SHA-1 see [KEYMALG] and [FIPS186-2] without For 512-bit RSA with SHA-1 see [KEYMALG] and [FIPS186-2] without
Change Notice 1, for 512-bit RSA with SHA-256 see [RSAOAEP] and Change Notice 1, for 512-bit RSA with SHA-256 see [RSAOAEP] and
[FIPS186-2] without Change Notice 1, for 1024-bit through 3072-bit [FIPS186-2] without Change Notice 1, for 1024-bit through 3072-bit
RSA with SHA-256 see [RSAOAEP] and [FIPS186-2] with Change Notice 1, RSA with SHA-256 see [RSAOAEP] and [FIPS186-2] with Change Notice 1,
and for 4096-bit RSA with SHA-256 see [RSAOAEP] and [PKCS1]. The and for 4096-bit RSA with SHA-256 see [RSAOAEP] and [PKCS1]. In
first reference provides the signature algorithm's object identifier either case, the first reference provides the signature algorithm's
and the second provides the signature algorithm's definition. object identifier and the second provides the signature algorithm's
definition.
For 512-bit DSA with SHA-1 see [KEYMALG] and [FIPS186-2] without For 512-bit DSA with SHA-1 see [KEYMALG] and [FIPS186-2] without
Change Notice 1, for 512-bit DSA with SHA-256 see [KEYMALG2] and Change Notice 1, for 512-bit DSA with SHA-256 see [KEYMALG2] and
[FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see [FIPS186-2] without Change Notice 1, for 1024-bit DSA with SHA-1 see
[KEYMALG] and [FIPS186-2] with Change Notice 1, for 1024-bit DSA with [KEYMALG] and [FIPS186-2] with Change Notice 1, for 1024-bit DSA with
SHA-256 see [KEYMALG2] and [FIPS186-3]. The first reference provides SHA-256 see [KEYMALG2] and [FIPS186-3]. In either case, the first
the signature algorithm's object identifier and the second provides reference provides the signature algorithm's object identifier and
the signature algorithm's definition. the second provides the signature algorithm's definition.
For 512-4096-bit RSA-PSS with SHA-256 see [RSAPSS]. For 512-4096-bit RSA-PSS with SHA-256 see [RSAPSS].
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.
skipping to change at page 13, line 21 skipping to change at page 14, line 22
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 the key usage certificates. End-entity certificates contain the key usage
extension which restrains EEs from using the key to performing extension which restrains EEs from using the key when performing
issuing authority operations (see Section 4.4.2). issuing authority operations (see Section 4.4.2).
As per [KEYM], Certificates MUST contain a basicConstraints extension As per [KEYM], Certificates MUST contain a basicConstraints extension
in CA certificates, and SHOULD NOT contain that extension in end in CA certificates, and SHOULD NOT contain that extension in end
entity certificates. entity 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
skipping to change at page 14, line 13 skipping to change at page 15, line 13
S/MIME-enabled application can specify additional requirements S/MIME-enabled application can specify additional requirements
concerning the digitalSignature or nonRepudiation bits within this concerning the digitalSignature or nonRepudiation bits within this
extension. extension.
If the key usage extension is not specified, receiving clients MUST If the key usage extension is not specified, receiving clients MUST
presume that the digitalSignature and nonRepudiation bits are set. presume that the digitalSignature and nonRepudiation bits are set.
4.4.3. Subject Alternative Name 4.4.3. Subject Alternative Name
The subject alternative name extension is used in S/MIME as the The subject alternative name extension is used in S/MIME as the
preferred means to convey the RFC-2822 email address(es) that preferred means to convey the email address(es) that correspond(s) to
correspond(s) to the entity for this certificate. Any RFC-2822 email the entity for this certificate. Any email addresses present MUST be
addresses present MUST be encoded using the rfc822Name CHOICE of the encoded using the rfc822Name CHOICE of the GeneralName type as
GeneralName type. Since the SubjectAltName type is a SEQUENCE OF described in [KEYM] Section 4.2.1.6. Since the SubjectAltName type
GeneralName, multiple RFC-2822 email addresses MAY be present. is a SEQUENCE OF GeneralName, multiple email addresses MAY be
present.
4.4.4. Extended Key Usage Extension 4.4.4. Extended Key Usage Extension
The extended key usage extension also serves to limit the technical The extended key usage extension also serves to limit the technical
purposes for which a public key listed in a valid certificate may be purposes for which a public key listed in a valid certificate may be
used. The set of technical purposes for the certificate therefore used. The set of technical purposes for the certificate therefore
are the intersection of the uses indicated in the key usage and are the intersection of the uses indicated in the key usage and
extended key usage extensions. extended key usage extensions.
For example, if the certificate contains a key usage extension For example, if the certificate contains a key usage extension
skipping to change at page 16, line 37 skipping to change at page 17, line 40
verification is larger than the 2048-bit RSA key sizes for message verification is larger than the 2048-bit RSA key sizes for message
signature generation/verification or message encryption/decryption in signature generation/verification or message encryption/decryption in
[SMIME-MSG] because many Root CAs included in certificate stores have [SMIME-MSG] because many Root CAs included in certificate stores have
already issued Root certificates with 4096-bit key. The standard already issued Root certificates with 4096-bit key. The standard
that defines comparable key sizes for DSA is not yet available. In that defines comparable key sizes for DSA is not yet available. In
particular, [FIPS186-2] without Change Notice 1 allowed DSA key sizes particular, [FIPS186-2] without Change Notice 1 allowed DSA key sizes
between 512 and 1024 bits and [FIPS186-2] with Change Notice 1 only between 512 and 1024 bits and [FIPS186-2] with Change Notice 1 only
allowed DSA key sizes of 1024 bits. A revision to support larger key allowed DSA key sizes of 1024 bits. A revision to support larger key
sizes is being developed, and once it is available, implementors sizes is being developed, and once it is available, implementors
ought to support DSA key sizes comparable to the RSA key sizes ought to support DSA key sizes comparable to the RSA key sizes
recommended in this specification. recommended in this specification. Further, 4096-bit keys are
normally only used by Root certificates and not by subordinate CA
certificates; thereby, lengthening the Root CA certificate's validity
period.
Today, 512-bit RSA and DSA keys are considered by many experts to be RSA and DSA keys of less than 1024 bits are now considered by many
cryptographically insecure. experts to be cryptographically insecure (due to advances in
computing power), and should no longer be used to sign certificates
or CRLs. Such keys were previously considered secure, so processing
previously received signed and encrypted mail may require processing
certificates or CRLs signed with weak keys. Implementations that
wish to support previous versions of S/MIME or process old messages
need to consider the security risks that result from accepting
certificates and CRLs with smaller key sizes (e.g., spoofed
certificates) versus the costs of denial of service. If an
implementation supports verification of certificates or CRLs
generated with RSA and DSA keys of less than 1024 bits, it MUST warn
the user. Implementers should consider providing a stronger warning
for weak signatures on certificates and CRLs associated with newly
received messages than the one provided for certificates and CRLs
associated with previously stored messages. Server implementations
(e.g., secure mail list servers) where user warnings are not
appropriate SHOULD reject messages with weak cryptography.
If an implementation is concerned about compliance with NIST key size If an implementation is concerned about compliance with NIST key size
recommendations, then see [SP800-57]. recommendations, then see [SP800-57].
7. References 7. References
7.1. Normative References 7.1. Normative References
[ACAUTH] Farrell, S. and R. Housley, "An Internet Attribute [ACAUTH] Farrell, S., Housley, R., and S. Turner, "An Internet
Certificate Profile for Authorization", RFC 3281, April Attribute Certificate Profile for Authorization",
2002. draft-ietf-pkix-3281update-04.txt, work-in-progress.
[CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC [CMS] Housley, R., "Cryptographic Message Syntax (CMS)", RFC
3852, July 2004. 3852, July 2004.
Housley, R., "Cryptographic Message Syntax (CMS) Housley, R., "Cryptographic Message Syntax (CMS)
Multiple Signer Clarification", RFC 4853, April 2007. Multiple Signer Clarification", RFC 4853, April 2007.
[ESS] Hoffman, P., "Enhanced Security Services for S/MIME", [ESS] Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
skipping to change at page 17, line 38 skipping to change at page 19, line 15
List (CRL) Profile", RFC 5280, May 2008. List (CRL) Profile", RFC 5280, May 2008.
[KEYMALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and [KEYMALG] Bassham, L., Polk, W., and R. Housley, "Algorithms and
Identifiers for the Internet X.509 Public Key Identifiers for the Internet X.509 Public Key
Infrastructure Certificate and Certificate Revocation Infrastructure Certificate and Certificate Revocation
List (CRL) Profile", RFC 3279, April 2002. List (CRL) Profile", RFC 3279, April 2002.
[KEYMALG2] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and [KEYMALG2] Dang, Q., Santesson, S., Moriarty, K., Brown, D., and
T. Polk, "Internet X.509 Public Key Infrastructure: T. Polk, "Internet X.509 Public Key Infrastructure:
Additional Algorithms and Identifiers for DSA and Additional Algorithms and Identifiers for DSA and
ECDSA", draft-ietf-pkix-sha2-dsa-ecdsa, work-in- ECDSA", draft-ietf-pkix-sha2-dsa-ecdsa-06.txt, work-in-
progress. progress.
[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.
[PKCS1] Jonsson, J. and B. Kaliki, "Public-Key Cryptography [PKCS1] Jonsson, J. and B. Kaliki, "Public-Key Cryptography
Standards (PKCS) #1: RSA Cryptography Specifications Standards (PKCS) #1: RSA Cryptography Specifications
Version 2.1", RFC 3447, February 2003. Version 2.1", RFC 3447, February 2003.
[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", RFC 5322,
October 2008.
[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.
[RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "Additional [RSAOAEP] Schaad, J., Kaliski, B., and R. Housley, "Additional
Algorithms and Identifiers for RSA Cryptography for use Algorithms and Identifiers for RSA Cryptography for use
in the Internet X.509 Public Key Infrastructure in the Internet X.509 Public Key Infrastructure
Certificate and Certificate Revocation List (CRL) Certificate and Certificate Revocation List (CRL)
Profile", RFC 4055, June 2005. Profile", RFC 4055, 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", draft-ietf-smime-3851bis- Message Specification", draft-ietf-smime-3851bis-
07.txt, work-in-progress. 09.txt, work-in-progress.
[X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824- [X.680] ITU-T Recommendation X.680 (2002) | ISO/IEC 8824-
1:2002. Information Technology - Abstract Syntax 1:2002. Information Technology - Abstract Syntax
Notation One (ASN.1): Specification of basic notation. 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.
skipping to change at page 19, line 41 skipping to change at page 21, line 23
Ramsdell, B., "S/MIME Version 3.1 Message Ramsdell, B., "S/MIME Version 3.1 Message
Specification", RFC 3851, July 2004. Specification", RFC 3851, July 2004.
Hoffman, P., "Enhanced Security Services for S/MIME", Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999. RFC 2634, June 1999.
Schaad, J., "ESS Update: Adding CertID Algorithm Schaad, J., "ESS Update: Adding CertID Algorithm
Agility", RFC 5035, August 2007. Agility", RFC 5035, August 2007.
[SP800-57] National Institute of Standards and Technology (NIST), [SP800-57] National Institute of Standards and Technology (NIST),
Special Publication 800-57: Recommendation for Key Special Publication 800-57: Recommendation for Key
Management, August 2005. Management, August 2005.
[X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594- [X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-
1:1997, Information technology - Open Systems 1:1997, Information technology - Open Systems
Interconnection - The Directory: Overview of concepts, Interconnection - The Directory: Overview of concepts,
models and services. models and services.
Appendix A. Moving S/MIME v2 Certificate Handling to Historic Status Appendix A. Moving S/MIME v2 Certificate Handling to Historic Status
The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document) The S/MIME v3 [SMIMEv3], v3.1 [SMIMEv3.1], and v3.2 (this document)
are backwards compatible with the S/MIME v2 Certificate Handling are backwards compatible with the S/MIME v2 Certificate Handling
Specification [SMIMEv2], with the exception of the algorithms Specification [SMIMEv2], with the exception of the algorithms
(dropped RC2/40 requirement and added DSA and RSA-PSS requirements). (dropped RC2/40 requirement and added DSA and RSA-PSS requirements).
Therefore, it is recommended that RFC 2312 [SMIMEv2] be moved to Therefore, it is recommended that RFC 2312 [SMIMEv2] be moved to
Historic status. Historic status.
Appendix B. Acknowledgements Appendix B. 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 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, Alfred Hoenes, Paul Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Alfred Hoenes, Paul
Hoffman, Russ Housley, David P. Kemp, Michael Myers, John Pawling, Hoffman, Russ Housley, David P. Kemp, Michael Myers, John Pawling,
Denis Pinkas, and Jim Schaad. Denis Pinkas, and Jim Schaad.
Author's Addresses Authors' Addresses
Blake Ramsdell Blake Ramsdell
Brute Squad Labs, Inc. Brute Squad Labs, Inc.
Email: blaker@gmail.com Email: blaker@gmail.com
Sean Turner Sean Turner
IECA, Inc. IECA, Inc.
3057 Nutley Street, Suite 106 3057 Nutley Street, Suite 106
Fairfax, VA 22031 Fairfax, VA 22031
USA USA
Email: turners@ieca.com Email: turners@ieca.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
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
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 38 change blocks. 
78 lines changed or deleted 113 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/