draft-ietf-smime-cert-06.txt   draft-ietf-smime-cert-07.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-cert-06.txt Worldtalk draft-ietf-smime-cert-07.txt Worldtalk
December 14, 1998 March 31, 1999
Expires in six months Expires September 30, 1999
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 and is in full conformance with all
documents of the Internet Engineering Task Force (IETF), its areas, provisions of Section 10 of RFC2026.
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts. Internet-Drafts are working documents of the Internet Engineering Task
Force (IETF), its areas, and its working groups. Note that other
groups may also distribute 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
or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
To view the entire list of current Internet-Drafts, please check the The list of current Internet-Drafts can be accessed at
"1id-abstracts.txt" listing contained in the Internet-Drafts Shadow http://www.ietf.org/ietf/1id-abstracts.txt
Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern Europe),
ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific Rim), The list of Internet-Draft Shadow Directories can be accessed at
ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 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 certify 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 S/MIME-specific Profile [KEYM]. S/MIME agents MUST meet the certificate processing
requirements documented in this I-D in addition to those stated in requirements documented in this document in addition to those stated
[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. Note that the method S/MIME messages make management supported by CMS.
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.
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.
skipping to change at line 123 skipping to change at line 124
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
Receiving agents MUST support for the Certificate Revocation List Receiving agents MUST support the Certificate Revocation List (CRL)
(CRL) format defined in [KEYM]. If sending agents include CRLs in format defined in [KEYM]. If sending agents include CRLs in outgoing
outgoing messages, the CRL format defined in [KEYM] MUST be used. messages, the CRL format defined in [KEYM] MUST be used.
All agents MUST validate CRLs and check certificates against CRLs, if
available, in accordance with [KEYM].
Receiving agents MUST recognize CRLs in received S/MIME messages. All agents MUST be capable of performing revocation checks using CRLs
as specified in [KEYM]. All agents MUST perform revocation status
checking in accordance with [KEYM]. Receiving agents MUST recognize
CRLs in received S/MIME messages.
Agents MUST use revocation information included as a CRL in an S/MIME Agents SHOULD store CRLs received in messages for use in processing
message when verifying the signature and certificate path validity in later messages.
that message. Agents SHOULD store CRLs received in messages for use in
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 PKIX v1 and PKIX 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
skipping to change at line 194 skipping to change at line 193
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.
Agents 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. Also note that in the case of DSA
certificates the parameters may be located in the root certificate.
This would require that the recipient possess the root certificate in
order to perform a signature verification, and is a valid example of a
case 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
but are not currently recommended. but are not currently recommended.
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. scope of this specification.
3. Distinguished Names in Certificates 3. Using Distinguished Names for Internet Mail
3.1 Using Distinguished Names for Internet Mail
End-entity certificates MAY contain an Internet mail address as End-entity certificates MAY contain an Internet mail address as
described in [RFC-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 in the PKCS #9 emailAddress attribute.
Sending agents SHOULD make the address in the From or Sender header in Sending agents SHOULD make the address in the From or Sender header in
a mail message match an Internet mail address in the signer's a mail message match an Internet mail address in the signer's
certificate. Receiving agents MUST check that the address in the From certificate. Receiving agents MUST check that the address in the From
or Sender header of a mail message matches an Internet mail address in or Sender header of a mail message matches an Internet mail address 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.
skipping to change at line 296 skipping to change at line 297
information every time a certificate is verified as part of a information every time a certificate is verified as part of a
certificate chain validation even if the certificate was already certificate chain validation even if the certificate was already
verified in the past. However, in many instances (such as off-line verified in the past. However, in many instances (such as off-line
verification) access to the latest CRL information may be difficult or verification) access to the latest CRL information may be difficult or
impossible. The use of CRL information, therefore, may be dictated by impossible. The use of CRL information, therefore, may be dictated by
the value of the information that is protected. The value of the CRL the value of the information that is protected. The value of the CRL
information in a particular context is beyond the scope of this draft information in a particular context is beyond the scope of this draft
but may be governed by the policies associated with particular but may be governed by the policies associated with particular
certificate hierarchies. certificate hierarchies.
All agents MUST be capable of performing revocation checks using CRLs
as specified in [KEYM]. All agents MUST perform revocation status
checking in accordance with [KEYM]. Receiving agents MUST recognize
CRLs in received S/MIME messages.
4.2 Certificate Chain Validation 4.2 Certificate Chain Validation
In creating a user agent for secure messaging, certificate, CRL, and In creating a user agent for secure messaging, certificate, CRL, and
certificate chain validation SHOULD be highly automated while still certificate chain validation SHOULD be highly automated while still
acting in the best interests of the user. Certificate, CRL, and chain acting in the best interests of the user. Certificate, CRL, and chain
validation MUST be performed as per [KEYM] when validating a validation MUST be performed as per [KEYM] when validating a
correspondent's public key. This is necessary before using a public correspondent's public key. This is necessary before using a public
key to provide security services such as: verifying a signature; key to provide security services such as: verifying a signature;
encrypting a content-encryption key (ex: RSA); or forming a pairwise encrypting a content-encryption key (ex: RSA); or forming a pairwise
symmetric key (ex: Diffie-Hellman) to be used to encrypt or decrypt a symmetric key (ex: Diffie-Hellman) to be used to encrypt or decrypt a
skipping to change at line 323 skipping to change at line 329
(although in most cases they will be related to the sender). Incoming (although in most cases they will be related to the sender). Incoming
certificates and CRLs SHOULD be cached for use in chain validation and certificates and CRLs SHOULD be cached for use in chain validation and
optionally stored for later use. This temporary certificate and CRL optionally stored for later use. This temporary certificate and CRL
cache SHOULD be used to augment any other certificate and CRL cache SHOULD be used to augment any other certificate and CRL
retrieval mechanisms for chain validation on incoming signed messages. retrieval mechanisms for chain validation on incoming signed messages.
4.3 Certificate and CRL Signing Algorithms 4.3 Certificate and CRL Signing Algorithms
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 [DSS].
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 [PKCS#1V2].
4.4 PKIX Certificate Extensions 4.4 PKIX Certificate Extensions
PKIX describes an extensible framework in which the basic certificate PKIX describes an extensible framework in which the basic certificate
information can be extended and how such extensions can be used to information can be extended and how such extensions can be used to
control the process of issuing and validating certificates. The PKIX control the process of issuing and validating certificates. The PKIX
Working Group has ongoing efforts to identify and create extensions Working Group has ongoing efforts to identify and create extensions
which have value in particular certification environments. As such, which have value in particular certification environments. Further,
there is there are active efforts underway to issue PKIX certificates for
still a fair amount of profiling work to be done before there is business purposes. This document identifies the minumum required set
widespread agreement on which extensions will be used. Further, there of certificate extensions which have the greatest value in the S/MIME
are active efforts underway to issue PKIX certificates for business environment. The syntax and semantics of all the identified extensions
purposes. This draft identifies the minumum required set of are defined in [KEYM].
certificate extensions which have the greatest value in the S/MIME
environment. The basicConstraints, and keyUsage extensions are defined
in [KEYM].
Sending and receiving agents MUST correctly handle the 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 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
skipping to change at line 376 skipping to change at line 379
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-entity 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-entity certificates contain an extension that certificates. End-entity certificates contain an extension 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 in CA
certificates, and SHOULD NOT contain that extension in end entity
certificates.
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 PKIX certificate, then it If a key usage extension is included in a PKIX certificate, then it
MUST be marked as critical. MUST be marked as critical.
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), if the keyUsage
clarification is needed as to how to interpret the key usage keyAgreement bit is set to 1 AND if the public key is to be used to
extension. If the keyUsage keyAgreement bit is set to 1 AND if the form a pairwise key to decrypt data, then the S/MIME agent MUST only
public key is to be used to form a pairwise key to decrypt data, then use the public key if the keyUsage encipherOnly bit is set to 0. If
the S/MIME agent MUST only use the public key if the keyUsage the keyUsage keyAgreement bit is set to 1 AND if the key is to be used
encipherOnly bit is set to 0. If the keyUsage keyAgreement bit is set to form a pairwise key to encrypt data, then the S/MIME agent MUST
to 1 AND if the key is to be used to form a pairwise key to encrypt only use the public key if the keyUsage decipherOnly bit is set to 0.
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.
skipping to change at line 458 skipping to change at line 461
check them all thoroughly, and to decide what to do if the check check them all thoroughly, and to decide what to do if the check
fails. fails.
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- [DSS] NIST FIPS PUB 186, "Digital Signature Standard", 18 May 1994.
pkix-crmf
[KEYM] "Internet X.509 Public Key Infrastructure 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
[PKCS#1V2], "PKCS #1: RSA Cryptography Specifications Version 2.0",
[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
[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
skipping to change at line 491 skipping to change at line 495
[X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997, [X.509] ITU-T Recommendation X.509 (1997) | ISO/IEC 9594-8:1997,
Information technology - Open Systems Interconnection - The Directory: Information technology - Open Systems Interconnection - The Directory:
Authentication framework Authentication framework
[X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997, [X.520] ITU-T Recommendation X.520 (1997) | ISO/IEC 9594-6:1997,
Information technology - Open Systems Interconnection - The Directory: Information technology - Open Systems Interconnection - The Directory:
Selected attribute types. Selected attribute types.
B. Acknowledgements B. Acknowledgements
This document is largely based on [CERTV2] written by Steve Dusse, <TBD>
Paul Hoffman, Blake Ramsdell, and Jeff Weinstein.
Significant comments and additions were made by John Pawling and Jim
Schaad.
C. Changes from last draft C. Changes from last draft
Removed section 3.2 (required name attributes) (WG Consensus) Changed "I-D" to "document" in section 1 (Russ Housley)
Added definitions for "agents" (Bill Flanigan, Paul Hoffman) Added clarification to section 3.1 regarding emailAddress attribute
from PKCS #9 (Russ Housley)
Redid 4.4.2.1 regarding Diffie-Hellman to clarify "doneness" (Russ
Housley)
Clarified 4.4 regarding certificate extensions and profiling efforts
(Russ Housley)
Clarified 2.3 regarding DSA parameters being scattered all over the
certificate chain, necessitating the transmission of the root
certificate (Jim Schaad)
Clarified 4.4.1 regarding basic constraints in end entity certificates
(Jim Schaad)
Changed an errant reference to [KEYM] to [SMIME-MSG] (Jim Schaad)
Removed certificate request language from section 1 (Jim Schaad)
Removed [CRMF] reference from section A (Jim Schaad)
Added reference to PKCS #1 v2 and DSS for signature algorithms in
section 4.3 (Jim Schaad)
Fixed some language in 4.4 regarding syntax and semantics of
extensions are defined in [KEYM] (Jim Schaad)
Changed back the errant reference to [KEYM] (John Pawling)
Promoted section 3.1 to section 3 (Paul Hoffman)
Added CRL processing clarification to 2.1 and 4.1 (WG Consensus "after
much exciting debate" initiated by Denis Pinkas)
D. 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/