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

PKIX的RFC英文文档

         message) and to verify that the issuer key was used to sign it.

      b) using the full certificate.  The client does not need to 
         verify first the certification path of the certificate. 

      c) using CertIdWithSignature. The client does not need to 
         verify first the certification path of the certificate. 

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

   In that case, the client MUST use the AIA extension present in 
   the certificate to locate the Authorized Responder.  The client 
   does not need to verify first the certification path of the 
   certificate. However, when it gets the OCSP response, it SHALL 
   verify that the signature from the OCSP response is correct.  For 
   doing this, it MUST find a certificate which holds a special mark 
   (i.e. which contains in the Extended Key Usage the extension 
   id-kp-OCSPSigning) issued by the issuer of the certificate to be 
   verified and then make sure that this certificate allows to verify 
   the signature from the OCSP response.  It MUST verify the whole 
   certification path for that certificate and verify that none of the 
   certificates is revoked.

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

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

Malpani & all                                                  [Page 11]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002


   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
       badCRL                (8)   --Error in CRL processing
   }

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 }

   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 Certificates OPTIONAL }

   The value for signature SHALL be computed on the DER encoding of
   tbsResponseData.  The responder MAY include certificates that help
   the OCSP client verify the responder's signature in the certs field
   of BasicOCSPResponse.

   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 }


Malpani & all                                                  [Page 12]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002


   KeyHash ::= OCTET STRING -- SHA-1 hash of responder's public key
   -- (i.e. the SHA-1 hash of the value of the BIT STRING 
   -- subjectPublicKey [excluding the tag, length and number of unused 
  --  bits] of the responder's certificate).

   SingleResponse ::= SEQUENCE {
      reqCert                      ReqCert,
      -- MUST be identical to the same field from the request
      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

5.2.2  Notes on OCSP Responses

5.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 is explained in more detail in Section 2.4).

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

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

Malpani & all                                                  [Page 13]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002


   Systems or applications that rely on OCSP responses MUST be capable
   of detecting and enforcing use of the id-kp-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-kp-OCSPSigning in an ExtendedKeyUsage
   extension and is issued by the CA that issued the certificate in
   question.

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

5.2.2.3.  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 realize 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 [RFC3280].

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


Malpani & all                                                  [Page 14]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002

5.2.2.4. Checks to be done by the responder

The key used to sign the response belongs to one of the following:

       1) the CA who issued the certificate in question,

       2) a Trusted Responder whose public key is trusted by the
          requestor,

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

5.2.2.4.1. Responder whose public key is the same as the key from CA who 
issued the certificate

   In that case, the OCSP server may either use a direct access to the 
   issuer database that contains the certificate or use CRLs that 
   originate directly from the issuer (e.g. communicated through a 
   trusted channel).  In that case either an access to a single data 
   base is supported or accesses to CRLs issued by one single issuer 
   are supported.  There cannot be any mistake about the name of the 
   issuer.

5.2.2.4.2. Trusted Responder whose public key is trusted by the 
requestor

   There are three ways for the client to designate the issuer:

      a) using CertID. 

         Since the issuer may be using CRLs or OCSP servers to provide 
         the revocation status information, and since the keys for 
         signing the CRLs may be the same or different from the keys 
         used to sign the certificate, the OCSP server MUST make sure 
         that either the CRL or the OCSP response that it is using 
         is signed with the right key.  This means that the OCSP 
         responder MUST build a certification path up to one of its 
         trust anchors and then get the public key of the issuer. 
         At that time, it MUST verify that this key matches the 
         issuerKeyHash.  This key MUST match with the private key that 
         has been used is used to sign the CRL or the OCSP response or 
         the certificates issued to designate the CRL issuer or the 
         OCSP responder. 

      b) using the full certificate. 

         When the OCSP responder has a direct access to the data base 
         of the issuer for which it is providing revocation status 
         information, then it SHALL make sure that it is the right 
         certificate by verifying that the certificate that was sent 
         matches the one in the data base. 


Malpani & all                                                  [Page 15]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002


         When the OCSP responder does not have access to the data base 
         of the issuers, then it SHALL make sure that it is the right 
         certificate by verifying the signature over that 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 is then 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 OCSP response, or the certificates issued to designate 
         the CRL issuer or the OCSP responder.

      c) using CertIdWithSignature. 

         When the OCSP responder has a direct access to the data base 
         of the issuer for which it is providing revocation status 
         information, then it SHALL make sure that it is the right 
         certificate by verifying that the signature that was sent 
         matches with the signature of the certificate contained in