draft-ietf-pkix-cvp-01.txt

PKIX的RFC英文文档

The same validation protocol may be used to validate a certificate 
against a validation policy either for:

   1) initial validation or for,
   2) re-validation, using information captured by a CVP server 
      and returned to the client at the time of initial validation.


Pinkas                                                         [Page 6]

Internet Draft                   CVP                       October 2002

4.1 Initial validation 

An initial validation SHALL be performed according to a validation 
policy. 

If the client does not specify in its request the validation policy to 
be used, the server will indicate in the response the one that has 
been used. In such a case, the client SHOULD verify that the one 
selected is appropriate for its use.

4.2 Re-validation 

Re-validation SHALL be performed according to a validation policy. 

The requester MUST specify the certificate to be validated and MUST 
provide previous returned references of the certification path, or 
the previous returned values of the certification path.

5. Description the CVP protocol

A DVP/DPD request may be optionally signed and contains the following 
data:

   -- a protocol version
   -- an optional nonce to prevent replays
   -- either the identification of the certificate(s) to validate 
      or the certificate(s) themselves, and for each certificate:
         -- optionally, useful certificates
         -- optionally, useful revocation information
         -- optionally, previous returned references for re-validation
         -- optionally, previous returned values for re-validation
   -- optionally, the validation or discovery policy to be used
   -- whether it is a DPV or a DPD request
        -- for a DPV request:
           -- whether the server response shall not be signed
           -- whether the values of the path should be returned
           -- whether the references of the path should be returned
           -- whether the references of the path should be time-stamped
         -- for a DPD request:
             -- whether the server response shall be signed
             -- optionally, a context information provided by the 
                server for getting additional path information
             -- whether the path and all the revocation status should 
                be returned
             -- whether both the path and only the certificate 
                revocation status should be returned
             -- whether both the path and the CA revocation status 
                should be returned
             -- whether only the path should be returned
   -- optionally, identification(s) of the requester, to be copied in 
      the response, when the request is authenticated
   -- optionally, data from the requester to be copied in the response
   -- optional extensions 


Pinkas                                                         [Page 7]

Internet Draft                   CVP                       October 2002


Upon receipt of a request, a CVP 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 is not met, the CVP responder 
produces an unsigned error message; otherwise, it returns a definitive 
signed or unsigned response, as requested.

A CVP response contains a major status, followed by a response in case 
of "success" and optionally with the validation data. 

The validation data that has been collected during the validation may 
be rather long since it may consist of a certification path and its 
associated revocation status information for each element from the 
path. If the validation data was directly part of the signed response, 
then the signed response could also be rather long, if needed to be 
stored simply as a proof for a third party trusting the same CVP 
server. For that reason, only the hash of the validation data is part 
of the signed response, and the actual values of the validation data 
are not part of the signed response.

Each response includes the following data:

   -- protocol version,
   -- an optional nonce to detect replays,
   -- a major status,
   -- a minor status
   -- the identification of the certificate,
   -- the reference of the validation policy that has been used,
   -- the kind of service that has been requested,
   -- a serial number for that response,
   -- the response time,
   -- the validation time,
   -- a hash over all parameters from the request (to detect changes),
   -- identification) of the server, when the response is signed,
   -- an optional unambiguous reference of the CVP server certificate.
   -- optional identification(s) of the requester,
   -- optional data from the requester that is copied in the response,
   -- optional context information,
   -- a field for future extensions.

External to the signed part of the response, the response may include 
the validation data.

5.2. Detailed Protocol

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



Pinkas                                                         [Page 8]

Internet Draft                   CVP                       October 2002


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

   The terms imported from elsewhere are: Extensions, Name, 
   AlgorithmIdentifier, CRLReason, RevocationValues, 
   CompleteCertificateRefs, CompleteRevocationRefs.

5.2.1. Request

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

   CVPRequest     ::=     SEQUENCE {
       mbsRequest                MBSRequest,
                                 -- May Be Signed Request
       optionalSignature    [0]  EXPLICIT Signature       OPTIONAL }

   MBSRequest      ::=   CHOICE {
      policyRequest         [0]  PolicyRequest,
      request               [1]  Request
   }

   PolicyRequest   ::= SEQUENCE {
      version                       [0]  EXPLICIT Version  DEFAULT v1,
      validationPoliciesMaxNumber        INTEGER,
      discoveryPoliciesMaxNumber         INTEGER
   }

version allows to identify the version of the protocol.

   Version ::=                   INTEGER  {  v1(0) }

validationPoliciesMaxNumber specifies the maximum number of validation 
policies to be returned.

discoveryPoliciesMaxNumber specifies the maximum number of discovery 
policies to be returned.

Request ::= SEQUENCE {
       version                   Version           DEFAULT v1,
       nonce                     OCTET STRING               OPTIONAL,
       certsQueries              SEQUENCE OF CertsQuery
       valOrDiscoPolicy          ValOrDiscoPolicy           OPTIONAL,
       checks                    Checks,
       requesterName        [1]  EXPLICIT GeneralName       OPTIONAL,
       requesterData        [2]  EXPLICIT CHARACTER STRING  OPTIONAL,
       signatory            [3]  ESSCertID                  OPTIONAL
       requestExtensions    [4]  EXPLICIT Extensions        OPTIONAL
   }

nonce is a unique number (e.g. a large pseudo random number) generated 
by the client that may be used to detect replay.

Pinkas                                                         [Page 9]

