rfc2560.txt

PKIX的RFC英文文档

Network Working Group                                           M. Myers
Request for Comments: 2560                                      VeriSign
Category: Standards Track                                      R. Ankney
                                                                  CertCo
                                                              A. Malpani
                                                                ValiCert
                                                             S. Galperin
                                                                  My CFO
                                                                C. Adams
                                                    Entrust Technologies
                                                               June 1999


                X.509 Internet Public Key Infrastructure
               Online Certificate Status Protocol - OCSP

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Copyright Notice

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

1.  Abstract

   This document specifies a protocol useful in determining the current
   status of a digital certificate without requiring CRLs. Additional
   mechanisms addressing PKIX operational requirements are specified in
   separate documents.

   An overview of the protocol is provided in section 2. Functional
   requirements are specified in section 4. Details of the protocol are
   in section 5. We cover security issues with the protocol in section
   6. Appendix A defines OCSP over HTTP, appendix B accumulates ASN.1
   syntactic elements and appendix C specifies the mime types for the
   messages.

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document (in uppercase, as shown) are to be interpreted as described
   in [RFC2119].





Myers, et al.               Standards Track                     [Page 1]

RFC 2560                       PKIX OCSP                       June 1999


2.  Protocol Overview

   In lieu of or as a supplement to checking against a periodic CRL, it
   may be necessary to obtain timely information regarding the
   revocation status of a certificate (cf. [RFC2459], Section 3.3).
   Examples include high-value funds transfer or large stock trades.

   The Online Certificate Status Protocol (OCSP) enables applications to
   determine the (revocation) state of an identified certificate. OCSP
   may be used to satisfy some of the operational requirements of
   providing more timely revocation information than is possible with
   CRLs and may also be used to obtain additional status information. An
   OCSP client issues a status request to an OCSP responder and suspends
   acceptance of the certificate in question until the responder
   provides a response.

   This protocol specifies the data that needs to be exchanged between
   an application checking the status of a certificate and the server
   providing that status.

2.1  Request

   An OCSP request contains the following data:

   -- protocol version
   -- service request
   -- target certificate identifier
   -- optional extensions which MAY be processed by the OCSP Responder

   Upon receipt of a request, an OCSP Responder determines if:

   1. the message is well formed

   2. the responder is configured to provide the requested service and

   3. the request contains the information needed by the responder If
   any one of the prior conditions are not met, the OCSP responder
   produces an error message; otherwise, it returns a definitive
   response.

2.2  Response

   OCSP responses can be of various types.  An OCSP response consists of
   a response type and the bytes of the actual response. There is one
   basic type of OCSP response that MUST be supported by all OCSP
   servers and clients. The rest of this section pertains only to this
   basic response type.




Myers, et al.               Standards Track                     [Page 2]

RFC 2560                       PKIX OCSP                       June 1999


   All definitive response messages SHALL be digitally signed. The key
   used to sign the response MUST belong to one of the following:

   -- the CA who issued the certificate in question
   -- a Trusted Responder whose public key is trusted by the requester
   -- a CA Designated Responder (Authorized Responder) who holds a
      specially marked certificate issued directly by the CA, indicating
      that the responder may issue OCSP responses for that CA

   A definitive response message is composed of:

   -- version of the response syntax
   -- name of the responder
   -- responses for each of the certificates in a request
   -- optional extensions
   -- signature algorithm OID
   -- signature computed across hash of the response

   The response for each of the certificates in a request consists of

   -- target certificate identifier
   -- certificate status value
   -- response validity interval
   -- optional extensions

   This specification defines the following definitive response
   indicators for use in the certificate status value:

   -- good
   -- revoked
   -- unknown

   The "good" state indicates a positive response to the status inquiry.
   At a minimum, this positive response indicates that the certificate
   is not revoked, but does not necessarily mean that the certificate
   was ever issued or that the time at which the response was produced
   is within the certificate's validity interval. Response extensions
   may be used to convey additional information on assertions made by
   the responder regarding the status of the certificate such as
   positive statement about issuance, validity, etc.

   The "revoked" state indicates that the certificate has been revoked
   (either permanantly or temporarily (on hold)).

   The "unknown" state indicates that the responder doesn't know about
   the certificate being requested.





Myers, et al.               Standards Track                     [Page 3]

