< draft-ietf-smime-3850bis-03.txt   draft-ietf-smime-3850bis-04.txt >
S/MIME WG Blake Ramsdell, SendMail S/MIME WG Blake Ramsdell, SendMail
Internet Draft Sean Turner, IECA Internet Draft Sean Turner, IECA
Intended Status: Standard Track June 3, 2008 Intended Status: Standard Track June 30, 2008
Obsoletes: 3850 (once approved) Obsoletes: 3850 (once approved)
Expires: December 3, 2008 Expires: December 30, 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-03.txt draft-ietf-smime-3850bis-04.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html http://www.ietf.org/shadow.html
This Internet-Draft will expire on December 3, 2008. This Internet-Draft will expire on December 30, 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 5280, the Internet
Internet X.509 Public Key Infrastructure Certificate and CRL Profile. X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME
S/MIME agents must meet the certificate processing requirements in agents must meet the certificate processing requirements in this
this document as well as those in RFC 3280bis. This document document as well as those in RFC 5280. This document obsoletes RFC
obsoletes RFC 3850. 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...................................................2
1.1. Definitions...............................................3 1.1. Definitions...............................................3
1.2. Conventions used in this document.........................4 1.2. Conventions used in this document.........................4
1.3. Compatibility with Prior Practice S/MIME..................4 1.3. Compatibility with Prior Practice S/MIME..................4
1.4. Changes Since S/MIME V3.1 (RFC 3850)......................4 1.4. Changes Since S/MIME v3.1.................................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...............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 and Key Sizes.....10 4.3. Certificate and CRL Signing Algorithms and Key Sizes.....10
4.4. PKIX Certificate Extensions..............................11 4.4. PKIX Certificate Extensions..............................11
4.4.1. Basic Constraints...................................11
4.4.2. Key Usage Certificate Extension.....................12
4.4.3. Subject Alternative Name............................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 7. References....................................................14
A.1. Normative References.....................................15 7.1. Normative References.....................................14
A.2. Informative References...................................16 7.2. Informative References...................................15
Appendix B. Acknowledgements.....................................17 Appendix A. Moving S/MIME v2 Certificate Handling to Historic
Status...............................................18
Appendix B. Acknowledgements.....................................19
1. Introduction 1. Introduction
S/MIME (Secure/Multipurpose Internet Mail Extensions), described in S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
[SMIME-MSG], provides a method to send and receive secure MIME [SMIME-MSG], provides a method to send and receive secure MIME
messages. Before using a public key to provide security services, messages. Before using a public key to provide security services,
the S/MIME agent MUST verify that the public key is valid. S/MIME the S/MIME agent MUST verify that the public key is valid. S/MIME
agents MUST use PKIX certificates to validate public keys as agents MUST use PKIX certificates to validate public keys as
described in the Internet X.509 Public Key Infrastructure (PKIX) described in the Internet X.509 Public Key Infrastructure (PKIX)
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 35 skipping to change at page 4, line 32
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 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, [SMIMEv2], S/MIME version 3 is described in RFC 2630 through RFC 2634
and S/MIME version 3.1 is described in RFC 3850 through 3851 inclusive [SMIMEv3], and S/MIME version 3.1 is described in RFC 3850
inclusive and RFC 2634. RFC 2311 also has historical information through RFC 3852 and RFC 2634 [SMIMEv3.1]. RFC 2311 also has
about the development of S/MIME. historical information about the development of S/MIME.
1.4. Changes Since S/MIME V3.1 (RFC 3850) 1.4. Changes Since S/MIME v3.1
Conventions Used in This Document: Moved to section 1.2. Added Conventions Used in This Document: Moved to section 1.2. Added
definitions for SHOULD+, SHOULD-, and MUST-. definitions for SHOULD+, SHOULD-, and MUST-.
Sec 1.2: Added text about v3.1 RFCs. Sec 1.3: Added text about v3.1 RFCs.
Sec 3: Updated note to indicate emailAddress IA5String upper bound is Sec 3: Updated note to indicate emailAddress IA5String upper bound is
255 characters. 255 characters.
Sec 4.3: RSA with SHA-256 (PKCS #1 v1.5) added as MUST, RSA with SHA- Sec 4.3: RSA with SHA-256 (PKCS #1 v1.5) added as MUST, 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-PSS with SHA-256. Updated key sizes.
Sec A.1: Updated references to latest versions of PKIX profile and Sec 7: Moved references from Appendix B to this section. Updated
S/MIME Message Specification. references to latest versions of PKIX profile and S/MIME Message
Specification. Changed reference from KEYMALG to KEYM.
Sec A.1: Changed reference from KEYMALG to KEYM. App A: Added Appendix B to move S/MIME v2 Certificate Handling to
Historic Status.
2. CMS Options 2. CMS Options
The CMS message format allows for a wide variety of options in The CMS message format allows for a wide variety of options in
content and algorithm support. This section puts forth a number of content and algorithm support. This section puts forth a number of
support requirements and recommendations in order to achieve a base support requirements and recommendations in order to achieve a base
level of interoperability among all S/MIME implementations. Most of level of interoperability among all S/MIME implementations. Most of
the CMS format for S/MIME messages is defined in [SMIME-MSG]. the CMS format for S/MIME messages is defined in [SMIME-MSG].
2.1. Certificate Revocation Lists 2.1. Certificate Revocation Lists
skipping to change at page 8, line 26 skipping to change at page 8, line 26
A receiving agent needs to provide some certificate retrieval A receiving agent needs to provide some certificate retrieval
mechanism in order to gain access to certificates for recipients of mechanism in order to gain access to certificates for recipients of
digital envelopes. There are many ways to implement certificate digital envelopes. There are many ways to implement certificate
retrieval mechanisms. X.500 directory service is an excellent retrieval mechanisms. X.500 directory service is an excellent
example of a certificate retrieval-only mechanism that is compatible example of a certificate retrieval-only mechanism that is compatible
with classic X.500 Distinguished Names. Another method under with classic X.500 Distinguished Names. Another method under
consideration by the IETF is to provide certificate retrieval consideration by the IETF is to provide certificate retrieval
services as part of the existing Domain Name System (DNS). Until services as part of the existing Domain Name System (DNS). Until
such mechanisms are widely used, their utility may be limited by the such mechanisms are widely used, their utility may be limited by the
small number of correspondent's certificates that can be retrieved. small number of the correspondent's certificates that can be
At a minimum, for initial S/MIME deployment, a user agent could retrieved. At a minimum, for initial S/MIME deployment, a user agent
automatically generate a message to an intended recipient requesting could automatically generate a message to an intended recipient
that recipient's certificate in a signed return message. requesting the recipient's certificate in a signed return message.
Receiving and sending agents SHOULD also provide a mechanism to allow Receiving and sending agents SHOULD also provide a mechanism to allow
a user to "store and protect" certificates for correspondents in such a user to "store and protect" certificates for correspondents in such
a way so as to guarantee their later retrieval. In many a way so as to guarantee their later retrieval. In many
environments, it may be desirable to link the certificate environments, it may be desirable to link the certificate
retrieval/storage mechanisms together in some sort of certificate retrieval/storage mechanisms together in some sort of certificate
database. In its simplest form, a certificate database would be database. In its simplest form, a certificate database would be
local to a particular user and would function in a similar way as an local to a particular user and would function in a similar way as an
"address book" that stores a user's frequent correspondents. In this "address book" that stores a user's frequent correspondents. In this
way, the certificate retrieval mechanism would be limited to the way, the certificate retrieval mechanism would be limited to the
skipping to change at page 10, line 31 skipping to change at page 10, line 31
- 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].
The following RSA and DSA key size requirements for S/MIME receiving The following are the RSA and DSA key size requirements for S/MIME
agents during certificate and CRL signature verification: receiving agents during certificate and CRL signature verification:
0 < key size < 512 : MAY (see Section 6) 0 < key size < 512 : MAY (see Section 6)
512 <= key size <= 2048 : MUST (see Section 6) 512 <= key size <= 2048 : MUST (see Section 6)
2048 < key size <= 4096 : MAY (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 describes how such extensions can be
control the process of issuing and validating certificates. The PKIX used to control the process of issuing and validating certificates.
Working Group has ongoing efforts to identify and create extensions The PKIX Working Group has ongoing efforts to identify and create
which have value in particular certification environments. Further, extensions which have value in particular certification environments.
there are active efforts underway to issue PKIX certificates for Further, there are active efforts underway to issue PKIX certificates
business purposes. This document identifies the minimum required set for business purposes. This document identifies the minimum required
of certificate extensions which have the greatest value in the S/MIME set of certificate extensions which have the greatest value in the
environment. The syntax and semantics of all the identified S/MIME environment. The syntax and semantics of all the identified
extensions are defined in [KEYM]. extensions are defined in [KEYM].
Sending and receiving agents MUST correctly handle the basic Sending and receiving agents MUST correctly handle the basic
constraints, key usage, authority key identifier, subject key constraints, key usage, authority key identifier, subject key
identifier, and subject alternative names certificate extensions when identifier, and subject alternative names certificate extensions when
they appear in end-entity and CA certificates. Some mechanism SHOULD they appear in end-entity and CA certificates. Some mechanism SHOULD
exist to gracefully handle other certificate extensions when they exist to gracefully handle other certificate extensions when they
appear in end-entity or CA certificates. appear in end-entity or CA certificates.
Certificates issued for the S/MIME environment SHOULD NOT contain any Certificates issued for the S/MIME environment SHOULD NOT contain any
skipping to change at page 11, line 46 skipping to change at page 11, line 46
4.4.1. Basic Constraints 4.4.1. Basic Constraints
The basic constraints extension serves to delimit the role and The basic constraints extension serves to delimit the role and
position that an issuing authority or end-entity certificate plays in position that an issuing authority or end-entity certificate plays in
a certification path. a certification path.
For example, certificates issued to CAs and subordinate CAs contain a For example, certificates issued to CAs and subordinate CAs contain a
basic constraint extension that identifies them as issuing authority basic constraint extension that identifies them as issuing authority
certificates. End-entity certificates contain an extension that certificates. End-entity certificates contain an extension that
constrains the certificate from being an issuing authority constrains the certificate from being an issuing authority
certificate. certificate (see Section 4.4.2).
Certificates SHOULD contain a basicConstraints extension in CA Certificates SHOULD contain a basicConstraints extension in CA
certificates, and SHOULD NOT contain that extension in end entity certificates, and SHOULD NOT contain that extension in end entity
certificates. certificates.
4.4.2. Key Usage Certificate Extension 4.4.2. Key Usage Certificate Extension
The key usage extension serves to limit the technical purposes for The key usage extension serves to limit the technical purposes for
which a public key listed in a valid certificate may be used. Issuing which a public key listed in a valid certificate may be used. Issuing
authority certificates may contain a key usage extension that authority certificates may contain a key usage extension that
skipping to change at page 14, line 22 skipping to change at page 14, line 22
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.
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 recently 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
trusted agent, this time MUST NOT be the SigningTime attribute found trusted agent, this time MUST NOT be the SigningTime attribute found
in an S/MIME message. For most sending agents, the SigningTime in an S/MIME message. For most sending agents, the SigningTime
attribute could be deliberately set to direct the receiving agent to attribute could be deliberately set to direct the receiving agent to
check a CRL that could have out-of-date revocation status for a check a CRL that could have out-of-date revocation status for a
certificate, or cause an improper result when checking the Validity certificate, or cause an improper result when checking the Validity
field of a certificate. field of a certificate.
Appendix A. References 7. References
A.1. Normative References 7.1. Normative References
[ACAUTH] Farrell, S. and R. Housley, "An Internet Attribute [ACAUTH] Farrell, S. and R. Housley, "An Internet Attribute
Certificate Profile for Authorization", RFC 3281, April Certificate Profile for Authorization", RFC 3281, April
2002. 2002.
[CMS] Housely, 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 4852, April 2007. Multiple Signer Clarification", RFC 4852, April 2007.
[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.
skipping to change at page 15, line 40 skipping to change at page 15, line 23
[MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate [MUSTSHOULD] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[PKCS9] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object [PKCS9] Nystrom, M. and B. Kaliski, "PKCS #9: Selected Object
Classes and Attribute Types Version 2.0", RFC 2985, Classes and Attribute Types Version 2.0", RFC 2985,
November 2000. November 2000.
[IMF] Resnick, P., "Internet Message Format", work-in- [IMF] Resnick, P., "Internet Message Format", work-in-
progress. progress.
[RSAPSS] Schaad, J., "Use of RSASA-PSS Signature Algorithm in [RSAPSS] Schaad, J., "Use of RSASA-PSS Signature Algorithm in
Cryptographic Message Syntax (CMS)", RFC 4056, June Cryptographic Message Syntax (CMS)", RFC 4056, June
2005. 2005.
[SMIME-MSG] Ramsdell, B., and S. Turner, "S/MIME Version 3.2 [SMIME-MSG] Ramsdell, B., and S. Turner, "S/MIME Version 3.2
Message Specification", work in progress. Message Specification", work in progress.
[X.208-88] ITU-T. Recommendation X.208: Specification of Abstract [X.208-88] ITU-T Recommendation X.208 (1988) | ISO/IEC ISO/IEC
Syntax Notation One (ASN.1). 1988. 8824-1:1988. Specification of Abstract Syntax Notation
One (ASN.1).
A.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.
[RC95] Rogier, N. and Chauvaud, P., "The compression function
of MD2 is not collision free," Presented at Selected
Areas in Cryptography '95, May 1995.
[SECLABEL] Nicolls, W., "Implementing Company Classification [SECLABEL] Nicolls, W., "Implementing Company Classification
Policy with the S/MIME Security Label", RFC 3114, May Policy with the S/MIME Security Label", RFC 3114, May
2002. 2002.
[SMIMEv2] Dusse, S., Hoffman, P., Ramsdell, B., Lundblade, L. and
L. Repka, "S/MIME Version 2 Message Specification", RFC
2311, March 1998.
Dusse, S., Hoffman, P., Ramsdell, B., and J. Weinstein,
"S/MIME Version 2 Certificate Handling", RFC 2312,
March 1998.
Kaliski, B., "PKCS #1: RSA Encryption Version 1.5", RFC
2313, March 1998.
Kaliski, B., "PKCS #10: Certificate Request Syntax
Version 1.5", RFC 2314, March 1998.
Kaliski, B., "PKCS #7: Certificate Message Syntax
Version 1.5", RFC 2314, March 1998.
[SMIMEv3] Housley, R., "Cryptographic Message Syntax", RFC 2630,
June 1999.
Rescorla, E., "Diffie-Hellman Key Agreement Method",
RFC 2631, June 1999.
Ramsdell, B., "S/MIME Version 3 Certificate Handling",
RFC 2632, June 1999.
Ramsdell, B., "S/MIME Version 3 Message Specification",
RFC 2633, June 1999.
Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[SMIMEv3.1] Housley, R., "Cryptographic Message Syntax", RFC 3852,
July 2004.
Ramsdell, B., "S/MIME Version 3.1 Certificate
Handling", RFC 3850, July 2004.
Ramsdell, B., "S/MIME Version 3.1 Message
Specification", RFC 3851, July 2004.
Hoffman, P., "Enhanced Security Services for S/MIME",
RFC 2634, June 1999.
[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.
[X.501] ITU-T Recommendation X.501 (1997) | ISO/IEC 9594- [X.501] ITU-T Recommendation X.501 (1997) | ISO/IEC 9594-
2:1997, Information technology - Open Systems 2:1997, Information technology - Open Systems
Interconnection - The Directory: Models. Interconnection - The Directory: Models.
[X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594- [X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-
8:1997, Information technology - Open Systems 8:1997, Information technology - Open Systems
Interconnection - The Directory: Authentication Interconnection - The Directory: Authentication
framework. Framework.
[X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594- [X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-
6:1997, Information technology - Open Systems 6:1997, Information technology - Open Systems
Interconnection - The Directory: Selected attribute Interconnection - The Directory: Selected Attribute
types. Types.
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)
Certificate Handling documents are backwards S/MIME v2 Message
Specification RFC 2312 [SMIMEv2], with the exception of the
algorithms (dropped RC2/40 requirement and added DSA and RSA-PSS
requirements). Therefore, it is recommended that RFC 2312 [SMIMEv2]
be moved to Historic status.
Appendix B. Acknowledgements Appendix B. Acknowledgements
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. 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 v3 of this document. Any list of people very hard and contributed to this document. Any list of people is
is doomed to omission and for that I apologize. In alphabetical doomed to omission and for that I apologize. In alphabetical order,
order, the following people stand out in my mind due to the fact that the following people stand out in my mind due to the fact that they
they made direct contributions to this document. made direct contributions to this document.
Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Paul Hoffman, Russ Bill Flanigan, Trevor Freeman, Elliott Ginsburg, Paul Hoffman, Russ
Housley, David P. Kemp, Michael Myers, John Pawling, Denis Pinkas, Housley, David P. Kemp, Michael Myers, John Pawling, Denis Pinkas,
and Jim Schaad. Jim Schaad, and Alfred Hoenes.
Author's Addresses Author's Addresses
Blake Ramsdell Blake Ramsdell
SendMail SendMail
Email: blake@sendmail.com Email: blake@sendmail.com
Sean Turner Sean Turner
 End of changes. 33 change blocks. 
68 lines changed or deleted 117 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/