draft-ietf-smime-3850bis-10.txt   draft-ietf-smime-3850bis-11.txt 
S/MIME WG B. Ramsdell S/MIME WG B. Ramsdell
Internet Draft Brute Squad Labs Internet Draft Brute Squad Labs
Intended Status: Standard Track S. Turner Intended Status: Standard Track S. Turner
Obsoletes: 3850 (once approved) IECA Obsoletes: 3850 (once approved) IECA
Expires: October 27, 2009 April 27, 2009 Expires: November 12, 2009 May 12, 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-10.txt draft-ietf-smime-3850bis-11.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 October 27, 2009. This Internet-Draft will expire on November 12, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 12, line 22 skipping to change at page 12, line 22
- SHOULD+ support DSA with SHA-256 - SHOULD+ support DSA with SHA-256
- SHOULD+ support RSASSA-PSS with SHA-256 - SHOULD+ support RSASSA-PSS with SHA-256
- 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 and RSASSA-PSS key size requirements for
agents during certificate and CRL signature verification: S/MIME receiving agents during certificate and CRL signature
verification:
key size <= 1023 : MAY (see Section 6) key size <= 1023 : MAY (see Section 6)
1024 <= 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:
key size <= 1023 : MAY (see Section 6) key size <= 1023 : MAY (see Section 6)
1024 = key size : SHOULD (see Section 6) 1024 <= key size <= 3072 : MUST (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]. In and for 4096-bit RSA with SHA-256 see [RSAOAEP] and [PKCS1]. In
either case, the first reference provides the signature algorithm's either case, the first reference provides the signature algorithm's
object identifier and the second provides the signature algorithm's object identifier and the second provides the signature algorithm's
definition. 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 through
SHA-256 see [KEYMALG2] and [FIPS186-3]. In either case, the first 3072 DSA with SHA-256 see [KEYMALG2] and [FIPS186-3]. In either case,
reference provides the signature algorithm's object identifier and the first reference provides the signature algorithm's object
the second provides the signature algorithm's definition. identifier and the second provides the signature algorithm's
definition.
For 512-4096-bit RSASSA-PSS with SHA-256 see [RSAPSS]. For RSASSA-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.
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 17, line 16 skipping to change at page 17, line 16
could be included in fake certificates to allow the originator to could be included in fake certificates to allow the originator to
detect receipt of the message even if signature verification fails. detect receipt of the message even if signature verification fails.
The 4096-bit RSA key size requirement for certificate and CRL The 4096-bit RSA key size requirement for certificate and CRL
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, [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, and [FIPS186-3] allowed DSA key
sizes is being developed, and once it is available, implementors sizes from 1024 to 3072 bits. Further, 4096-bit keys are normally
ought to support DSA key sizes comparable to the RSA key sizes only used by Root certificates and not by subordinate CA
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 certificates; thereby, lengthening the Root CA certificate's validity
period. period.
RSA and DSA keys of less than 1024 bits are now considered by many RSA and DSA keys of less than 1024 bits are now considered by many
experts to be cryptographically insecure (due to advances in experts to be cryptographically insecure (due to advances in
computing power), and should no longer be used to sign certificates computing power), and should no longer be used to sign certificates
or CRLs. Such keys were previously considered secure, so processing or CRLs. Such keys were previously considered secure, so processing
previously received signed and encrypted mail may require processing previously received signed and encrypted mail may require processing
certificates or CRLs signed with weak keys. Implementations that certificates or CRLs signed with weak keys. Implementations that
wish to support previous versions of S/MIME or process old messages wish to support previous versions of S/MIME or process old messages
skipping to change at page 18, line 11 skipping to change at page 18, line 11
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., Housley, R., and S. Turner, "An Internet [ACAUTH] Farrell, S., Housley, R., and S. Turner, "An Internet
Attribute Certificate Profile for Authorization", Attribute Certificate Profile for Authorization",
draft-ietf-pkix-3281update-04.txt, work-in-progress. draft-ietf-pkix-3281update-05.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.
 End of changes. 9 change blocks. 
18 lines changed or deleted 18 lines changed or added

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