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

PKIX的RFC英文文档

   not authorized to make this query to this server.

3.5  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 it is
   does not know when newer revocation information will be available
   (examples of why a responder might not know when new revocation
   information is likely to be available are that the CA hasn't told
   it, or because newer information is available all the time).

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

3.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.8  Transports for OCSP

   While OCSP can be used over many transports, for interoperability,
   all OCSP clients and responders MUST support the use of HTTP [HTTP]
   as the transport.

4.  Functional Requirements

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

Malpani & all                                                   [Page 6]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002


   AuthorityInfoAccess extension (defined in [RFC3280], 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).

4.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 nextUpdate is set in the response, it is greater than the 
      current time.

   7. The producedAt time in the response is sufficiently recent.

   8. If the request contained a nonce, the response must contain the
      same nonce (see section 5.4.1).

   NOTE: The first criteria does not imply that a client should reject
   an OCSP response from a server that contains statuses of
   a superset or subset of the certificates whose statuses were 
   requested i.e. it is all right for a server to, in an OCSP response 
   provide the statuses of only some of the certificates requested, and 
   some other certificates whose statues were not requested. For 
   example, if a client requests the status of certificates with serial 
   numbers 1 and 2 and gets a response which has the statuses of 
   certificates with serial numbers 1 and 3, the client can accept that 
   response for the status of the certificate with serial number 1, 
   assuming the rest of the response acceptance criteria were met.



Malpani & all                                                   [Page 7]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002


5.  Detailed Protocol

   The ASN.1 syntax imports terms defined in [RFC3280]. 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, IssuerandSerialNumber.

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

5.1.1  Request Syntax

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

   TBSRequest      ::=     SEQUENCE {
       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 Certificates OPTIONAL}

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

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

   Certificates    ::=     SEQUENCE SIZE(1..MAX) of Certificate

ReqCert  ::= CHOICE {
   certID                     CertID,
   fullCert               [0] FullCertificate,
   certIdWithSignature    [1] CertIdWithSignature }

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


Malpani & all                                                   [Page 8]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002

Note: CertID is kept unchanged from OCSPv1.

OCSPv1 interoperablity can be obtained through the use of the certID 
element of the ReqCert CHOICE.  If certID is used in ReqCert, the value 
for version in the tbsRequest field of OCSPRequest SHALL be v1. If any 
other choice in ReqCert is used, the value for version SHALL be v2.


   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 of the BIT STRING subjectPublicKey field (excluding the tag,
   length and number of unused bits) 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.

fullCert may be either a public key certificate, as defined in 
RFC 3280, or an attribute certificate, as defined in RFC 3281.

OCSP responder SHALL support public key certificates and MAY support 
Attribute Certificates.

   FullCertificate ::= CHOICE {
     certificate      [0]  Certificate,
     attributeCert    [1]  AttributeCertificate }

certIdWithSignature is a more compact way to specify unambiguously a 
certificate.

   CertIdWithSignature ::= SEQUENCE {
        issuerandSerialNumber     IssuerandSerialNumber,
        tbsCertificateHash        BIT STRING,
        certSignature             CertSignature
   }

IssuerandSerialNumber is defined in [RFC3369] section 10.2.4.

tbsCertificateHash contains a hash value computed over the ASN.1 DER 
encoded tbsCertificate field from the certificate using the hash 
function identified in the signature algorithm from the signature.

certSignature contains the signature fields from the certificate.

   CertSignature ::= SEQUENCE {
        signatureAlgorithm        AlgorithmIdentifier,
        signatureValue            BIT STRING
   }






Malpani & all                                                   [Page 9]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002

5.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, when CertID is 
   being used, 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. Including the hash of 
   the CA's public key allows an OCSP client to ensure that it and the 
   responder are both referring to the same CA.

   Support for any specific extension is OPTIONAL. The critical flag
   SHOULD NOT be set for any of them.  Section 6.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).

   The requestor MAY choose to sign the OCSP request. In that case,
   the signature is computed over the DER encoding of 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.

5.1.3. Notes on the client behavior

   This standard mandates the client to verify that 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.

These three cases are then considered individually:

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

   In that case, the client MUST first verify the certification path of 
   the certificate and then use the key that was used to verify the 
   certificate to verify that the signature from the OCSP response is 
   correct. 






Malpani & all                                                  [Page 10]

INTERNET DRAFT      OCSP extension and OCSPv2 protocol     December 2002


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

   In that case, the client must directly use the public key from 
   the Trusted Responder.  This means that the client may not know if 
   that key is revoked or not (unless out-of-bands means are being 
   used).

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

      a) using CertID.  In that case, issuerNameHash and issuerKeyHash 
         are provided by the client.  Since the client needs to provide 
         the issuerKeyHash, this means that it needs first to get the 
         superior CA certificate (e.g. it may be sent in a signed