RFC 2560                       PKIX OCSP                       June 1999


2.3  Exception Cases

   In case of errors, the OCSP Responder may return an error message.
   These messages are not signed. Errors can be of the following types:

   -- malformedRequest
   -- internalError
   -- tryLater
   -- sigRequired
   -- unauthorized

   A server produces the "malformedRequest" response if the request
   received does not conform to the OCSP syntax.

   The response "internalError" indicates that the OCSP responder
   reached an inconsistent internal state. The query should be retried,
   potentially with another responder.

   In the event that the OCSP responder is operational, but unable to
   return a status for the requested certificate, the "tryLater"
   response can be used to indicate that the service exists, but is
   temporarily unable to respond.

   The response "sigRequired" is returned in cases where the server
   requires the client sign the request in order to construct a
   response.

   The response "unauthorized" is returned in cases where the client is
   not authorized to make this query to this server.

2.4  Semantics of thisUpdate, nextUpdate and producedAt

   Responses can contain three times in them - thisUpdate, nextUpdate
   and producedAt. The semantics of these fields are:

   - thisUpdate: The time at which the status being indicated is known
                 to be correct
   - nextUpdate: The time at or before which newer information will be
                 available about the status of the certificate
   - producedAt: The time at which the OCSP responder signed this
                 response.

   If nextUpdate is not set, the responder is indicating that newer
   revocation information is available all the time.







Myers, et al.               Standards Track                     [Page 4]

RFC 2560                       PKIX OCSP                       June 1999


2.5  Response Pre-production

   OCSP responders MAY pre-produce signed responses specifying the
   status of certificates at a specified time. The time at which the
   status was known to be correct SHALL be reflected in the thisUpdate
   field of the response. The time at or before which newer information
   will be available is reflected in the nextUpdate field, while the
   time at which the response was produced will appear in the producedAt
   field of the response.

2.6  OCSP Signature Authority Delegation

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. A certificate's issuer
   explicitly delegates OCSP signing authority by issuing a certificate
   containing a unique value for extendedKeyUsage in the OCSP signer's
   certificate. This certificate MUST be issued directly to the
   responder by the cognizant CA.

2.7  CA Key Compromise

   If an OCSP responder knows that a particular CA's private key has
   been compromised, it MAY return the revoked state for all
   certificates issued by that CA.

3.  Functional Requirements

3.1  Certificate Content

   In order to convey to OCSP clients a well-known point of information
   access, CAs SHALL provide the capability to include the
   AuthorityInfoAccess extension (defined in [RFC2459], section 4.2.2.1)
   in certificates that can be checked using OCSP.  Alternatively, the
   accessLocation for the OCSP provider may be configured locally at the
   OCSP client.

   CAs that support an OCSP service, either hosted locally or provided
   by an Authorized Responder, MUST provide for the inclusion of a value
   for a uniformResourceIndicator (URI) accessLocation and the OID value
   id-ad-ocsp for the accessMethod in the AccessDescription SEQUENCE.

   The value of the accessLocation field in the subject certificate
   defines the transport (e.g. HTTP) used to access the OCSP responder
   and may contain other transport dependent information (e.g. a URL).







Myers, et al.               Standards Track                     [Page 5]

RFC 2560                       PKIX OCSP                       June 1999


3.2  Signed Response Acceptance Requirements

   Prior to accepting a signed response as valid, OCSP clients SHALL
   confirm that:

   1. The certificate identified in a received response corresponds to
   that which was identified in the corresponding request;

   2. The signature on the response is valid;

   3. The identity of the signer matches the intended recipient of the
   request.

   4. The signer is currently authorized to sign the response.

   5. The time at which the status being indicated is known to be
   correct (thisUpdate) is sufficiently recent.

   6. When available, the time at or before which newer information will
   be available about the status of the certificate (nextUpdate) is
   greater than the current time.

4.  Detailed Protocol

   The ASN.1 syntax imports terms defined in [RFC2459]. For signature
   calculation, the data to be signed is encoded using the ASN.1
   distinguished encoding rules (DER) [X.690].

   ASN.1 EXPLICIT tagging is used as a default unless specified
   otherwise.

   The terms imported from elsewhere are: Extensions,
   CertificateSerialNumber, SubjectPublicKeyInfo, Name,
   AlgorithmIdentifier, CRLReason

