draft-ietf-smime-rfc2632bis-01.txt   draft-ietf-smime-rfc2632bis-02.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-rfc2632bis-01.txt Brute Squad Labs draft-ietf-smime-rfc2632bis-02.txt Brute Squad Labs
June 30, 2002 October 30, 2002
Expires December 30, 2002 Expires April 30, 2003
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 223 skipping to change at line 223
attribute certificate use is defined in [SECLABEL]. attribute certificate use is defined in [SECLABEL].
3. Using Distinguished Names for Internet Mail 3. Using Distinguished Names for Internet Mail
End-entity certificates MAY contain an Internet mail address as End-entity certificates MAY contain an Internet mail address as
described in [RFC-2822]. The address must be an "addr-spec" as defined described in [RFC-2822]. The address must be an "addr-spec" as defined
in Section 3.4.1 of that specification. The email address SHOULD be in 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 email addresses in the subjectAltName Receiving agents MUST recognize and accept certificates that contain
field. Receiving agents MUST recognize email addresses in the no email address. Receiving agents MUST recognize email addresses in
Distinguished Name field in the PKCS #9 [PKCS9] emailAddress the subjectAltName field. Receiving agents MUST recognize email
attribute: addresses in the Distinguished Name field in the PKCS #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 }
Sending agents SHOULD make the address in the From or Sender header in 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 a mail message match an Internet mail address in the signer's
certificate. Receiving agents MUST check that the address in the From certificate. Receiving agents MUST check that the address in the From
or Sender header of a mail message matches an Internet mail address in or Sender header of a mail message matches an Internet mail address,
the signer's certificate, if mail addresses are present in the if present, in the signer's certificate, if mail addresses are present
certificate. A receiving agent SHOULD provide some explicit alternate in the certificate. A receiving agent SHOULD provide some explicit
processing of the message if this comparison fails, which may be to alternate processing of the message if this comparison fails, which
display a message that shows the recipient the addresses in the may be to display a message that shows the recipient the addresses in
certificate or other certificate details. the certificate or other certificate details.
A receiving agent SHOULD display a subject name or other certificate
details when displaying an indication of successful or unsuccessful
signature verification.
All subject and issuer names MUST be populated (i.e. not an empty All subject and issuer names MUST be populated (i.e. not an empty
SEQUENCE) in S/MIME-compliant PKIX certificates, except that the SEQUENCE) in S/MIME-compliant PKIX certificates, except that the
subject DN in a user's (i.e. end-entity) certificate MAY be an empty subject DN in a user's (i.e. end-entity) certificate MAY be an empty
SEQUENCE in which case the subjectAltName extension will include the SEQUENCE in which case the subjectAltName extension will include the
subject's identifier and MUST be marked as critical. subject's identifier and MUST be marked as critical.
4. Certificate Processing 4. Certificate Processing
A receiving agent needs to provide some certificate retrieval A receiving agent needs to provide some certificate retrieval
skipping to change at line 418 skipping to change at line 423
lists and other data. lists and other data.
For example, a certification authority may create subordinate issuer For example, a certification authority may create subordinate issuer
certificates which contain a key usage extension which specifies that certificates which contain a key usage extension which specifies that
the corresponding public key can be used to sign end user certificates the corresponding public key can be used to sign end user certificates
and sign CRLs. and sign CRLs.
If a key usage extension is included in a PKIX certificate, then it If a key usage extension is included in a PKIX certificate, then it
MUST be marked as critical. MUST be marked as critical.
S/MIME receiving agents MUST NOT accept the signature of a message if
it was verified using a certificate which contains the key usage
extension without either the digitalSignature or nonRepudiation bit
set. Sometimes S/MIME is used as a secure message transport for
applications beyond interpersonal messaging. In such cases, the
S/MIME-enabled application can specify additional requirements
concerning the digitalSignature or nonRepudiation bits within this
extension.
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 462 skipping to change at line 476
has not been listed, however, the reader should not assume that they has not been listed, however, the reader should not assume that they
are not important. The opposite is true: if a certificate is not are not important. The opposite is true: if a certificate is not
provably valid and associated with the message, the processing provably valid and associated with the message, the processing
software should take immediate and noticable steps to inform the end software should take immediate and noticable steps to inform the end
user about it. user about it.
Some of the many places where signature and certificate checking might Some of the many places where signature and certificate checking might
fail include: fail include:
- no Internet mail addresses in a certificate matches the sender of a - no Internet mail addresses in a certificate matches the sender of a
message message,if the certificate contains at least one mail address
- no certificate chain leads to a trusted CA - no certificate chain leads to a trusted CA
- no ability to check the CRL for a certificate - no ability to check the CRL for a certificate
- an invalid CRL was received - an invalid CRL was received
- the CRL being checked is expired - the CRL being checked is expired
- the certificate is expired - the certificate is expired
- the certificate has been revoked - the certificate has been revoked
There are certainly other instances where a certificate may be There are certainly other instances where a certificate may be
invalid, and it is the responsibility of the processing software to invalid, and it is the responsibility of the processing software to
check them all thoroughly, and to decide what to do if the check check them all thoroughly, and to decide what to do if the check
skipping to change at line 489 skipping to change at line 503
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
[CERTV2] "S/MIME Version 2 Certificate Handling", RFC 2312 [CERTV2] "S/MIME Version 2 Certificate Handling", RFC 2312
[CMS] "Cryptographic Message Syntax", Internet Draft [CMS] "Cryptographic Message Syntax", RFC 3369
draft-ietf-smime-rfc2630bis
[CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", Internet- [CMSALG] "Cryptographic Message Syntax (CMS) Algorithms", RFC 3370
Draft draft-ietf-smime-cmsalg
[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 [KEYMAC] "An Internet Attribute Certificate Profile for
Authorization", RFC 3281 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
skipping to change at line 554 skipping to change at line 566
Blake Ramsdell Blake Ramsdell
Brute Squad Labs Brute Squad Labs
Suite 217-C Suite 217-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
Updated [KEYM] reference, added [KEYMALG] reference (Russ Housley) Clarifications for the use of email addresses in certificates (David
P. Kemp)
Added [KEYMAC] reference and referred to it from section 2.2 (Russ
Housley)
Added clarification text to section 2.1 regarding all versions of CRLs
to be supported (Russ Housley)
Moved text regarding CA certificates and overlapping validity periods
from section 2.1 to section 4 (Russ Housley)
Changed reference to non-section section 3.1 to section 3 (Russ
Housley).
Clarification of v2 vs. v1 attribute certificates (Russ Housley)
MUST NOT use v1 attribute certificates (Russ Housley)
Clarification of DSA certificate language (Russ Housley)
Removed non-recommendation of non-DN chain building (Russ Housley)
Added [SECLABEL] and reference from section 2.3 (Russ Housley)
Added [PKCS9] and reference from section 3 (Russ Housley)
Changed references to "certificate-revocation" to "certificate
revocation (Russ Housley)
Changed references to "certificate chain" to "certification path" nonRepudiation and digitalSignature key usage language clarification
(Russ Housley) (Russ Housley)
Clarification of extension handling (Russ Housley) Updated references to CMS and CMSALG to point to RFCs (Blake Ramsdell)
Removed PKCS#1 v1.5 warning (Russ Housley)
Added MD2 warnings, [RC95] reference and MAY language (Jim Schaad,
Blake Ramsdell, Russ Housley)
 End of changes. 

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