draft-ietf-smime-cert-05.txt   draft-ietf-smime-cert-06.txt 
Internet Draft Editor: Blake Ramsdell, Internet Draft Editor: Blake Ramsdell,
draft-ietf-smime-cert-05.txt Worldtalk draft-ietf-smime-cert-06.txt Worldtalk
August 6, 1998 December 14, 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 78 skipping to change at line 78
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
X.690. X.690.
Receiving agent: software that interprets and processes S/MIME CMS
objects, MIME body parts that contain CMS objects, or both.
Sending agent: software that creates S/MIME CMS objects, MIME body
parts that contain CMS objects, or both.
S/MIME agent: user software that is a receiving agent, a sending
agent, or both.
1.2 Compatibility with Prior Practice of S/MIME 1.2 Compatibility with Prior Practice of S/MIME
S/MIME version 3 agents should attempt to have the greatest S/MIME version 3 agents should attempt to have the greatest
interoperability possible with S/MIME version 2 agents. S/MIME version interoperability possible with S/MIME version 2 agents. S/MIME version
2 is described in RFC 2311 through RFC 2315, inclusive. RFC 2311 also 2 is described in RFC 2311 through RFC 2315, inclusive. RFC 2311 also
has historical information about the development of S/MIME. has historical information about the development of S/MIME.
1.3 Terminology 1.3 Terminology
Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD Throughout this draft, the terms MUST, MUST NOT, SHOULD, and SHOULD
skipping to change at line 226 skipping to change at line 235
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 PKIX 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
Receiving agents MUST support parsing of zero, one, or more instances
of each of the following set of name attributes within the
Distinguished Names in certificates.
countryName
stateOrProvinceName
localityName
commonName
title
organizationName
organizationalUnitName
streetAddress
postalCode
telephoneNumber
emailAddress
All attributes other than emailAddress are described in X.520 [X.520].
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 such as directory servers. Another
the IETF is to provide certificate retrieval services as part of the method under consideration by the IETF is to provide certificate
existing Domain Name System (DNS). Until such mechanisms are widely retrieval services as part of the existing Domain Name System (DNS).
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 293 skipping to change at line 276
certificate if it can not be found in a user's local certificate certificate if it can not be found in a user's local certificate
storage/retrieval database. storage/retrieval 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].
4.1 Certificate Revocation Lists 4.1 Certificate Revocation Lists
A receiving agent SHOULD have access to some certificate-revocation In general, it is always better to get the latest CRL information from
list (CRL) retrieval mechanism in order to gain access to certificate- a CA than to get information stored away from incoming messages. A
receiving agent SHOULD have access to some certificate-revocation list
(CRL) retrieval mechanism in order to gain access to certificate-
revocation information when validating certificate chains. A receiving revocation information when validating certificate chains. A receiving
or sending agent SHOULD also provide a mechanism to allow a user to or sending agent SHOULD also provide a mechanism to allow a user to
store incoming certificate-revocation information for correspondents store incoming certificate-revocation information for correspondents
in such a way so as to guarantee its later retrieval. However, it is in such a way so as to guarantee its later retrieval.
always better to get the latest information from the CA than to get
information stored away from incoming messages.
Receiving and sending agents SHOULD retrieve and utilize CRL Receiving and sending agents SHOULD retrieve and utilize CRL
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
skipping to change at line 516 skipping to change at line 499
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. Changes from last draft C. Changes from last draft
Whammed out X.509 references in favor of PKIX references (Denis Removed section 3.2 (required name attributes) (WG Consensus)
Pinkas) Added definitions for "agents" (Bill Flanigan, Paul Hoffman)
D. Editor's address D. Editors 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/