rfc3280.txt

RFC 的详细文档！

Housley, et. al.            Standards Track                    [Page 10]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


      (a)  a pure top-down hierarchy, with all certification paths
      starting from IPRA;

      (b)  a naming subordination rule restricting the names of a CA's
      subjects; and

      (c)  use of the PCA concept, which requires knowledge of
      individual PCAs to be built into certificate chain verification
      logic.  Knowledge of individual PCAs was required to determine if
      a chain could be accepted.

   With X.509 v3, most of the requirements addressed by RFC 1422 can be
   addressed using certificate extensions, without a need to restrict
   the CA structures used.  In particular, the certificate extensions
   relating to certificate policies obviate the need for PCAs and the
   constraint extensions obviate the need for the name subordination
   rule.  As a result, this document supports a more flexible
   architecture, including:

      (a)  Certification paths start with a public key of a CA in a
      user's own domain, or with the public key of the top of a
      hierarchy.  Starting with the public key of a CA in a user's own
      domain has certain advantages.  In some environments, the local
      domain is the most trusted.

      (b)  Name constraints may be imposed through explicit inclusion of
      a name constraints extension in a certificate, but are not
      required.

      (c)  Policy extensions and policy mappings replace the PCA
      concept, which permits a greater degree of automation.  The
      application can determine if the certification path is acceptable
      based on the contents of the certificates instead of a priori
      knowledge of PCAs.  This permits automation of certification path
      processing.

3.3  Revocation

   When a certificate is issued, it is expected to be in use for its
   entire validity period.  However, various circumstances may cause a
   certificate to become invalid prior to the expiration of the validity
   period.  Such circumstances include change of name, change of
   association between subject and CA (e.g., an employee terminates
   employment with an organization), and compromise or suspected
   compromise of the corresponding private key.  Under such
   circumstances, the CA needs to revoke the certificate.





