rfc2312.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 1,124 行 · 第 1/3 页

Network Working Group                                           S. Dusse
Request for Comments: 2312                             RSA Data Security
Category: Informational                                       P. Hoffman
                                                Internet Mail Consortium
                                                             B. Ramsdell
                                                               Worldtalk
                                                            J. Weinstein
                                                                Netscape
                                                              March 1998


                 S/MIME Version 2 Certificate Handling

Status of this Memo

   This memo provides information for the Internet community.  It does
   not specify an Internet standard of any kind.  Distribution of this
   memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (1998).  All Rights Reserved.

1. Overview

   S/MIME (Secure/Multipurpose Internet Mail Extensions), described in
   [SMIME-MSG], provides a method to send and receive secure MIME
   messages. In order to validate the keys of a message sent to it, an
   S/MIME agent needs to certify that the key is valid. This memo
   describes the mechanisms S/MIME uses to create and validate keys
   using certificates.

   This specification is compatible with PKCS #7 in that it uses the
   data types defined by PKCS #7. It also inherits all the varieties of
   architectures for certificate-based key management supported by PKCS
   #7.  Note that the method S/MIME messages make certificate requests
   is defined in [SMIME-MSG].

   In order to handle S/MIME certificates, an agent has to follow
   specifications in this memo, as well as some of the specifications
   listed in the following documents:

    - "PKCS #1: RSA Encryption", [PKCS-1].
    - "PKCS #7: Cryptographic Message Syntax", [PKCS-7]
    - "PKCS #10: Certification Request Syntax", [PKCS-10].






Dusse, et. al.               Informational                      [Page 1]

RFC 2312        S/MIME Version 2 Certificate Handling         March 1998


   Please note: The information in this document is historical material
   being published for the public record. It is not an IETF standard.
   The use of the word "standard" in this document indicates a standard
   for adopters of S/MIME version 2, not an IETF standard.

1.1 Definitions

   For the purposes of this memo, the following definitions apply.

   ASN.1: Abstract Syntax Notation One, as defined in CCITT X.208.

   BER: Basic Encoding Rules for ASN.1, as defined in CCITT X.209.

   Certificate: A type that binds an entity's distinguished name to a
   public key with a digital signature. This type is defined in CCITT
   X.509 [X.509].  This type also contains the distinguished name of the
   certificate issuer (the signer), an issuer-specific serial number,
   the issuer's signature algorithm identifier, and a validity period.

   Certificate Revocation List (CRL): A type that contains information
   about certificates whose validity an issuer has prematurely revoked.
   The information consists of an issuer name, the time of issue, the
   next scheduled time of issue, and a list of certificate serial
   numbers and their associated revocation times. The CRL is signed by
   the issuer. The type intended by this specification is the one
   defined in [KEYM].

   DER: Distinguished Encoding Rules for ASN.1, as defined in CCITT
   X.509.

1.2 Compatibility with Prior Practice of S/MIME

   Appendix C contains important information about how S/MIME agents
   following this specification should act in order to have the greatest
   interoperability with earlier implementations of S/MIME.

1.3 Terminology

   Throughout this memo, the terms MUST, MUST NOT, SHOULD, and SHOULD
   NOT are used in capital letters. This conforms to the definitions in
   [MUSTSHOULD].  [MUSTSHOULD] defines the use of these key words to
   help make the intent of standards track documents as clear as
   possible. The same key words are used in this document to help
   implementors achieve interoperability.







Dusse, et. al.               Informational                      [Page 2]

RFC 2312        S/MIME Version 2 Certificate Handling         March 1998


2. PKCS #7 Options

   The PKCS #7 message format allows for a wide variety of options in
   content and algorithm support. This section puts forth a number of
   support requirements and recommendations in order to achieve a base
   level of interoperability among all S/MIME implementations. Most of
   the PKCS #7 format for S/MIME messages is defined in [SMIME-MSG].

2.1 CertificateRevocationLists

   Receiving agents MUST support for the Certificate Revocation List
   (CRL) format defined in [KEYM]. If sending agents include CRLs in
   outgoing 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]. All agents SHOULD check the
   nextUpdate field in the CRL against the current time. If the current
   time is later than the nextUpdate time, the action that the agent
   takes is a local decision. For instance, it could warn a human user,
   it could retrieve a new CRL if able, and so on.

   Receiving agents MUST recognize CRLs in received S/MIME messages.

   Clients MUST use revocation information included as a CRL in an
   S/MIME message when verifying the signature and certificate path
   validity in that message.  Clients SHOULD store CRLs received in
   messages for use in processing later messages.

   Clients MUST handle multiple valid Certificate Authority (CA)
   certificates containing the same subject name and the same public
   keys but with overlapping validity intervals.

2.2 ExtendedCertificateOrCertificate

   Receiving agents MUST support X.509 v1 and X.509 v3 certificates. See
   [KEYM] for details about the profile for certificate formats. End
   entity certificates MUST include an Internet mail address, as
   described in section 3.1.

