rfc2560.txt

PKIX的RFC英文文档

   The value for responseBytes consists of an OBJECT IDENTIFIER and a
   response syntax identified by that OID encoded as an OCTET STRING.

   ResponseBytes ::=       SEQUENCE {
       responseType   OBJECT IDENTIFIER,
       response       OCTET STRING }

   For a basic OCSP responder, responseType will be id-pkix-ocsp-basic.

   id-pkix-ocsp           OBJECT IDENTIFIER ::= { id-ad-ocsp }
   id-pkix-ocsp-basic     OBJECT IDENTIFIER ::= { id-pkix-ocsp 1 }






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


   OCSP responders SHALL be capable of producing responses of the id-
   pkix-ocsp-basic response type. Correspondingly, OCSP clients SHALL be
   capable of receiving and processing responses of the id-pkix-ocsp-
   basic response type.

   The value for response SHALL be the DER encoding of
   BasicOCSPResponse.

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

   The value for signature SHALL be computed on the hash of the DER
   encoding ResponseData.

   ResponseData ::= SEQUENCE {
      version              [0] EXPLICIT Version DEFAULT v1,
      responderID              ResponderID,
      producedAt               GeneralizedTime,
      responses                SEQUENCE OF SingleResponse,
      responseExtensions   [1] EXPLICIT Extensions OPTIONAL }

   ResponderID ::= CHOICE {
      byName               [1] Name,
      byKey                [2] KeyHash }

   KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
   (excluding the tag and length fields)

   SingleResponse ::= SEQUENCE {
      certID                       CertID,
      certStatus                   CertStatus,
      thisUpdate                   GeneralizedTime,
      nextUpdate         [0]       EXPLICIT GeneralizedTime OPTIONAL,
      singleExtensions   [1]       EXPLICIT Extensions OPTIONAL }

   CertStatus ::= CHOICE {
       good        [0]     IMPLICIT NULL,
       revoked     [1]     IMPLICIT RevokedInfo,
       unknown     [2]     IMPLICIT UnknownInfo }

   RevokedInfo ::= SEQUENCE {
       revocationTime              GeneralizedTime,
       revocationReason    [0]     EXPLICIT CRLReason OPTIONAL }

   UnknownInfo ::= NULL -- this can be replaced with an enumeration



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


4.2.2  Notes on OCSP Responses

4.2.2.1  Time

   The thisUpdate and nextUpdate fields define a recommended validity
   interval. This interval corresponds to the {thisUpdate, nextUpdate}
   interval in CRLs. Responses whose nextUpdate value is earlier than
   the local system time value SHOULD be considered unreliable.
   Responses whose thisUpdate time is later than the local system time
   SHOULD be considered unreliable. Responses where the nextUpdate value
   is not set are equivalent to a CRL with no time for nextUpdate (see
   Section 2.4).

   The producedAt time is the time at which this response was signed.

4.2.2.2  Authorized Responders

   The key that signs a certificate's status information need not be the
   same key that signed the certificate. It is necessary however to
   ensure that the entity signing this information is authorized to do
   so.  Therefore, a certificate's issuer MUST either sign the OCSP
   responses itself or it MUST explicitly designate this authority to
   another entity.  OCSP signing delegation SHALL be designated by the
   inclusion of id-kp-OCSPSigning in an extendedKeyUsage certificate
   extension included in the OCSP response signer's certificate.  This
   certificate MUST be issued directly by the CA that issued the
   certificate in question.

   id-kp-OCSPSigning OBJECT IDENTIFIER ::= {id-kp 9}

   Systems or applications that rely on OCSP responses MUST be capable
   of detecting and enforcing use of the id-ad-ocspSigning value as
   described above. They MAY provide a means of locally configuring one
   or more OCSP signing authorities, and specifying the set of CAs for
   which each signing authority is trusted. They MUST reject the
   response if the certificate required to validate the signature on the
   response fails to meet at least one of the following criteria:

   1. Matches a local configuration of OCSP signing authority for the
   certificate in question; or

   2. Is the certificate of the CA that issued the certificate in
   question; or

   3. Includes a value of id-ad-ocspSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question."




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


   Additional acceptance or rejection criteria may apply to either the
   response itself or to the certificate used to validate the signature
   on the response.