Housley, et. al.            Standards Track                    [Page 11]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


   X.509 defines one method of certificate revocation.  This method
   involves each CA periodically issuing a signed data structure called
   a certificate revocation list (CRL).  A CRL is a time stamped list
   identifying revoked certificates which is signed by a CA or CRL
   issuer and made freely available in a public repository.  Each
   revoked certificate is identified in a CRL by its certificate serial
   number.  When a certificate-using system uses a certificate (e.g.,
   for verifying a remote user's digital signature), that system not
   only checks the certificate signature and validity but also acquires
   a suitably-recent CRL and checks that the certificate serial number
   is not on that CRL.  The meaning of "suitably-recent" may vary with
   local policy, but it usually means the most recently-issued CRL.  A
   new CRL is issued on a regular periodic basis (e.g., hourly, daily,
   or weekly).  An entry is added to the CRL as part of the next update
   following notification of revocation.  An entry MUST NOT be removed
   from the CRL until it appears on one regularly scheduled CRL issued
   beyond the revoked certificate's validity period.

   An advantage of this revocation method is that CRLs may be
   distributed by exactly the same means as certificates themselves,
   namely, via untrusted servers and untrusted communications.

   One limitation of the CRL revocation method, using untrusted
   communications and servers, is that the time granularity of
   revocation is limited to the CRL issue period.  For example, if a
   revocation is reported now, that revocation will not be reliably
   notified to certificate-using systems until all currently issued CRLs
   are updated -- this may be up to one hour, one day, or one week
   depending on the frequency that CRLs are issued.

   As with the X.509 v3 certificate format, in order to facilitate
   interoperable implementations from multiple vendors, the X.509 v2 CRL
   format needs to be profiled for Internet use.  It is one goal of this
   document to specify that profile.  However, this profile does not
   require the issuance of CRLs.  Message formats and protocols
   supporting on-line revocation notification are defined in other PKIX
   specifications.  On-line methods of revocation notification may be
   applicable in some environments as an alternative to the X.509 CRL.
   On-line revocation checking may significantly reduce the latency
   between a revocation report and the distribution of the information
   to relying parties.  Once the CA accepts a revocation report as
   authentic and valid, any query to the on-line service will correctly
   reflect the certificate validation impacts of the revocation.
   However, these methods impose new security requirements: the
   certificate validator needs to trust the on-line validation service
   while the repository does not need to be trusted.





Housley, et. al.            Standards Track                    [Page 12]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


3.4  Operational Protocols

   Operational protocols are required to deliver certificates and CRLs
   (or status information) to certificate using client systems.
   Provisions are needed for a variety of different means of certificate
   and CRL delivery, including distribution procedures based on LDAP,
   HTTP, FTP, and X.500.  Operational protocols supporting these
   functions are defined in other PKIX specifications.  These
   specifications may include definitions of message formats and
   procedures for supporting all of the above operational environments,
   including definitions of or references to appropriate MIME content
   types.

3.5  Management Protocols

   Management protocols are required to support on-line interactions
   between PKI user and management entities.  For example, a management
   protocol might be used between a CA and a client system with which a
   key pair is associated, or between two CAs which cross-certify each
   other.  The set of functions which potentially need to be supported
   by management protocols include:

      (a)  registration:  This is the process whereby a user first makes
      itself known to a CA (directly, or through an RA), prior to that
      CA issuing  a certificate or certificates for that user.

      (b)  initialization:  Before a client system can operate securely
      it is necessary to install key materials which have the
      appropriate relationship with keys stored elsewhere in the
      infrastructure.  For example, the client needs to be securely
      initialized with the public key and other assured information of
      the trusted CA(s), to be used in validating certificate paths.

      Furthermore, a client typically needs to be initialized with its
      own key pair(s).

      (c)  certification:  This is the process in which a CA issues a
      certificate for a user's public key, and returns that certificate
      to the user's client system and/or posts that certificate in a
      repository.

      (d)  key pair recovery:  As an option, user client key materials
      (e.g., a user's private key used for encryption purposes) may be
      backed up by a CA or a key backup system.  If a user needs to
      recover these backed up key materials (e.g., as a result of a
      forgotten password or a lost key chain file), an on-line protocol
      exchange may be needed to support such recovery.




Housley, et. al.            Standards Track                    [Page 13]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


      (e)  key pair update:  All key pairs need to be updated regularly,
      i.e., replaced with a new key pair, and new certificates issued.

      (f)  revocation request:  An authorized person advises a CA of an
      abnormal situation requiring certificate revocation.

      (g)  cross-certification:  Two CAs exchange information used in
      establishing a cross-certificate.  A cross-certificate is a
      certificate issued by one CA to another CA which contains a CA
      signature key used for issuing certificates.

   Note that on-line protocols are not the only way of implementing the
   above functions.  For all functions there are off-line methods of
   achieving the same result, and this specification does not mandate
   use of on-line protocols.  For example, when hardware tokens are
   used, many of the functions may be achieved as part of the physical
   token delivery.  Furthermore, some of the above functions may be
   combined into one protocol exchange.  In particular, two or more of
   the registration, initialization, and certification functions can be
   combined into one protocol exchange.

   The PKIX series of specifications defines a set of standard message
   formats supporting the above functions.  The protocols for conveying
   these messages in different environments (e.g., e-mail, file
   transfer, and WWW) are described in those specifications.

4  Certificate and Certificate Extensions Profile

   This section presents a profile for public key certificates that will
   foster interoperability and a reusable PKI.  This section is based
   upon the X.509 v3 certificate format and the standard certificate
   extensions defined in [X.509].  The ISO/IEC and ITU-T documents use
   the 1997 version of ASN.1; while this document uses the 1988 ASN.1
   syntax, the encoded certificate and standard extensions are
   equivalent.  This section also defines private extensions required to
   support a PKI for the Internet community.

   Certificates may be used in a wide range of applications and
   environments covering a broad spectrum of interoperability goals and
   a broader spectrum of operational and assurance requirements.  The
   goal of this document is to establish a common baseline for generic
   applications requiring broad interoperability and limited special
   purpose requirements.  In particular, the emphasis will be on
   supporting the use of X.509 v3 certificates for informal Internet
   electronic mail, IPsec, and WWW applications.






Housley, et. al.            Standards Track                    [Page 14]

RFC 3280        Internet X.509 Public Key Infrastructure      April 2002


4.1  Basic Certificate Fields

   The X.509 v3 certificate basic syntax is as follows.  For signature
   calculation, the data that is to be signed is encoded using the ASN.1
   distinguished encoding rules (DER) [X.690].  ASN.1 DER encoding is a
   tag, length, value encoding system for each element.

   Certificate  ::=  SEQUENCE  {
        tbsCertificate       TBSCertificate,
        signatureAlgorithm   AlgorithmIdentifier,
        signatureValue       BIT STRING  }

   TBSCertificate  ::=  SEQUENCE  {
        version         [0]  EXPLICIT Version DEFAULT v1,
        serialNumber         CertificateSerialNumber,
        signature            AlgorithmIdentifier,
        issuer               Name,
        validity             Validity,
        subject              Name,
        subjectPublicKeyInfo SubjectPublicKeyInfo,
        issuerUniqueID  [1]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        subjectUniqueID [2]  IMPLICIT UniqueIdentifier OPTIONAL,
                             -- If present, version MUST be v2 or v3
        extensions      [3]  EXPLICIT Extensions OPTIONAL
                             -- If present, version MUST be v3
        }

   Version  ::=  INTEGER  {  v1(0), v2(1), v3(2)  }

   CertificateSerialNumber  ::=  INTEGER

   Validity ::= SEQUENCE {
        notBefore      Time,
        notAfter       Time }

   Time ::= CHOICE {
        utcTime        UTCTime,
        generalTime    GeneralizedTime }

   UniqueIdentifier  ::=  BIT STRING

   SubjectPublicKeyInfo  ::=  SEQUENCE  {
        algorithm            AlgorithmIdentifier,
        subjectPublicKey     BIT STRING  }

   Extensions  ::=  SEQUENCE SIZE (1..MAX) OF Extension