2.2.1 Historical Note About PKCS #7 Certificates

   The PKCS #7 message format supports a choice of certificate two
   formats for public key content types: X.509 and PKCS #6 Extended
   Certificates. The PKCS #6 format is not in widespread use. In
   addition, proposed revisions of X.509 certificates address much of
   the same functionality and flexibility as was intended in the PKCS
   #6. Thus, sending and receiving agents MUST NOT use PKCS #6 extended
   certificates.



Dusse, et. al.               Informational                      [Page 3]

RFC 2312        S/MIME Version 2 Certificate Handling         March 1998


2.3 ExtendedCertificateAndCertificates

   Receiving agents MUST be able to handle an arbitrary number of
   certificates of arbitrary relationship to the message sender and to
   each other in arbitrary order. In many cases, the certificates
   included in a signed message may represent a chain of certification
   from the sender to a particular root. There may be, however,
   situations where the certificates in a signed message may be
   unrelated and included for convenience.

   Sending agents SHOULD include any certificates for the user's public
   key(s) and associated issuer certificates. This increases the
   likelihood that the intended recipient can establish trust in the
   originator's public key(s).  This is especially important when
   sending a message to recipients that may not have access to the
   sender's public key through any other means or when sending a signed
   message to a new recipient. The inclusion of certificates in outgoing
   messages can be omitted if S/MIME objects are sent within a group of
   correspondents that has established access to each other's
   certificates by some other means such as a shared directory or manual
   certificate distribution. Receiving S/MIME agents SHOULD be able to
   handle messages without certificates using a database or directory
   lookup scheme.

   A sending agent SHOULD include at least one chain of certificates up
   to, but not including, a Certificate Authority (CA) that it believes
   that the recipient may trust as authoritative. A receiving agent
   SHOULD be able to handle an arbitrarily large number of certificates
   and chains.

   Clients MAY send CA certificates, that is, certificates that are
   self-signed and can be considered the "root" of other chains. Note
   that receiving agents SHOULD NOT simply trust any self-signed
   certificates as valid CAs, but SHOULD use some other mechanism to
   determine if this is a CA that should be trusted.

   Receiving agents MUST support chaining based on the distinguished
   name fields. Other methods of building certificate chains may be
   supported but are not currently recommended.












Dusse, et. al.               Informational                      [Page 4]

RFC 2312        S/MIME Version 2 Certificate Handling         March 1998


3. Distinguished Names in Certificates

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 CCITT 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











Dusse, et. al.               Informational                      [Page 5]

RFC 2312        S/MIME Version 2 Certificate Handling         March 1998


   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 MUST contain an Internet mail address as
   described in [RFC-822]. The address must be an "addr-spec" as defined
   in Section 6.1 of that specification.

   Receiving agents MUST recognize email addresses in the subjectAltName
   field. Receiving agents MUST recognize email addresses in the
   Distinguished Name field.

   Sending agents SHOULD make the address in the From header in a mail
   message match an Internet mail address in the signer's certificate.
   Receiving agents MUST check that the address in the From header of a
   mail message matches an Internet mail address in the signer's
   certificate. A receiving agent MUST provide some explicit alternate
   processing of the message if this comparison fails, which may be to
   reject the message.

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.

   Sending agents MUST include the Internet mail address during
   Distinguished Name creation. Guidelines for the inclusion, omission,
   and ordering of the remaining 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
   StateOrProvinceName
   Locality
   CommonName
   Title
   Organization
   OrganizationalUnit
   StreetAddress
   PostalCode
   PhoneNumber
   EmailAddress





Dusse, et. al.               Informational                      [Page 6]

RFC 2312        S/MIME Version 2 Certificate Handling         March 1998


   All attributes other than EmailAddress are described in X.520
   [X.520].  EmailAddress is an IA5String that can have multiple
   attribute values.

4. Certificate Processing

   A receiving agent needs to provide some certificate retrieval
   mechanism in order to gain access to certificates for recipients of
   digital envelopes.  There are many ways to implement certificate
   retrieval mechanisms. X.500 directory service is an excellent example
   of a certificate retrieval-only mechanism that is compatible with
   classic X.500 Distinguished Names. The PKIX Working Group is
   investigating other mechanisms. Another method under consideration by
   the IETF is to provide certificate retrieval services as part of the
   existing Domain Name System (DNS). Until such mechanisms are widely
   used, their utility may be limited by the small number of
   correspondent's certificates that can be retrieved. At a minimum, for
   initial S/MIME deployment, a user agent could automatically generate
   a message to an intended recipient requesting that recipient's
   certificate in a signed return message.

   Receiving and sending agents SHOULD also provide a mechanism to allow
   a user to "store and protect" certificates for correspondents in such
   a way so as to guarantee their later retrieval. In many environments,
   it may be desirable to link the certificate retrieval/storage
   mechanisms together in some sort of certificate database. In its
   simplest form, a certificate database would be local to a particular
   user and would function in a similar way as a "address book" that
   stores a user's frequent correspondents. In this way, the certificate
   retrieval mechanism would be limited to the certificates that a user
   has stored (presumably from incoming messages).  A comprehensive
   certificate retrieval/storage solution may combine two or more
   mechanisms to allow the greatest flexibility and utility to the user.