Internet Draft                   CVP                       October 2002


certQueries may be composed of a single or of multiple certQuery.

   CertQuery ::= SEQUENCE {
       certToValidate              CertOrCertRef,
       usefulCerts            [0]  CertificateValues          OPTIONAL,
       usefulRevoc            [1]  RevocationValues           OPTIONAL,
                                   -- defined in [RFC3126]
       previousValidationData [2]  ValidationData             OPTIONAL,
       CertQueryExtensions    [3]  EXPLICIT Extensions        OPTIONAL
   }

certToValidate is the certificate to validate. It is either the actual 
value of the certificate or an unambiguous reference of that 
certificate: the issuer name, the certificate serial number, a hash 
value computed over the ASN.1 DER encoded tbsCertificate field from the 
certificate, and the signature (value and algorithm identifier) of the 
certificate; or the issuer name, the certificate serial number, a hash 
value computed over the certificate; in order to guard both against 
compromission of CA keys and CA name homonyms. 

usefulCerts is a set of certificates that may be useful for the server 
to build a path.

usefulRevoc is a set of revocation information, that may be useful for 
the server to make sure that no element from the path is revoked.

previousValidationData contains the validation data from a previous 
response. This information may be necessary for the CVP server to be 
able to perform a re-validation for a time T in the past.

valOrDiscoPolicy is a reference to either the validation policy or the 
discovery policy to be used. If the field is missing, the server will 
indicate which policy has been used. It is may either be the 
unambiguous reference of a policy or a simple policy as defined in this 
document or in other RFCs.

checks is defined as Checks.

   Checks ::= CHOICE { 
      dpvCheck              [0]  DpvCheck,
      dpdChecks             [1]  DpdChecks
   }

There is a choice between a DPV request and a DPD request.

   DpvCheck ::= SEQUENCE {
       signed                    BOOLEAN DEFAULT TRUE
       validationTime            GeneralizedTime            OPTIONAL,
                                 -- for a time in the past
       returnValues         [1]  BOOLEAN Default            FALSE,
       returnRefs           [2]  BOOLEAN Default            FALSE,
       timeStampRefs        [3]  BOOLEAN Default            FALSE
   }

Pinkas                                                        [Page 10]

Internet Draft                   CVP                       October 2002

For a DPV request the following parameters can be specified:

By default, all DPV responses are signed. However, the client may 
request unsigned responses if the communication is protected using 
other means (e.g. TLS)

validationTime is the time for which the validation should be performed 
for a time in the past. If that field is missing, then the current time 
is assumed.

returnValues is an indicator to ask the server to return the values of 
the path (both the values of the certificates used and the values of 
the revocation information used) or the value of a CVP response trusted 
under the validation policy.

returnRefs is an indicator to ask the server to return the references 
of the path (both the references of the certificates used and the 
references of the revocation information used). For validation for a 
time in the past, this avoids path construction and saves storage space 
when multiple validations are using the same path values (certificates 
and CRLs).

timeStampRefs is an indicator to ask the server to return a time-
stamped version of the returnRefs. The number of time-stamps and the 
names of the TSAs are indicated in the validation policy. This 
provides a protection in case a key from a CA, CRL Issuer, OCSP 
responder or CVP server would be compromised after the date of issue of 
the time-stamps.

   DpdChecks ::= SEQUENCE {
       signed                    BOOLEAN           DEFAULT FALSE,
       serverContextInfo         OCTET STRING      OPTIONAL,
       infoToBeReturned          InfoToBeReturned
  }

By default, all DPD responses are unsigned. However, the client may 
request signed responses if the communication is not protected (e.g. 
using TLS) by using the signed parameter.

serverContextInfo, if present, contains context from a previous 
request-response transaction with the same server. It allows the server 
to return one by one certification paths for the same certificate to 
the client. For example, if a server constructs a particular 
certification path for a certificate, but the client finds it 
unacceptable, the client can then send the same query back to the 
server with the serverContextInfo from the first response, and the 
server will be able to provide a different certification path (if one 
can be found).

Contents of the serverContextInfo are opaque to the client. That is, 
the client only knows that it needs to return the value provided by the 
server with the subsequent request to get a different certification 
path. Note that the subsequent query needs be essentially identical to 
the previous query. The client MUST NOT change any items other than:

Pinkas                                                        [Page 11]

Internet Draft                   CVP                       October 2002


      - nonce
      - serverContextInfo
      - the optional client's signature on the request

infoToBeReturned specifies the four different kinds of information to 
be returned.

   InfoToBeReturned ::= ENUMERATED {
        pathWithRevocInfo               (0),
        pathWithEndEntityRevocInfoOnly  (1),
        pathWithCaRevocInfoOnly         (2),
        pathWithoutRevocInfo            (3)
   }

pathWithRevocInfo indicates that the path and all the revocation status 
should be returned.

pathWithEndEntityRevocInfoOnly indicates that both the path and only 
the certificate revocation status should be returned.

pathWithCaRevocInfoOnly indicates that both the path and the CA 
revocation status should be returned.

pathWithoutRevocInfo indicates that only the path should be returned.

requesterName is an optional field that contains an identifier of the 
requester. It is used when the request is signed. In that case if the 
identifier of the requester matches one of the identifiers included in 
the signer's certificate, then it MAY be copied by the CVP server in 
its response.

requesterData is a string of characters that SHOULD be blindly copied 
by the CVP server in the signed response.