4.2.2.2.1  Revocation Checking of an Authorized Responder

   Since an Authorized OCSP responder provides status information for
   one or more CAs, OCSP clients need to know how to check that an
   authorized responder's certificate has not been revoked. CAs may
   choose to deal with this problem in one of three ways:

   - A CA may specify that an OCSP client can trust a responder for the
   lifetime of the responder's certificate. The CA does so by including
   the extension id-pkix-ocsp-nocheck. This SHOULD be a non-critical
   extension. The value of the extension should be NULL. CAs issuing
   such a certificate should realized that a compromise of the
   responder's key, is as serious as the compromise of a CA key used to
   sign CRLs, at least for the validity period of this certificate. CA's
   may choose to issue this type of certificate with a very short
   lifetime and renew it frequently.

   id-pkix-ocsp-nocheck OBJECT IDENTIFIER ::= { id-pkix-ocsp 5 }

   - A CA may specify how the responder's certificate be checked for
   revocation. This can be done using CRL Distribution Points if the
   check should be done using CRLs or CRL Distribution Points, or
   Authority Information Access if the check should be done in some
   other way. Details for specifying either of these two mechanisms are
   available in [RFC2459].

   - A CA may choose not to specify any method of revocation checking
   for the responder's certificate, in which case, it would be up to the
   OCSP client's local security policy to decide whether that
   certificate should be checked for revocation or not.

4.3  Mandatory and Optional Cryptographic Algorithms

   Clients that request OCSP services SHALL be capable of processing
   responses signed used DSA keys identified by the DSA sig-alg-oid
   specified in section 7.2.2 of [RFC2459]. Clients SHOULD also be
   capable of processing RSA signatures as specified in section 7.2.1 of
   [RFC2459]. OCSP responders SHALL support the SHA1 hashing algorithm.

4.4  Extensions

   This section defines some standard extensions, based on the extension
   model employed in X.509 version 3 certificates see [RFC2459]. Support
   for all extensions is optional for both clients and responders.  For



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


   each extension, the definition indicates its syntax, processing
   performed by the OCSP Responder, and any extensions which are
   included in the corresponding response.

4.4.1  Nonce

   The nonce cryptographically binds a request and a response to prevent
   replay attacks. The nonce is included as one of the requestExtensions
   in requests, while in responses it would be included as one of the
   responseExtensions. In both the request and the response, the nonce
   will be identified by the object identifier id-pkix-ocsp-nonce, while
   the extnValue is the value of the nonce.

   id-pkix-ocsp-nonce     OBJECT IDENTIFIER ::= { id-pkix-ocsp 2 }

4.4.2  CRL References

   It may be desirable for the OCSP responder to indicate the CRL on
   which a revoked or onHold certificate is found. This can be useful
   where OCSP is used between repositories, and also as an auditing
   mechanism. The CRL may be specified by a URL (the URL at which the
   CRL is available), a number (CRL number) or a time (the time at which
   the relevant CRL was created). These extensions will be specified as
   singleExtensions. The identifier for this extension will be id-pkix-
   ocsp-crl, while the value will be CrlID.

   id-pkix-ocsp-crl       OBJECT IDENTIFIER ::= { id-pkix-ocsp 3 }

   CrlID ::= SEQUENCE {
      crlUrl               [0]     EXPLICIT IA5String OPTIONAL,
      crlNum               [1]     EXPLICIT INTEGER OPTIONAL,
      crlTime              [2]     EXPLICIT GeneralizedTime OPTIONAL }

   For the choice crlUrl, the IA5String will specify the URL at which
   the CRL is available. For crlNum, the INTEGER will specify the value
   of the CRL number extension of the relevant CRL. For crlTime, the
   GeneralizedTime will indicate the time at which the relevant CRL was
   issued.

4.4.3  Acceptable Response Types

   An OCSP client MAY wish to specify the kinds of response types it
   understands. To do so, it SHOULD use an extension with the OID id-
   pkix-ocsp-response, and the value AcceptableResponses.  This
   extension is included as one of the requestExtensions in requests.
   The OIDs included in AcceptableResponses are the OIDs of the various
   response types this client can accept (e.g., id-pkix-ocsp-basic).




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


   id-pkix-ocsp-response  OBJECT IDENTIFIER ::= { id-pkix-ocsp 4 }

   AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

   As noted in section 4.2.1, OCSP responders SHALL be capable of
   responding with responses of the id-pkix-ocsp-basic response type.
   Correspondingly, OCSP clients SHALL be capable of receiving and
   processing responses of the id-pkix-ocsp-basic response type.