4.1  Requests

   This section specifies the ASN.1 specification for a confirmation
   request. The actual formatting of the message could vary depending on
   the transport mechanism used (HTTP, SMTP, LDAP, etc.).

4.1.1  Request Syntax

   OCSPRequest     ::=     SEQUENCE {
       tbsRequest                  TBSRequest,
       optionalSignature   [0]     EXPLICIT Signature OPTIONAL }

   TBSRequest      ::=     SEQUENCE {



Myers, et al.               Standards Track                     [Page 6]

RFC 2560                       PKIX OCSP                       June 1999


       version             [0]     EXPLICIT Version DEFAULT v1,
       requestorName       [1]     EXPLICIT GeneralName OPTIONAL,
       requestList                 SEQUENCE OF Request,
       requestExtensions   [2]     EXPLICIT Extensions OPTIONAL }

   Signature       ::=     SEQUENCE {
       signatureAlgorithm      AlgorithmIdentifier,
       signature               BIT STRING,
       certs               [0] EXPLICIT SEQUENCE OF Certificate
   OPTIONAL}

   Version         ::=             INTEGER  {  v1(0) }

   Request         ::=     SEQUENCE {
       reqCert                     CertID,
       singleRequestExtensions     [0] EXPLICIT Extensions OPTIONAL }

   CertID          ::=     SEQUENCE {
       hashAlgorithm       AlgorithmIdentifier,
       issuerNameHash      OCTET STRING, -- Hash of Issuer's DN
       issuerKeyHash       OCTET STRING, -- Hash of Issuers public key
       serialNumber        CertificateSerialNumber }

   issuerNameHash is the hash of the Issuer's distinguished name. The
   hash shall be calculated over the DER encoding of the issuer's name
   field in the certificate being checked. issuerKeyHash is the hash of
   the Issuer's public key. The hash shall be calculated over the value
   (excluding tag and length) of the subject public key field in the
   issuer's certificate. The hash algorithm used for both these hashes,
   is identified in hashAlgorithm. serialNumber is the serial number of
   the certificate for which status is being requested.

4.1.2  Notes on the Request Syntax

   The primary reason to use the hash of the CA's public key in addition
   to the hash of the CA's name, to identify the issuer, is that it is
   possible that two CAs may choose to use the same Name (uniqueness in
   the Name is a recommendation that cannot be enforced). Two CAs will
   never, however, have the same public key unless the CAs either
   explicitly decided to share their private key, or the key of one of
   the CAs was compromised.

   Support for any specific extension is OPTIONAL. The critical flag
   SHOULD NOT be set for any of them.  Section 4.4 suggests several
   useful extensions.  Additional extensions MAY be defined in
   additional RFCs. Unrecognized extensions MUST be ignored (unless they
   have the critical flag set and are not understood).




Myers, et al.               Standards Track                     [Page 7]

RFC 2560                       PKIX OCSP                       June 1999


   The requestor MAY choose to sign the OCSP request. In that case, the
   signature is computed over the tbsRequest structure. If the request
   is signed, the requestor SHALL specify its name in the requestorName
   field. Also, for signed requests, the requestor MAY include
   certificates that help the OCSP responder verify the requestor's
   signature in the certs field of Signature.

4.2  Response Syntax

   This section specifies the ASN.1 specification for a confirmation
   response. The actual formatting of the message could vary depending
   on the transport mechanism used (HTTP, SMTP, LDAP, etc.).

4.2.1  ASN.1 Specification of the OCSP Response

   An OCSP response at a minimum consists of a responseStatus field
   indicating the processing status of the prior request. If the value
   of responseStatus is one of the error conditions, responseBytes are
   not set.

   OCSPResponse ::= SEQUENCE {
      responseStatus         OCSPResponseStatus,
      responseBytes          [0] EXPLICIT ResponseBytes OPTIONAL }

   OCSPResponseStatus ::= ENUMERATED {
       successful            (0),  --Response has valid confirmations
       malformedRequest      (1),  --Illegal confirmation request
       internalError         (2),  --Internal error in issuer
       tryLater              (3),  --Try again later
                                   --(4) is not used
       sigRequired           (5),  --Must sign the request
       unauthorized          (6)   --Request unauthorized
   }