draft-ietf-smime-rfc2632bis-03.txt   draft-ietf-smime-rfc2632bis-04.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-rfc2632bis-03.txt Brute Squad Labs draft-ietf-smime-rfc2632bis-04.txt Brute Squad Labs
February 20, 2003 October 26, 2003
Expires August 20, 2003 Expires April 26, 2004
S/MIME Version 3.1 Certificate Handling S/MIME Version 3.1 Certificate Handling
Status of this memo Status of this memo
This document is an Internet-Draft and is in full conformance with all This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026. provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Task Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other Force (IETF), its areas, and its working groups. Note that other
skipping to change at line 56 skipping to change at line 56
For the purposes of this draft, the following definitions apply. For the purposes of this draft, the following definitions apply.
ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680-689. ASN.1: Abstract Syntax Notation One, as defined in ITU-T X.680-689.
Attribute Certificate (AC): An X.509 AC is a separate structure from a Attribute Certificate (AC): An X.509 AC is a separate structure from a
subject's public key X.509 Certificate. A subject may have multiple subject's public key X.509 Certificate. A subject may have multiple
X.509 ACs associated with each of its public key X.509 Certificates. X.509 ACs associated with each of its public key X.509 Certificates.
Each X.509 AC binds one or more Attributes with one of the subject's Each X.509 AC binds one or more Attributes with one of the subject's
public key X.509 Certificates. The X.509 AC syntax is defined in public key X.509 Certificates. The X.509 AC syntax is defined in
[KEYMAC]. [ACAUTH].
BER: Basic Encoding Rules for ASN.1, as defined in ITU-T X.690. BER: Basic Encoding Rules for ASN.1, as defined in ITU-T X.690.
Certificate: A type that binds an entity's distinguished name to a Certificate: A type that binds an entity's distinguished name to a
public key with a digital signature. This type is defined in the public key with a digital signature. This type is defined in the
Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL
Profile [KEYM]. This type also contains the distinguished name of the Profile [KEYM]. This type also contains the distinguished name of the
certificate issuer (the signer), an issuer-specific serial number, the certificate issuer (the signer), an issuer-specific serial number, the
issuer's signature algorithm identifier, a validity period, and issuer's signature algorithm identifier, a validity period, and
extensions also defined in that document. extensions also defined in that document.
skipping to change at line 90 skipping to change at line 90
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 of S/MIME 1.2 Compatibility with Prior Practice of S/MIME
S/MIME version 3 agents should attempt to have the greatest S/MIME version 3.1 agents should attempt to have the greatest
interoperability possible with S/MIME version 2 agents. S/MIME version interoperability possible with agents for prior versions of S/MIME.
2 is described in RFC 2311 through RFC 2315, inclusive. RFC 2311 also S/MIME version 2 is described in RFC 2311 through RFC 2315, inclusive
has historical information about the development of S/MIME. and S/MIME version 3 is described in RFC 2630 through RFC 2634
inclusive. RFC 2311 also has historical information about the
development of S/MIME.
1.3 Terminology 1.3 Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [MUSTSHOULD]. document are to be interpreted as described in [MUSTSHOULD].
1.4 Discussion of This Draft 1.4 Changes Since S/MIME v3.0
Version 1 and Version 2 CRLs MUST be supported.
Multiple CA certificates with the same subject and public key, but
with overlapping validity periods MUST be supported.
Version 2 attribute certificates SHOULD be supported, and version 1
attributes certificates MUST NOT be used.
MD2 use for certificate signatures discouraged, and security language
added.
Clarified use of email address use in certificates. Certificates that
do not contain an email address have no requirements for verifying the
email address associated with the certificate.
Receiving agents SHOULD display certificate information when
displaying the results of signature verification.
Receiving agents MUST NOT accept a signature made with a certificate
that does not have the digitalSignature or nonRepudiation bit set.
Clarifications for the interpretation of the key usage and extended
key usage extensions.
1.5 Discussion of This Draft
This draft is being discussed on the "ietf-smime" mailing list. This draft is being discussed on the "ietf-smime" mailing list.
To subscribe, send a message to: To subscribe, send a message to:
ietf-smime-request@imc.org ietf-smime-request@imc.org
with the single word with the single word
subscribe subscribe
skipping to change at line 146 skipping to change at line 174
later messages. later messages.
2.2 CertificateChoices 2.2 CertificateChoices
Receiving agents MUST support PKIX v1 and PKIX v3 certificates. See Receiving agents MUST support PKIX v1 and PKIX v3 certificates. See
[KEYM] for details about the profile for certificate formats. End [KEYM] for details about the profile for certificate formats. End
entity certificates MAY include an Internet mail address, as described entity certificates MAY include an Internet mail address, as described
in section 3. in section 3.
Receiving agents SHOULD support X.509 version 2 attribute Receiving agents SHOULD support X.509 version 2 attribute
certificates. See [KEYMAC] for details about the profile for attribute certificates. See [ACAUTH] for details about the profile for attribute
certificates. certificates.
2.2.1 Historical Note About CMS Certificates 2.2.1 Historical Note About CMS Certificates
The CMS message format supports a choice of certificate formats for The CMS message format supports a choice of certificate formats for
public key content types: PKIX, PKCS #6 Extended Certificates and public key content types: PKIX, PKCS #6 Extended Certificates and
X.509 Attribute Certificates. X.509 Attribute Certificates.
The PKCS #6 format is not in widespread use. In addition, PKIX The PKCS #6 format is not in widespread use. In addition, PKIX
certificate extensions address much of the same functionality and certificate extensions address much of the same functionality and
skipping to change at line 432 skipping to change at line 460
S/MIME receiving agents MUST NOT accept the signature of a message if S/MIME receiving agents MUST NOT accept the signature of a message if
it was verified using a certificate which contains the key usage it was verified using a certificate which contains the key usage
extension without either the digitalSignature or nonRepudiation bit extension without either the digitalSignature or nonRepudiation bit
set. Sometimes S/MIME is used as a secure message transport for set. Sometimes S/MIME is used as a secure message transport for
applications beyond interpersonal messaging. In such cases, the applications beyond interpersonal messaging. In such cases, the
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
presume that the digitalSignature and nonRepudiation bits are set.
4.4.2.1 Key Usage in Diffie-Hellman Key Exchange Certificates 4.4.2.1 Key Usage in Diffie-Hellman Key Exchange Certificates
For Diffie-Hellman key exchange certificates (certificates in which For Diffie-Hellman key exchange certificates (certificates in which
the subject public key algorithm is dhpublicnumber), if the keyUsage the subject public key algorithm is dhpublicnumber), if the keyUsage
keyAgreement bit is set to 1 AND if the public key is to be used to keyAgreement bit is set to 1 AND if the public key is to be used to
form a pairwise key to decrypt data, then the S/MIME agent MUST only form a pairwise key to decrypt data, then the S/MIME agent MUST only
use the public key if the keyUsage encipherOnly bit is set to 0. If use the public key if the keyUsage encipherOnly bit is set to 0. If
the keyUsage keyAgreement bit is set to 1 AND if the key is to be used the keyUsage keyAgreement bit is set to 1 AND if the key is to be used
to form a pairwise key to encrypt data, then the S/MIME agent MUST to form a pairwise key to encrypt data, then the S/MIME agent MUST
only use the public key if the keyUsage decipherOnly bit is set to 0. only use the public key if the keyUsage decipherOnly bit is set to 0.
skipping to change at line 524 skipping to change at line 555
collisions [RC95]. Collisions occur when one can find two different collisions [RC95]. Collisions occur when one can find two different
messages that generate the same message digest. A checksum operation messages that generate the same message digest. A checksum operation
in MD2 is the only remaining obstacle to the success of the attack. 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. For this reason, the use of MD2 for new applications is discouraged.
It is still reasonable to use MD2 to verify existing signatures, as 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 the ability to find collisions in MD2 does not enable an attacker to
find new messages having a previously computed hash value. find new messages having a previously computed hash value.
A. References A. References
[ACAUTH] "An Internet Attribute Certificate Profile for
Authorization", RFC 3281
[CERTV2] "S/MIME Version 2 Certificate Handling", RFC 2312 [CERTV2] "S/MIME Version 2 Certificate Handling", RFC 2312
[CMS] "Cryptographic Message Syntax", RFC 3369 [CMS] "Cryptographic Message Syntax", RFC 3369
[CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370 [CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370
[KEYM] "Internet X.509 Public Key Infrastructure Certificate and CRL [KEYM] "Internet X.509 Public Key Infrastructure Certificate and CRL
Profile", RFC 3280 Profile", RFC 3280
[KEYMAC] "An Internet Attribute Certificate Profile for
Authorization", RFC 3281
[KEYMALG] "Algorithms and Identifiers for the Internet X.509 Public [KEYMALG] "Algorithms and Identifiers for the Internet X.509 Public
Key Infrastructure Certificate and CRL Profile ", RFC 3279 Key Infrastructure Certificate and CRL Profile ", RFC 3279
[MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement [MUSTSHOULD] "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119 Levels", RFC 2119
[PKCS9] "PKCS #9: Selected Object Classes and Attribute Types Version [PKCS9] "PKCS #9: Selected Object Classes and Attribute Types Version
2.0", RFC 2985 2.0", RFC 2985
[RC95] Rogier, N. and Chauvaud, P., "The compression function of MD2 [RC95] Rogier, N. and Chauvaud, P., "The compression function of MD2
skipping to change at line 575 skipping to change at line 606
[X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997, [X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997,
Information technology - Open Systems Interconnection - The Directory: Information technology - Open Systems Interconnection - The Directory:
Authentication framework Authentication framework
[X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997, [X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997,
Information technology - Open Systems Interconnection - The Directory: Information technology - Open Systems Interconnection - The Directory:
Selected attribute types. Selected attribute types.
B. Acknowledgements B. Acknowledgements
[tbd] 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 be
a v3.
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
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
made direct contributions to this document.
Bill Flanigan
Trevor Freeman
Elliott Ginsburg
Paul Hoffman
Russ Housley
David P. Kemp
Michael Myers
John Pawling
Denis Pinkas
Jim Schaad
C. Editor's address C. Editor's address
Blake Ramsdell Blake Ramsdell
Brute Squad Labs Brute Squad Labs
Suite 217-C Suite 407-C
16451 Redmond Way 16451 Redmond Way
Redmond, WA 98052-4482 Redmond, WA 98052-4482
blake@brutesquadlabs.com blake@brutesquadlabs.com
D. Changes from last draft D. Changes from last draft
Added "4.4.4 Extended Key Usage Extension" (Trevor Freeman)
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/