4.4.4  Archive Cutoff

   An OCSP responder MAY choose to retain revocation information beyond
   a certificate's expiration. The date obtained by subtracting this
   retention interval value from the producedAt time in a response is
   defined as the certificate's "archive cutoff" date.

   OCSP-enabled applications would use an OCSP archive cutoff date to
   contribute to a proof that a digital signature was (or was not)
   reliable on the date it was produced even if the certificate needed
   to validate the signature has long since expired.

   OCSP servers that provide support for such historical reference
   SHOULD include an archive cutoff date extension in responses.  If
   included, this value SHALL be provided as an OCSP singleExtensions
   extension identified by id-pkix-ocsp-archive-cutoff and of syntax
   GeneralizedTime.

   id-pkix-ocsp-archive-cutoff  OBJECT IDENTIFIER ::= { id-pkix-ocsp 6 }

   ArchiveCutoff ::= GeneralizedTime

   To illustrate, if a server is operated with a 7-year retention
   interval policy and status was produced at time t1 then the value for
   ArchiveCutoff in the response would be (t1 - 7 years).

4.4.5  CRL Entry Extensions

   All the extensions specified as CRL Entry Extensions - in Section 5.3
   of [RFC2459] - are also supported as singleExtensions.

4.4.6  Service Locator

   An OCSP server may be operated in a mode whereby the server receives
   a request and routes it to the OCSP server which is known to be
   authoritative for the identified certificate.  The serviceLocator
   request extension is defined for this purpose.  This extension is
   included as one of the singleRequestExtensions in requests.




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


   id-pkix-ocsp-service-locator OBJECT IDENTIFIER ::= { id-pkix-ocsp 7 }

   ServiceLocator ::= SEQUENCE {
       issuer    Name,
       locator   AuthorityInfoAccessSyntax OPTIONAL }

   Values for these fields are obtained from the corresponding fields in
   the subject certificate.

5.  Security Considerations

   For this service to be effective, certificate using systems must
   connect to the certificate status service provider. In the event such
   a connection cannot be obtained, certificate-using systems could
   implement CRL processing logic as a fall-back position.

   A denial of service vulnerability is evident with respect to a flood
   of queries. The production of a cryptographic signature significantly
   affects response generation cycle time, thereby exacerbating the
   situation. Unsigned error responses open up the protocol to another
   denial of service attack, where the attacker sends false error
   responses.

   The use of precomputed responses allows replay attacks in which an
   old (good) response is replayed prior to its expiration date but
   after the certificate has been revoked. Deployments of OCSP should
   carefully evaluate the benefit of precomputed responses against the
   probability of a replay attack and the costs associated with its
   successful execution.

   Requests do not contain the responder they are directed to. This
   allows an attacker to replay a request to any number of OCSP
   responders.

   The reliance of HTTP caching in some deployment scenarios may result
   in unexpected results if intermediate servers are incorrectly
   configured or are known to possess cache management faults.
   Implementors are advised to take the reliability of HTTP cache
   mechanisms into account when deploying OCSP over HTTP.












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


6.  References

   [RFC2459] Housley, R., Ford, W., Polk, W. and D. Solo, "Internet
             X.509 Public Key Infrastructure Certificate and CRL
             Profile", RFC 2459, January 1999.

   [HTTP]    Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T.
             Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC
             2068, January 1997.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [URL]     Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
             Resource Locators (URL)", RFC 1738, December 1994.

   [X.690]   ITU-T Recommendation X.690 (1994) | ISO/IEC 8825-1:1995,
             Information Technology - ASN.1 encoding rules:
             Specification of Basic Encoding Rules (BER), Canonical
             Encoding Rules (CER) and Distinguished Encoding Rules
             (DER).






























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


7.  Authors' Addresses

   Michael Myers
   VeriSign, Inc.
   1350 Charleston Road
   Mountain View, CA 94043

   EMail: [e-mail]


   Rich Ankney
   CertCo, LLC
   13506 King Charles Dr.
   Chantilly, VA  20151

   EMail: [e-mail]