draft-ietf-smime-cert-03.txt   draft-ietf-smime-cert-04.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-cert-03.txt Worldtalk draft-ietf-smime-cert-04.txt Worldtalk
March 24, 1998 May 4, 1998
Expires in six months Expires in six months
S/MIME Version 3 Certificate Handling S/MIME Version 3 Certificate Handling
Status of this memo Status of this memo
This document is an Internet-Draft. Internet-Drafts are working This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas, documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
To view the entire list of current Internet-Drafts, please check To view the entire list of current Internet-Drafts, please check the
the "1id-abstracts.txt" listing contained in the Internet-Drafts "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
(Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
(Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast).
(US West Coast).
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 certify that the public key is valid. S/MIME agents
MUST use X.509 certificates to validate public keys as described in MUST use X.509 certificates to validate public keys as described in
the ITU-T Recommendation X.509 (1997) [X.509] and the Internet Public the ITU-T Recommendation X.509 (1997) [X.509] and the Internet Public
Key Infrastructure (PKIX) X.509 Certificate and CRL Profile [KEYM]. Key Infrastructure (PKIX) X.509 Certificate and CRL Profile [KEYM].
skipping to change at line 54 skipping to change at line 53
1.1 Definitions 1.1 Definitions
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 a SEQUENCE OF 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
[X.509] [X.509]
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 ITU-T public key with a digital signature. This type is defined in ITU-T
X.509 [X.509]. This type also contains the distinguished name of the X.509 [X.509]. 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
skipping to change at line 123 skipping to change at line 122
Receiving agents MUST support for the Certificate Revocation List Receiving agents MUST support for the Certificate Revocation List
(CRL) format defined in [KEYM]. If sending agents include CRLs in (CRL) format defined in [KEYM]. If sending agents include CRLs in
outgoing messages, the CRL format defined in [KEYM] MUST be used. outgoing messages, the CRL format defined in [KEYM] MUST be used.
All agents MUST validate CRLs and check certificates against CRLs, if All agents MUST validate CRLs and check certificates against CRLs, if
available, in accordance with [KEYM]. available, in accordance with [KEYM].
Receiving agents MUST recognize CRLs in received S/MIME messages. Receiving agents MUST recognize CRLs in received S/MIME messages.
Clients MUST use revocation information included as a CRL in an S/MIME Agents MUST use revocation information included as a CRL in an S/MIME
message when verifying the signature and certificate path validity in message when verifying the signature and certificate path validity in
that message. Clients SHOULD store CRLs received in messages for use that message. Agents SHOULD store CRLs received in messages for use in
in processing later messages. processing later messages.
Clients MUST handle multiple valid Certificate Authority (CA) Agents MUST handle multiple valid Certificate 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.
2.2 CertificateChoices 2.2 CertificateChoices
Receiving agents MUST support X.509 v1 and X.509 v3 certificates. See Receiving agents MUST support X.509 v1 and X.509 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.1. in section 3.1.
skipping to change at line 181 skipping to change at line 180
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 SHOULD be able to handle an arbitrarily large number of certificates
and chains. and chains.
Clients MAY send CA certificates, that is, certificates that are self- Agents MAY send CA certificates, that is, certificates that are self-
signed and can be considered the "root" of other chains. Note that signed and can be considered the "root" of other chains. Note that
receiving agents SHOULD NOT simply trust any self-signed certificates receiving agents SHOULD NOT simply trust any self-signed certificates
as valid CAs, but SHOULD use some other mechanism to determine if this as valid CAs, but SHOULD use some other mechanism to determine if this
is a CA that should be trusted. is a CA that should be trusted.
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
but are not currently recommended. but are not currently recommended.
Receiving agents SHOULD support X.509 attribute certificates. At a Receiving agents SHOULD support the decoding of X.509 attribute
minimum, receiving agents SHOULD at least support the decoding of certificates included in CMS objects. All other issues regarding the
X.509 attribute certificates. Please note that there is no generation and use of X.509 attribute certificates are outside of the
requirement that the same CA create both the public key X.509
Certificate and X.509 attribute certificate(s) for a user. Each
organization's local policy will define how X.509 attribute
certificates are validated and used. The implications of performing
multiple certification path validations should be considered when
defining local policy. Exchanges between a subject and the CA dealing
with the generation of X.509 attribute certificates are outside the
scope of this specification. scope of this specification.
3. Distinguished Names in Certificates 3. Distinguished Names in Certificates
3.1 Using Distinguished Names for Internet Mail 3.1 Using Distinguished Names for Internet Mail
The format of an X.509 certificate includes fields for the subject
name and issuer name. The subject name identifies the owner of a
particular public key/private key pair while the issuer name is meant
to identify the entity that "certified" the subject (that is, who
signed the subject's certificate). The subject name and issuer name
are defined by X.509 as Distinguished Names.
Distinguished Names are defined by a ITU-T standard X.501 [X.501]. A
Distinguished Name is broken into one or more Relative Distinguished
Names. Each Relative Distinguished Name is comprised of one or more
Attribute-Value Assertions. Each Attribute-Value Assertion consists of
a Attribute Identifier and its corresponding value information, such
as CountryName=US. Distinguished Names were intended to identify
entities in the X.500 directory tree [X.500]. Each Relative
Distinguished Name can be thought of as a node in the tree which is
described by some collection of Attribute-Value Assertions. The entire
Distinguished Name is some collection of nodes in the tree that
traverse a path from the root of the tree to some end node which
represents a particular entity.
The goal of the directory was to provide an infrastructure to uniquely
name every communications entity everywhere. However, adoption of a
global X.500 directory infrastructure has been slower than expected.
Consequently, there is no requirement for X.500 directory service
provision in the S/MIME environment, although such provision would
almost undoubtedly be of great value in facilitating key management
for S/MIME.
The use of Distinguished Names in accordance with the X.500 directory
is not very widespread. By contrast, Internet mail addresses, as
described in RFC 822 [RFC-822], are used almost exclusively in the
Internet environment to identify originators and recipients of
messages. However, Internet mail addresses bear no resemblance to
X.500 Distinguished Names (except, perhaps, that they are both
hierarchical in nature). Some method is needed to map Internet mail
addresses to entities that hold public keys. Some people have
suggested that the X.509 certificate format should be abandoned in
favor of other binding mechanisms. Instead, S/MIME keeps the X.509
certificate and Distinguished Name mechanisms while tailoring the
content of the naming information to suit the Internet mail
environment.
End-entity certificates MAY contain an Internet mail address as End-entity certificates MAY contain an Internet mail address as
described in [RFC-822]. The address must be an "addr-spec" as defined described in [RFC-822]. The address must be an "addr-spec" as defined
in Section 6.1 of that specification. The email address SHOULD be in in Section 6.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 email addresses in the subjectAltName
field. Receiving agents MUST recognize email addresses in the field. Receiving agents MUST recognize email addresses in the
Distinguished Name field. Distinguished Name field.
skipping to change at line 281 skipping to change at line 231
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.
3.2 Required Name Attributes 3.2 Required Name Attributes
Receiving agents MUST support parsing of zero, one, or more instances Receiving agents MUST support parsing of zero, one, or more instances
of each of the following set of name attributes within the of each of the following set of name attributes within the
Distinguished Names in certificates. Distinguished Names in certificates.
Guidelines for the inclusion, omission, and ordering of name
attributes during the creation of a distinguished name will most
likely be dictated by the policies associated with the certification
service which will certify the corresponding name and public key.
countryName countryName
stateOrProvinceName stateOrProvinceName
localityName localityName
commonName commonName
title title
organizationName organizationName
organizationalUnitName organizationalUnitName
streetAddress streetAddress
postalCode postalCode
telephoneNumber telephoneNumber
emailAddress emailAddress
All attributes other than emailAddress are described in X.520 [X.520]. All attributes other than emailAddress are described in X.520 [X.520].
emailAddress is an IA5String that can have multiple attribute values. emailAddress is an IA5String that can have multiple attribute values.
Guidelines for the inclusion, omission, and ordering of name
attributes during the creation of a distinguished name will most
likely be dictated by the policies associated with the certification
service which will certify the corresponding name and public key.
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. The PKIX Working Group is
investigating other mechanisms. Another method under consideration by investigating other mechanisms. Another method under consideration by
the IETF is to provide certificate retrieval services as part of the the IETF is to provide certificate retrieval services as part of the
skipping to change at line 420 skipping to change at line 370
in [X.509]. in [X.509].
Sending and receiving agents MUST correctly handle the v3 Basic Sending and receiving agents MUST correctly handle the v3 Basic
Constraints Certificate Extension, the Key Usage Certificate Constraints Certificate Extension, the Key Usage Certificate
Extension, authorityKeyID, subjectKeyID, and the subjectAltNames when Extension, authorityKeyID, subjectKeyID, and the subjectAltNames when
they appear in end-user certificates. Some mechanism SHOULD exist to they appear in end-user certificates. Some mechanism SHOULD exist to
handle the defined v3 certificate extensions when they appear in handle the defined v3 certificate extensions when they appear in
intermediate or CA certificates. intermediate 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 other than those listed here. These extensions critical extensions (extensions that have the critical field set to
SHOULD be marked as non-critical unless the proper handling of the TRUE) other than those listed here. These extensions SHOULD be marked
extension is deemed critical to the correct interpretation of the as non-critical unless the proper handling of the extension is deemed
associated certificate. Other extensions may be included, but those critical to the correct interpretation of the associated certificate.
extensions SHOULD NOT be marked as critical. Other extensions may be included, but those extensions SHOULD NOT be
marked as critical.
Interpretation and syntax for all extensions MUST follow [KEYM],
unless otherwise specified here.
4.4.1 Basic Constraints Certificate Extension 4.4.1 Basic Constraints Certificate Extension
The basic constraints extension serves to delimit the role and The basic constraints extension serves to delimit the role and
position of an issuing authority or end-user certificate plays in a position of an issuing authority or end-entity certificate plays in a
chain of certificates. chain of certificates.
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-user subscriber certificates contain an extension certificates. End-entity certificates contain an extension that
that constrains the certificate from being an issuing authority constrains the certificate from being an issuing authority
certificate. certificate.
Certificates SHOULD contain a basicConstraints extension. Certificates SHOULD contain a basicConstraints extension.
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
restricts the key to signing certificates, certificate revocation restricts the key to signing certificates, certificate revocation
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 keyUsage extension which specifies that certificates which contain a keyUsage extension which specifies that
the corresponding public key can be used to sign end user certs and the corresponding public key can be used to sign end user certs and
sign CRLs. sign CRLs.
If a key usage extension is included in a v3 X.509 Certificate, then If a key usage extension is included in a v3 X.509 Certificate, then
it MUST be marked as critical. it MUST be marked as critical.
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), more
clarification is needed as to how to interpret the key usage
extension. 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-822 email address(es) that preferred means to convey the RFC-822 email address(es) that
correspond to the entity for this certificate. Any RFC-822 email correspond to the entity for this certificate. Any RFC-822 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-822 email addresses MAY be present. GeneralName, multiple RFC-822 email addresses MAY be present.
5. Security Considerations 5. Security Considerations
skipping to change at line 548 skipping to change at line 515
B. Acknowledgements B. Acknowledgements
This document is largely based on [CERTV2] written by Steve Dusse, This document is largely based on [CERTV2] written by Steve Dusse,
Paul Hoffman, Blake Ramsdell, and Jeff Weinstein. Paul Hoffman, Blake Ramsdell, and Jeff Weinstein.
Significant comments and additions were made by John Pawling and Jim Significant comments and additions were made by John Pawling and Jim
Schaad. Schaad.
C. Needed changes C. Needed changes
Names for chaining -- still no clear consensus
Key usage for signing / encrypting certificate explanation Key usage for signing / encrypting certificate explanation
4.4.3 -- do we need to further qualify the syntax for rfc822Name (no Attribute certificates -- keep 'em or pitch 'em?
wildcards or comments)? Delete DN jabber from 3.1?
We need a reference for attribute certificates Extensions -- do we make this list the "maximum allowable" instead of
the "minimum required"?
What is the criticality for the "minimum required" extensions?
Shouldn't 4.4.2.1 be in PKIX I?
D. Changes from last draft D. Changes from last draft
Revised section 1 (John Pawling) Changed "Status of this memo" paragraph to reflect new IETF text (Paul
Removed [PKCS-1] due to section 1 revisions (Blake Ramsdell) Hoffman)
Changed Certificate and Certificate Revocation List definitions to Added "S/MIME applications MUST follow [KEYM] for v3 attributes"
identify extensions and refer to [KEYM] (John Pawling) language.
Another MUST to MAY for email address in certificates, section 2.2 Cleaned up AC definition to be "one or more" instead of "SEQUENCE OF"
(John Pawling) (Bill Flanigan)
Added Attribute Certificates to 2.2.1 (Jim Schaad) Cleaned up use of "Agent" vs. use of "Client" (everyone is "Agent"
Changed language regarding "proposed" v3 extensions in 2.2.1 (Jim now) (Bill Flanigan)
Schaad / John Pawling) Reordered 3.2 a little bit (Bill Flanigan)
Reworded NULL-DN sentence in 3.1 to avoid confusion with ASN.1 NULL Added a little clarification about "critical" for certificate
(John Pawling) extensions (Bill Flanigan)
PKCS #7 to CMS in section 4 (John Pawling) Cleaned up some "end-entity" language in 4.4.1 (Bill Flanigan)
Section 4.2, revised language to support Diffie-Hellman (John Pawling) Added key usage clarification for DH certs in 4.4.2.1 (John Pawling)
Removed section A which was basically restating things in other drafts Yanked "DN jabber" from section 3.1 (Bill Flanigan)
(John Pawling) Changed 2.3 language regarding attribute certificates (John Pawling)
Section 2.1, removed language regarding nextUpdate field in CRL
(Elliott Ginsburg)
Wrote 4.4.3. Flames welcome. (Blake Ramsdell)
Fixed [CERTV2] to point to RFC 2312 (Blake Ramsdell)
Removed "old S/MIME" appendix (Jim Schaad, John Pawling, Paul Hoffman)
E. Editor's address E. Editor's address
Blake Ramsdell Blake Ramsdell
Worldtalk Worldtalk
13122 NE 20th St., Suite C 13122 NE 20th St., Suite C
Bellevue, WA 98005 Bellevue, WA 98005
(425) 882-8861 (425) 882-8861
blaker@deming.com blaker@deming.com
 End of changes. 

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