draft-ietf-smime-cert-04.txt   draft-ietf-smime-cert-05.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-cert-04.txt Worldtalk draft-ietf-smime-cert-05.txt Worldtalk
May 4, 1998 August 6, 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.
skipping to change at line 32 skipping to change at line 32
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe), Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim),
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). ftp.ietf.org (US East Coast), or ftp.isi.edu (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 PKIX certificates to validate public keys as described in the
the ITU-T Recommendation X.509 (1997) [X.509] and the Internet Public Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL
Key Infrastructure (PKIX) X.509 Certificate and CRL Profile [KEYM]. Profile [KEYM]. S/MIME agents MUST meet the S/MIME-specific
S/MIME agents MUST meet the S/MIME-specific requirements documented in requirements documented in this I-D in addition to those stated in
this I-D in addition to those stated in [X.509] and [KEYM]. [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. Note that the method S/MIME messages make management supported by CMS. Note that the method S/MIME messages make
certificate requests is defined in [SMIME-MSG]. certificate requests is defined in [SMIME-MSG].
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.
skipping to change at line 60 skipping to change at line 60
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
[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 the
X.509 [X.509]. This type also contains the distinguished name of the Internet X.509 Public Key Infrastructure (PKIX) Certificate and CRL
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 as defined in [KEYM]. extensions also defined 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 133 skipping to change at line 134
message when verifying the signature and certificate path validity in message when verifying the signature and certificate path validity in
that message. Agents SHOULD store CRLs received in messages for use in that message. Agents SHOULD store CRLs received in messages for use in
processing later messages. processing later messages.
Agents 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 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.1. in section 3.1.
Receiving agents SHOULD support X.509 attribute certificates. Receiving agents SHOULD support X.509 attribute 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: X.509, PKCS #6 Extended Certificates and public key content types: PKIX, PKCS #6 Extended Certificates and
X.509 Attribute Certificates. The PKCS #6 format is not in widespread X.509 Attribute Certificates. The PKCS #6 format is not in widespread
use. In addition, X.509 v3 certificate extensions address much of the use. In addition, PKIX certificate extensions address much of the same
same functionality and flexibility as was intended in the PKCS #6. functionality and flexibility as was intended in the PKCS #6. Thus,
Thus, sending and receiving agents MUST NOT use PKCS #6 extended sending and receiving agents MUST NOT use PKCS #6 extended
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,
situations where the certificates in a signed message may be unrelated situations where the certificates in a signed message may be unrelated
skipping to change at line 220 skipping to change at line 221
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 in
the signer's certificate, if mail addresses are present in the the signer's certificate, if mail addresses are present in the
certificate. A receiving agent SHOULD provide some explicit alternate certificate. A receiving agent SHOULD provide some explicit alternate
processing of the message if this comparison fails, which may be to processing of the message if this comparison fails, which may be to
display a message that shows the recipient the addresses in the display a message that shows the recipient the addresses in the
certificate or other certificate details. certificate or other certificate details.
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 v3 X.509 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.
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.
skipping to change at line 346 skipping to change at line 347
Certificates and Certificate-Revocation Lists (CRLs) are signed by the Certificates and Certificate-Revocation Lists (CRLs) are signed by the
certificate issuer. A receiving agent MUST be capable of verifying the certificate issuer. A receiving agent MUST be capable of verifying the
signatures on certificates and CRLs made with id-dsa-with-sha1. signatures on certificates and CRLs made with id-dsa-with-sha1.
A receiving agent SHOULD be capable of verifying the signatures on A receiving agent SHOULD be capable of verifying the signatures on
certificates and CRLs made with md2WithRSAEncryption, certificates and CRLs made with md2WithRSAEncryption,
md5WithRSAEncryption and sha-1WithRSAEncryption signature algorithms md5WithRSAEncryption and sha-1WithRSAEncryption signature algorithms
with key sizes from 512 bits to 2048 bits described in [SMIME-MSG]. with key sizes from 512 bits to 2048 bits described in [SMIME-MSG].
4.4 X.509 Version 3 Certificate Extensions 4.4 PKIX Certificate Extensions
The X.509 v3 standard describes an extensible framework in which the PKIX describes an extensible framework in which the basic certificate
basic certificate information can be extended and how such extensions information can be extended and how such extensions can be used to
can be used to control the process of issuing and validating control the process of issuing and validating certificates. The PKIX
certificates. The PKIX Working Group has ongoing efforts to identify Working Group has ongoing efforts to identify and create extensions
and create extensions which have value in particular certification which have value in particular certification environments. As such,
environments. As such, there is there is
still a fair amount of profiling work to be done before there is still a fair amount of profiling work to be done before there is
widespread agreement on which v3 extensions will be used. Further, widespread agreement on which extensions will be used. Further, there
there are active efforts underway to issue X.509 v3 certificates for are active efforts underway to issue PKIX certificates for business
business purposes. This draft identifies the minumum required set of purposes. This draft identifies the minumum required set of
certificate extensions which have the greatest value in the S/MIME certificate extensions which have the greatest value in the S/MIME
environment. The basicConstraints, and keyUsage extensions are defined environment. The basicConstraints, and keyUsage extensions are defined
in [X.509]. in [KEYM].
Sending and receiving agents MUST correctly handle the v3 Basic Sending and receiving agents MUST correctly handle the 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 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 (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.
skipping to change at line 407 skipping to change at line 408
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 PKIX certificate, then it
it MUST be marked as critical. MUST be marked as critical.
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), more the subject public key algorithm is dhpublicnumber), more
clarification is needed as to how to interpret the key usage clarification is needed as to how to interpret the key usage
extension. If the keyUsage keyAgreement bit is set to 1 AND if the 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 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 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 encipherOnly bit is set to 0. If the keyUsage keyAgreement bit is set
skipping to change at line 477 skipping to change at line 478
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 draft-housley- [CMS] "Cryptographic Message Syntax", Internet Draft draft-housley-
smime-cms smime-cms
[CRMF] "Certificate Request Message Format", Internet Draft draft-ietf- [CRMF] "Certificate Request Message Format", Internet Draft draft-ietf-
pkix-crmf pkix-crmf
[KEYM] "Internet Public Key Infrastructure X.509 Certificate and CRL [KEYM] "Internet X.509 Public Key Infrastructure Certificate and CRL
Profile", Internet-Draft draft-ietf-pkix-ipki-part1 Profile", Internet-Draft draft-ietf-pkix-ipki-part1
[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
[RFC-822], "Standard For The Format Of ARPA Internet Text Messages", [RFC-822], "Standard For The Format Of ARPA Internet Text Messages",
RFC 822. RFC 822.
[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
skipping to change at line 513 skipping to change at line 514
Selected attribute types. Selected attribute types.
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. Changes from last draft
Key usage for signing / encrypting certificate explanation
Attribute certificates -- keep 'em or pitch 'em?
Delete DN jabber from 3.1?
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
Changed "Status of this memo" paragraph to reflect new IETF text (Paul Whammed out X.509 references in favor of PKIX references (Denis
Hoffman) Pinkas)
Added "S/MIME applications MUST follow [KEYM] for v3 attributes"
language.
Cleaned up AC definition to be "one or more" instead of "SEQUENCE OF"
(Bill Flanigan)
Cleaned up use of "Agent" vs. use of "Client" (everyone is "Agent"
now) (Bill Flanigan)
Reordered 3.2 a little bit (Bill Flanigan)
Added a little clarification about "critical" for certificate
extensions (Bill Flanigan)
Cleaned up some "end-entity" language in 4.4.1 (Bill Flanigan)
Added key usage clarification for DH certs in 4.4.2.1 (John Pawling)
Yanked "DN jabber" from section 3.1 (Bill Flanigan)
Changed 2.3 language regarding attribute certificates (John Pawling)
E. Editor's address D. 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/