< draft-ietf-smime-rfc2632bis-06.txt   draft-ietf-smime-rfc2632bis-07.txt >
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-rfc2632bis-06.txt Sendmail, Inc. draft-ietf-smime-rfc2632bis-07.txt Sendmail, Inc.
May 6, 2004 June 4, 2004
Expires November 6, 2004 Expires December 4, 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 28 skipping to change at line 29
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 material time. It is inappropriate to use Internet-Drafts as reference material
or to cite them other than as "work in progress." 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.
Abstract
This document specifies conventions for X.509 certificate usage by
S/MIME (Secure/Multipurpose Internet Mail Extensions) agents. S/MIME
provides a method to send and receive secure MIME messages, and
certificates are an integral part of S/MIME agent processing. S/MIME
agents validate certificates as described in RFC 3280, the Internet
X.509 Public Key Infrastructure Certificate and CRL Profile. S/MIME
agents must meet the certificate processing requirements in this
document as well as those in RFC 3280.
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 verify 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
skipping to change at line 103 skipping to change at line 115
and S/MIME version 3 is described in RFC 2630 through RFC 2634 and S/MIME version 3 is described in RFC 2630 through RFC 2634
inclusive. RFC 2311 also has historical information about the inclusive. RFC 2311 also has historical information about the
development of S/MIME. 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 Changes Since S/MIME v3.0 1.4 Changes Since S/MIME v3 (RFC 2632)
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.
The use of the MD2 digest algorithm for certificate signatures is The use of the MD2 digest algorithm for certificate signatures is
discouraged, and security language 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.
skipping to change at line 154 skipping to change at line 166
All agents MUST be capable of performing revocation checks using CRLs All agents MUST be capable of performing revocation checks using CRLs
as specified in [KEYM]. All agents MUST perform revocation status as specified in [KEYM]. All agents MUST perform revocation status
checking in accordance with [KEYM]. Receiving agents MUST recognize checking in accordance with [KEYM]. Receiving agents MUST recognize
CRLs in received S/MIME messages. CRLs in received S/MIME messages.
Agents SHOULD store CRLs received in messages for use in processing Agents SHOULD store CRLs received in messages for use in processing
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 v1 X.509 and v3 X.509 identity
[KEYM] for details about the profile for certificate formats. End certificates as profiled in [KEYM]. End entity certificates MAY
entity certificates MAY include an Internet mail address, as described 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 PKIX public key content types: PKIX, PKCS #6 Extended Certificates [PKCS6]
Attribute Certificates. and PKIX 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 superseded 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.
skipping to change at line 263 skipping to change at line 274
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.
A receiving agent SHOULD display a subject name or other certificate A receiving agent SHOULD display a subject name or other certificate
details when displaying an indication of successful or unsuccessful details when displaying an indication of successful or unsuccessful
signature verification. 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 X.509 identity certificates, except that
subject DN in a user's (i.e. end-entity) certificate MAY be an empty the subject DN in a user's (i.e. end-entity) certificate MAY be an
SEQUENCE in which case the subjectAltName extension will include the empty SEQUENCE in which case the subjectAltName extension will include
subject's identifier and MUST be marked as critical. the 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
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 example retrieval mechanisms. X.500 directory service is an excellent example
of a certificate retrieval-only mechanism that is compatible with of a certificate retrieval-only mechanism that is compatible with
classic X.500 Distinguished Names. The PKIX Working Group is classic X.500 Distinguished Names. Another method under consideration
investigating other mechanisms such as directory servers. Another by the IETF is to provide certificate retrieval services as part of
method under consideration by the IETF is to provide certificate the existing Domain Name System (DNS). Until such mechanisms are
retrieval services as part of the existing Domain Name System (DNS). widely used, their utility may be limited by the small number of
Until such mechanisms are widely used, their utility may be limited by correspondent's certificates that can be retrieved. At a minimum, for
the small number of correspondent's certificates that can be initial S/MIME deployment, a user agent could automatically generate a
retrieved. At a minimum, for initial S/MIME deployment, a user agent message to an intended recipient requesting that recipient's
could automatically generate a message to an intended recipient certificate in a signed return message.
requesting that 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 environments, a way so as to guarantee their later retrieval. In many environments,
it may be desirable to link the certificate retrieval/storage it may be desirable to link the certificate retrieval/storage
mechanisms together in some sort of certificate database. In its mechanisms together in some sort of certificate database. In its
simplest form, a certificate database would be local to a particular simplest form, a certificate database would be local to a particular
user and would function in a similar way as a "address book" that user and would function in a similar way as a "address book" that
stores a user's frequent correspondents. In this way, the certificate stores a user's frequent correspondents. In this way, the certificate
retrieval mechanism would be limited to the certificates that a user retrieval mechanism would be limited to the certificates that a user
skipping to change at line 307 skipping to change at line 317
For instance, a secure Internet mail agent may resort to checking a For instance, a secure Internet mail agent may resort to checking a
centralized certificate retrieval mechanism for a certificate if it centralized certificate retrieval mechanism for a certificate if it
can not be found in a user's local certificate storage/retrieval can not be found in a user's local certificate storage/retrieval
database. database.
Receiving and sending agents SHOULD provide a mechanism for the import Receiving and sending agents SHOULD provide a mechanism for the import
and export of certificates, using a CMS certs-only message. This and export of certificates, using a CMS certs-only message. This
allows for import and export of full certificate chains as opposed to allows for import and export of full certificate chains as opposed to
just a single certificate. This is described in [SMIME-MSG]. just a single certificate. This is described in [SMIME-MSG].
Agents MUST handle multiple valid Certificate Authority (CA) Agents MUST handle multiple valid Certification Authority (CA)
certificates containing the same subject name and the same public keys certificates containing the same subject name and the same public keys
but with overlapping validity intervals. but with overlapping validity intervals.
4.1 Certificate Revocation Lists 4.1 Certificate Revocation Lists
In general, it is always better to get the latest CRL information from In general, it is always better to get the latest CRL information from
a CA than to get information stored away from incoming messages. A a CA than to get information stored away from incoming messages. A
receiving agent SHOULD have access to some certificate revocation list receiving agent SHOULD have access to some certificate revocation list
(CRL) retrieval mechanism in order to gain access to certificate (CRL) retrieval mechanism in order to gain access to certificate
revocation information when validating certification paths. A revocation information when validating certification paths. A
skipping to change at line 538 skipping to change at line 548
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 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 agent is consulting CRLs for certificate validation, it SHOULD make
sure that the most recently issued CRL for that CA is consulted, since sure that the most recently issued CRL for that CA is consulted, since
an S/MIME message sender could deliberately include an older unexpired an S/MIME message sender could deliberately include an older unexpired
CRL in an S/MIME message. This older CRL might not include recent CRL in an S/MIME message. This older CRL might not include recent
revoked certificates, which might lead an agent to accept a 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
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 in an
S/MIME message. For most sending agents, the SigningTime attribute
could be deliberately set to direct the receiving agent to check a CRL
that could have out-of-date revocation status for a certificate, or
cause an improper result when checking the Validity field of a
certificate.
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 (CMS)",
draft-ietf-smime-3369bis-04
[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
[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
skipping to change at line 568 skipping to change at line 588
[RFC-2822], "Internet Message Format", RFC 2822 [RFC-2822], "Internet Message Format", RFC 2822
[SMIME-MSG] "S/MIME Version 3 Message Specification ", Internet Draft [SMIME-MSG] "S/MIME Version 3 Message Specification ", Internet Draft
draft-ietf-smime-msg draft-ietf-smime-msg
B. Informative References B. Informative References
[CERTV2] "S/MIME Version 2 Certificate Handling", RFC 2312 [CERTV2] "S/MIME Version 2 Certificate Handling", RFC 2312
[PKCS6] RSA Laboratories, "PKCS #6: Extended-Certificate Syntax
Standard", November 1993
[RC95] Rogier, N. and Chauvaud, P., "The compression function of MD2 [RC95] Rogier, N. and Chauvaud, P., "The compression function of MD2
is not collision free," Presented at Selected Areas in Cryptography is not collision free," Presented at Selected Areas in Cryptography
'95, May 1995 '95, May 1995
[SECLABEL] "Implementing Company Classification Policy with the S/MIME [SECLABEL] "Implementing Company Classification Policy with the S/MIME
Security Label", RFC 3114 Security Label", RFC 3114
[X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997, [X.500] ITU-T Recommendation X.500 (1997) | ISO/IEC 9594-1:1997,
Information technology - Open Systems Interconnection - The Directory: Information technology - Open Systems Interconnection - The Directory:
Overview of concepts, models and services Overview of concepts, models and services
 End of changes. 13 change blocks. 
26 lines changed or deleted 49 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/