draft-ietf-pkix-ocspv2-ext-01.txt

PKIX的RFC英文文档

         the data base. 

         When the OCSP responder does not have access to the data base 
         of the issuer, then it may use either CRLs or the OCSP 
         responder designated by the CA that has issued the certificate.

         When the OCSP responder does not have access to the data base 
         of the issuers, then it SHALL first make sure that it is the 
         right certificate. 

         This MUST be done by verifying the signature over that 
         certificate.  For doing this, the OCSP responder first needs 
         to build a certification path up to one of its trust anchors 
        (without necessarily verifying the revocation status of the CAs 
         from the path).  The presumed issuer key MUST then be used to 
         verify the signature of the certificate using both the 
         tbsCertificateHash and the signature value.  That issuer key 
         MUST then be used to verify that this key is used to sign the 
         CRL or the OCSP response, or the certificates issued to 
         designate the CRL issuer or the OCSP responder.

5.2.2.4.3. CA designated Responder who holds a specially marked 
certificate issued directly by the CA

   The OCSP server may either have a direct access to the data base from 
   the issuer or use CRLs issued by that issuer or a designated CRL 
   issuer. 

   It is up to the OCSP responder to be fully aware when it is handling 
   the revocation service for two CAs that would have the same name 
   (certified under different certification branches).  


Malpani & all                                                  [Page 16]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002


   When all issuers that are handled have different names, there is no 
   problem.  Otherwise, when some issuers have the same name, then 
   different cases apply depending on the ways the client designates the 
   issuer:

      a) using CertID. 

         In that case, the OCSP responder MUST use issuerKeyHash to 
         make sure that it is getting information from the right 
         issuer.  For doing this, the OCSP responder once needs to 
         build a certification path up to one of its trust anchors 
         (without necessarily verifying the revocation status of 
         the CAs from the path).  The presumed issuer key MUST then be 
         checked against the issuerKeyHash. T hat issuer key MUST then 
         be used to verify that this key is used to sign the CRL, or 
         the certificates issued to designate the CRL issuer or is 
         associated with a given data base.

      b) using the full certificate. 

         In that case, the OCSP responder MUST verify the signature over 
         the certificate.  For doing this, the OCSP responder once 
         needs to build a certification path up to one of its trust
         anchors (without necessarily verifying the revocation status of 
         the CAs from the path).  The presumed issuer key MUST then be 
         used to verify the signature of the certificate using both the 
         tbsCertificateHash and the signature value.  That issuer key 
         MUST then be used to verify that this key is used to sign the 
         CRL, or the certificates issued to designate the CRL issuer or 
         is associated with a given data base.

      c) using CertIdWithSignature. 

         In that case, the OCSP responder MUST verify the signature over 
         the certificate.  For doing this, the OCSP responder once 
         needs to build a certification path up to one of its trust
         anchors (without necessarily verifying the revocation status of 
         the CAs from the path).  The presumed issuer key MUST then be 
         used to verify the signature of the certificate.  That issuer 
         key MUST then be used to verify that this key is used to sign 
         the CRL, or the certificates issued to designate the CRL 
         issuer or is associated with a given data base.

5.3  Mandatory and Optional Cryptographic Algorithms

   OCSP clients and responders MUST support the RSA signature
   algorithm. This algorithm is defined in RFC 2437 [RFC2437]. 
   OCSP clients and responders MAY support the DSA signature algorithm. 
   This algorithm is defined in FIPS Pub 186 [DSS].
   OCSP responders MUST support the SHA1 hashing algorithm. 
   This algorithm is defined in FIPS Pub 180-1 [SHA1].



Malpani & all                                                  [Page 17]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002


5.4  Extensions

   This section defines some standard extensions, based on the extension
   model employed in X.509 version 3 certificates see [RFC3280]. Support
   for all extensions is optional for both clients and responders.  For
   each extension, the definition indicates its syntax, processing
   performed by the OCSP Responder, and any extensions which are
   included in the corresponding response.

5.4.1  Nonce

   The nonce cryptographically binds a response to a request to
   prevent replay attacks. In a request, a nonce (if present) is
   included as one of the requestExtensions in requests, while in
   responses (if present) it is included as one of the
   responseExtensions. In both the request and the response, the nonce
   is identified by the object identifier id-pkix-ocsp-nonce, while
   the extnValue is the value of the nonce. If a nonce is included in
   a request, then the response MUST contain the same nonce. Responses
   without the same nonce MUST NOT be trusted.

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

     extnValue ::= OCTET STRING

5.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.




Malpani & all                                                  [Page 18]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002


5.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).

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

   AcceptableResponses ::= SEQUENCE OF OBJECT IDENTIFIER

   As noted in section 6.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.

5.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).

5.4.5  CRL Entry Extensions

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






Malpani & all                                                  [Page 19]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002

5.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.

   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.

   When this field is present in the request and when a full 
   certificate is sent, the server SHALL use the values contained in 
   this field rather than the field from the subject certificate.

6. CRL Locator

This extension can be supported either using OCSPv1 or using OCSPv2.

An OCSP server may be operated in a mode whereby the server receives a
request and fetches the CRL which authoritative for the identified
certificate. The crlLocator request extension is defined for this 
purpose.

This extension is included as one of the singleRequestExtensions in
requests.

   id-pkix-ocsp-crl-locator OBJECT IDENTIFIER ::= {id-pkix-ocsp X}

   CrlLocator ::= CRLDistributionPoints

The value for this field should be obtained by the client from the 
corresponding field in the subject certificate.

   When this field is present in the request and when a full 
   certificate is sent, the server SHALL use the values contained in 
   this field rather than the field from the subject certificate.

Note: In this way, OCSP servers able to access CRLs may use that CRL 
information and transform it into an OCSP response. This may allow a 
client to support the OCSP protocol, even when CRLs are issued by CAs.

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

Malpani & all                                                  [Page 20]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002

   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.

   Nonces should be random. If the nonce is generated in a non-random
   way, replay attacks MAY be possible.

   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.

   A "good" status for a certificate in OCSP does not imply that the
   certificate was ever issued or is in its validity period. Client
   applications need to check these facts for themselves.

   Two CAs around the world may perfectly pick the same DN, e.g. with a
   common name attribute like CN= Platinium CA. A *single* immediately 
   魋uperior CA