draft-ietf-smime-rfc2632bis-05.txt   draft-ietf-smime-rfc2632bis-06.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-rfc2632bis-05.txt Sendmail, Inc. draft-ietf-smime-rfc2632bis-06.txt Sendmail, Inc.
February 15, 2003 May 6, 2004
Expires August 15, 2004 Expires November 6, 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 33 skipping to change at line 33
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.
1. Overview 1. Overview
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, the messages. Before using a public key to provide security services, the
S/MIME agent MUST certify that the public key is valid. S/MIME agents S/MIME agent MUST verify that the public key is valid. S/MIME agents
MUST use PKIX certificates to validate public keys as described in the MUST use PKIX certificates to validate public keys as described in the
Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL
Profile [KEYM]. S/MIME agents MUST meet the certificate processing Profile [KEYM]. S/MIME agents MUST meet the certificate processing
requirements documented in this document in addition to those stated requirements documented in this document in addition to those stated
in [KEYM]. in [KEYM].
This specification is compatible with the Cryptographic Message Syntax This specification is compatible with the Cryptographic Message Syntax
[CMS] in that it uses the data types defined by CMS. It also inherits [CMS] in that it uses the data types defined by CMS. It also inherits
all the varieties of architectures for certificate-based key all the varieties of architectures for certificate-based key
management supported by CMS. management supported by CMS.
1.1 Definitions 1.1 Definitions
For the purposes of this draft, the following definitions apply. For the purposes of this document, 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.208.
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
[ACAUTH]. [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.209.
Certificate: A type that binds an entity's distinguished name to a Certificate: A type that binds an entity's name to a public key with a
public key with a digital signature. This type is defined in the digital signature. This type is defined in the Internet X.509 Public
Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL Key Infrastructure (PKIX) Certificate and CRL Profile [KEYM]. This
Profile [KEYM]. This type also contains the distinguished name of the type also contains the distinguished name of the certificate issuer
certificate issuer (the signer), an issuer-specific serial number, the (the signer), an issuer-specific serial number, the issuer's signature
issuer's signature algorithm identifier, a validity period, and algorithm identifier, a validity period, and extensions also defined
extensions also defined in that document. in that document.
Certificate Revocation List (CRL): A type that contains information Certificate Revocation List (CRL): A type that contains information
about certificates whose validity an issuer has prematurely revoked. about certificates whose validity an issuer has prematurely revoked.
The information consists of an issuer name, the time of issue, the The information consists of an issuer name, the time of issue, the
next scheduled time of issue, a list of certificate serial numbers and next scheduled time of issue, a list of certificate serial numbers and
their associated revocation times, and extensions as defined in their associated revocation times, and extensions as defined in
[KEYM]. The CRL is signed by the issuer. The type intended by this [KEYM]. The CRL is signed by the issuer. The type intended by this
specification is the one defined in [KEYM]. specification is the one defined in [KEYM].
DER: Distinguished Encoding Rules for ASN.1, as defined in ITU-T DER: Distinguished Encoding Rules for ASN.1, as defined in ITU-T
skipping to change at line 113 skipping to change at line 113
1.4 Changes Since S/MIME v3.0 1.4 Changes Since S/MIME v3.0
Version 1 and Version 2 CRLs MUST be supported. Version 1 and Version 2 CRLs MUST be supported.
Multiple CA certificates with the same subject and public key, but Multiple CA certificates with the same subject and public key, but
with overlapping validity periods MUST be supported. with overlapping validity periods MUST be supported.
Version 2 attribute certificates SHOULD be supported, and version 1 Version 2 attribute certificates SHOULD be supported, and version 1
attributes certificates MUST NOT be used. attributes certificates MUST NOT be used.
MD2 use for certificate signatures discouraged, and security language The use of the MD2 digest algorithm for certificate signatures is
added. discouraged, and security language added.
Clarified use of email address use in certificates. Certificates that Clarified use of email address use in certificates. Certificates that
do not contain an email address have no requirements for verifying the do not contain an email address have no requirements for verifying the
email address associated with the certificate. email address associated with the certificate.
Receiving agents SHOULD display certificate information when Receiving agents SHOULD display certificate information when
displaying the results of signature verification. displaying the results of signature verification.
Receiving agents MUST NOT accept a signature made with a certificate Receiving agents MUST NOT accept a signature made with a certificate
that does not have the digitalSignature or nonRepudiation bit set. that does not have the digitalSignature or nonRepudiation bit set.
Clarifications for the interpretation of the key usage and extended Clarifications for the interpretation of the key usage and extended
key usage extensions. key usage extensions.
1.5 Discussion of This Draft
This draft is being discussed on the "ietf-smime" mailing list.
To 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 for the mailing list
at <http://www.imc.org/ietf-smime/>.
2. CMS Options 2. CMS Options
The CMS message format allows for a wide variety of options in content The CMS message format allows for a wide variety of options in content
and algorithm support. This section puts forth a number of support and algorithm support. This section puts forth a number of support
requirements and recommendations in order to achieve a base level of requirements and recommendations in order to achieve a base level of
interoperability among all S/MIME implementations. Most of the CMS interoperability among all S/MIME implementations. Most of the CMS
format for S/MIME messages is defined in [SMIME-MSG]. format for S/MIME messages is defined in [SMIME-MSG].
2.1 CertificateRevocationLists 2.1 CertificateRevocationLists
skipping to change at line 180 skipping to change at line 166
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 [ACAUTH] 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 PKIX
X.509 Attribute Certificates. 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
flexibility as was intended in the PKCS #6. Thus, sending and flexibility as was intended in the PKCS #6. Thus, sending and
receiving agents MUST NOT use PKCS #6 extended certificates. receiving agents MUST NOT use PKCS #6 extended certificates.
X.509 version 1 attribute certificates are also not widely X.509 version 1 attribute certificates are also not widely
implemented, and have been superceded with version 2 attribute implemented, and have been superseded with version 2 attribute
certificates. Sending agents MUST NOT send version 1 attribute certificates. Sending agents MUST NOT send version 1 attribute
certificates. certificates.
2.3 CertificateSet 2.3 CertificateSet
Receiving agents MUST be able to handle an arbitrary number of Receiving agents MUST be able to handle an arbitrary number of
certificates of arbitrary relationship to the message sender and to certificates of arbitrary relationship to the message sender and to
each other in arbitrary order. In many cases, the certificates each other in arbitrary order. In many cases, the certificates
included in a signed message may represent a chain of certification included in a signed message may represent a chain of certification
from the sender to a particular root. There may be, however, from the sender to a particular root. There may be, however,
skipping to change at line 220 skipping to change at line 206
can be omitted if S/MIME objects are sent within a group of can be omitted if S/MIME objects are sent within a group of
correspondents that has established access to each other's correspondents that has established access to each other's
certificates by some other means such as a shared directory or manual certificates by some other means such as a shared directory or manual
certificate distribution. Receiving S/MIME agents SHOULD be able to certificate distribution. Receiving S/MIME agents SHOULD be able to
handle messages without certificates using a database or directory handle messages without certificates using a database or directory
lookup scheme. lookup scheme.
A sending agent SHOULD include at least one chain of certificates up A sending agent SHOULD include at least one chain of certificates up
to, but not including, a Certificate Authority (CA) that it believes to, but not including, a Certificate Authority (CA) that it believes
that the recipient may trust as authoritative. A receiving agent that the recipient may trust as authoritative. A receiving agent
SHOULD be able to handle an arbitrarily large number of certificates MUST be able to handle an arbitrarily large number of certificates
and chains. and chains.
Agents MAY send CA certificates, that is, certificates that are self- Agents MAY send CA certificates, that is, certificates which can be
signed and can be considered the "root" of other chains. Note that considered the "root" of other chains, and which MAY be self-signed.
receiving agents SHOULD NOT simply trust any self-signed certificates Note that receiving agents SHOULD NOT simply trust any self-signed
as valid CAs, but SHOULD use some other mechanism to determine if this certificates as valid CAs, but SHOULD use some other mechanism to
is a CA that should be trusted. Also note that when certificates determine if this is a CA that should be trusted. Also note that when
contain DSA public keys the parameters may be located in the root certificates contain DSA public keys the parameters may be located in
certificate. This would require that the recipient possess both the the root certificate. This would require that the recipient possess
end-entity certificate as well as the root certificate to perform a both the end-entity certificate as well as the root certificate to
signature verification, and is a valid example of a case where perform a signature verification, and is a valid example of a case
transmitting the root certificate may be required. where transmitting the root certificate may be required.
Receiving agents MUST support chaining based on the distinguished name Receiving agents MUST support chaining based on the distinguished name
fields. Other methods of building certificate chains may be supported. fields. Other methods of building certificate chains MAY be supported.
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
skipping to change at line 260 skipping to change at line 246
Receiving agents MUST recognize and accept certificates that contain Receiving agents MUST recognize and accept certificates that contain
no email address. Receiving agents MUST recognize email addresses in no email address. Receiving agents MUST recognize email addresses in
the subjectAltName field. Receiving agents MUST recognize email the subjectAltName field. Receiving agents MUST recognize email
addresses in the Distinguished Name field in the PKCS #9 [PKCS9] addresses in the Distinguished Name field in the PKCS #9 [PKCS9]
emailAddress attribute: 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.
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, or Sender header of a mail message matches an Internet mail address,
if present, in the signer's certificate, if mail addresses are present if present, in the signer's certificate, if mail addresses are present
in the certificate. A receiving agent SHOULD provide some explicit in the certificate. A receiving agent SHOULD provide some explicit
alternate processing of the message if this comparison fails, which alternate processing of the message if this comparison fails, which
may be to display a message that shows the recipient the addresses in may be to display a message that shows the recipient the addresses in
the certificate or other certificate details. the certificate or other certificate details.
skipping to change at line 404 skipping to change at line 392
which have value in particular certification environments. Further, which have value in particular certification environments. Further,
there are active efforts underway to issue PKIX certificates for there are active efforts underway to issue PKIX certificates for
business purposes. This document identifies the minimum required set business purposes. This document identifies the minimum required set
of certificate extensions which have the greatest value in the S/MIME of certificate extensions which have the greatest value in the S/MIME
environment. The syntax and semantics of all the identified extensions environment. The syntax and semantics of all the identified extensions
are defined in [KEYM]. 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 certificates. Some mechanism SHOULD exist to they appear in end-entity and CA certificates. Some mechanism SHOULD
gracefully handle other certificate extensions when they appear in exist to gracefully handle other certificate extensions when they
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
critical extensions (extensions that have the critical field set to critical extensions (extensions that have the critical field set to
TRUE) other than those listed here. These extensions SHOULD be marked TRUE) other than those listed here. These extensions SHOULD be marked
as non-critical unless the proper handling of the extension is deemed as non-critical unless the proper handling of the extension is deemed
critical to the correct interpretation of the associated certificate. critical to the correct interpretation of the associated certificate.
Other extensions may be included, but those extensions SHOULD NOT be Other extensions may be included, but those extensions SHOULD NOT be
marked as critical. marked as critical.
Interpretation and syntax for all extensions MUST follow [KEYM], Interpretation and syntax for all extensions MUST follow [KEYM],
skipping to change at line 463 skipping to change at line 451
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 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.2.1 Key Usage in Diffie-Hellman Key Exchange Certificates
For Diffie-Hellman key exchange certificates (certificates in which
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
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
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
only use the public key if the keyUsage decipherOnly bit is set to 0.
4.4.3 Subject Alternative Name Extension 4.4.3 Subject Alternative Name Extension
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 RFC-2822 email address(es) that
correspond to the entity for this certificate. Any RFC-2822 email correspond to the entity for this certificate. Any RFC-2822 email
addresses present MUST be encoded using the rfc822Name CHOICE of the addresses present MUST be encoded using the rfc822Name CHOICE of the
GeneralName type. Since the SubjectAltName type is a SEQUENCE OF GeneralName type. Since the SubjectAltName type is a SEQUENCE OF
GeneralName, multiple RFC-2822 email addresses MAY be present. GeneralName, multiple RFC-2822 email addresses MAY be present.
4.4.4 Extended Key Usage Extension 4.4.4 Extended Key Usage Extension
skipping to change at line 497 skipping to change at line 474
used. The set of technical purposes for the certificate therefore are used. The set of technical purposes for the certificate therefore are
the intersection of the uses indicated in the key usage and extended the intersection of the uses indicated in the key usage and extended
key usage extensions. key usage extensions.
For example, if the certificate contains a key usage extension For example, if the certificate contains a key usage extension
indicating digital signature and an extended key usage extension which indicating digital signature and an extended key usage extension which
includes the email protection OID, then the certificate may be used includes the email protection OID, then the certificate may be used
for signing but not encrypting S/MIME messages. If the certificate for signing but not encrypting S/MIME messages. If the certificate
contains a key usage extension indicating digital signature, but no contains a key usage extension indicating digital signature, but no
extended key usage extension then the certificate may also be used to extended key usage extension then the certificate may also be used to
sign but not encrypt S/MIME messages sign but not encrypt S/MIME messages.
If the extended key usage extension is present in the certificate then If the extended key usage extension is present in the certificate then
interpersonal message S/MIME receiving agents MUST check it contains interpersonal message S/MIME receiving agents MUST check it contains
either the emailProtection or the anyExtendedKeyUsage OID as defined either the emailProtection or the anyExtendedKeyUsage OID as defined
in [KEYM]. S/MIME uses other than interpersonal messaging MAY require in [KEYM]. S/MIME uses other than interpersonal messaging MAY require
the explicit presence of the extended key usage extension or other the explicit presence of the extended key usage extension or other
OIDs to be present in the extension or both. OIDs to be present in the extension or both.
5. Security Considerations 5. Security Considerations
skipping to change at line 523 skipping to change at line 500
the scope of this document, but some significant concerns are listed the scope of this document, but some significant concerns are listed
here. here.
When processing certificates, there are many situations where the When processing certificates, there are many situations where the
processing might fail. Because the processing may be done by a user processing might fail. Because the processing may be done by a user
agent, a security gateway, or other program, there is no single way to agent, a security gateway, or other program, there is no single way to
handle such failures. Just because the methods to handle the failures handle such failures. Just because the methods to handle the failures
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 noticeable 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,if the certificate contains at least one mail address 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
skipping to change at line 553 skipping to change at line 530
At the Selected Areas in Cryptography '95 conference in May 1995, At the Selected Areas in Cryptography '95 conference in May 1995,
Rogier and Chauvaud presented an attack on MD2 that can nearly find Rogier and Chauvaud presented an attack on MD2 that can nearly find
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.
It is possible for there to be multiple unexpired CRLs for a CA. If an
agent is consulting CRLs for certificate validation, it SHOULD make
sure that the most recently issued CRL for that CA is consulted, since
an S/MIME message sender could deliberately include an older unexpired
CRL in an S/MIME message. This older CRL might not include recent
revoked certificates, which might lead an agent to accept a
certificate that has been revoked in a subsequent CRL.
A. Normative References A. Normative References
[ACAUTH] "An Internet Attribute Certificate Profile for [ACAUTH] "An Internet Attribute Certificate Profile for
Authorization", RFC 3281 Authorization", RFC 3281
[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
skipping to change at line 637 skipping to change at line 622
Jim Schaad Jim Schaad
D. Editor's address D. Editor's address
Blake Ramsdell Blake Ramsdell
Sendmail, Inc. Sendmail, Inc.
704 228th Ave NE #775 704 228th Ave NE #775
Sammamish, WA 98074 Sammamish, WA 98074
blake@sendmail.com blake@sendmail.com
E. Changes from last draft
Updated editor contact info (Blake Ramsdell)
Separated normative and informative references (Jim Schaad)
 End of changes. 

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