draft-ietf-pkix-cvp-01.txt

PKIX的RFC英文文档

Internet Draft                                        Denis Pinkas, Bull
draft-ietf-pkix-cvp-01.txt                                 October, 2002
Expires in six months 



                      Certificate Validation Protocol
                       <draft-ietf-pkix-cvp-01.txt>


Status of this memo

This document is an Internet-Draft and is in full conformance with all 
provisions of Section 10 of RFC 2026.

Internet-Drafts are working documents of the Internet Engineering Task 
Force (IETF), its areas, and its working groups.  Note that other 
groups may also distribute working documents as Internet-Drafts. 

Internet-Drafts are draft documents valid for a maximum of six months 
and may be updated, replaced, or obsoleted by other documents at any 
time.  It is inappropriate to use Internet-Drafts as reference 
material or to cite them other than as "work in progress."

The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.

1.  Abstract

This document defines a protocol called Certificate Validation Protocol 
(CVP) that can be used to:

(1) query the validation or discovery policies supported by 
    a CVP server, 
(2) validate one or more public key certificates according to a 
    single validation policy, or
(3) obtain one or more certification paths for one or more certificates 
    according to a single discovery policy.

Key words used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 
   this document (in uppercase, as shown) are to be interpreted as 
   described in [RFC2119].

2.  Certificate Validation Protocol Overview

This protocol specification is in accordance with the protocol 
requirements for Delegated Path Validation (DPV) and Delegated Path 
Discovery (DPD) defined in [RFC3379].

A server may support either DPV or DPD, or both DPV and DPD.

Pinkas                                                         [Page 1]

Internet Draft                   CVP                       October 2002

Validation or discovery policy definitions may be long and complex, 
and some policies may allow for the setting of a few parameters (such 
as root self-signed certificates). The protocol allows the client to 
use pre-defined simple policies which include a few variable 
parameters; however, it is expected that most clients will simply 
reference a validation policy for a given application or accept the CVP 
server's default validation policy.

2.1. Validation or discovery policy query.

For a validation or discovery policy request, the server MUST return 
the OIDs of the policies that are supported and MAY also return the 
details of some pre-defined simple policies. This protocol MUST be 
supported both by DPV and DPD servers.

2.2. Delegated Certificate Validation

Certificate Validation SHALL always be performed against a set of 
rules, called a validation policy.

If the CVP server does not support the client requested validation 
policy, then the CVP server MUST return an error.

If the CVP request does not specify a validation policy, the server 
response MUST indicate the validation policy that was used.

The client can request that the server determine the certificate 
validity at a time other than the current time. The time T may be close 
to the present time or a time in the past. When it is a time close to 
the present time, the CVP server MUST do its best efforts to perform 
the validation (validation may not be possible if the required data 
may not be collected). 

The support of validation in the past, using some data previously 
captured at the time of initial verification is optional. When 
supported, the server uses data that is provided by the requester 
which may be the validation data that has been previously returned when 
making an initial validation. This is called a re-validation. 

The CVP server MUST obtain revocation status information for the 
validation time in the client request.

If the revocation status information for the requested validation time 
is unavailable, then the CVP server MUST return a status indicating 
that the certificate is invalid. Additional information about the
reason for invalidity is also provided.

In order to obtain the revocation status information of any certificate 
from the certification path, the CVP server might use, in accordance 
with the validation policy, different sources of revocation 
information. For example, a combination of OCSP responses (see [OCSP]), 
CRLs, and delta CRLs could be used. Alternatively, a response from 
another CVP server could be used.


Pinkas                                                         [Page 2]

Internet Draft                   CVP                       October 2002


Unless, the request cannot be understood due to an error, the CVP 
response indicates one of the following status alternatives:

   1) the certificate is valid according to the validation policy,
   2) the certificate is not valid according to the validation policy,
   3) the validity of the certificate is unknown according to the 
      validation policy.

When the certificate is not valid according to the validation policy, 
then the reason MUST also be indicated. Invalidity reasons include:

   a) the CVP server successfully constructed a certification path, 
      but it was not valid according to the validation algorithm in 
      [RFC3280].

   b) the CVP server successfully constructed a certification path,
      cannot determine the validity of the certificate because 
      certificate revocation information as specified in the validation 
      policy is missing.

   c) the certificate is not valid at this time. If another 
      request could be made later on, the certificate could possibly 
      be determined as valid. This condition may occur before a 
      certificate validity period has begun or while a certificate is 
      suspended.

In order to be able to prove to a third party (that trusts the same CVP 
server) that a check has correctly been done, the client needs to 
present a CVP response. In order to keep the response as short as 
possible, only the important components from the request are copied in 
the response.

In order to be able to prove to a third party (that does not trust the 
same CVP server ) that a check has correctly been done, the client 
will require to get all the data that has been collected during the 
validation so that the test can be redone again using the same 
information, in a subsequent validation (called re-validation). 

In such a case the server will need to return that information, called 
validation data.

Validation data may (not necessarily exclusively) consist of a 
certification path, revocation status information from authorized CRL 
issuers or authorized OCSP responders, revocation status information 
from CRL issuers or OCSP responders trusted under the validation 
policy, time-stamp tokens (see [TSP]) from TSAs responders trusted 
under the validation policy, or a CVP response from a CVP server that 
is trusted under the validation policy. 

When the certificate is valid, the server MUST, upon request, include 
the validation data in the response. However, the server MAY omit that 
information when the certificate is invalid or when it cannot determine 
the validity.

Pinkas                                                         [Page 3]

Internet Draft                   CVP                       October 2002


2.3. Delegated Path Discovery

Delegated Path Discovery SHALL always be performed against a set of 
rules, called a discovery policy.

If the CVP server does not support the client requested discovery 
policy, then the CVP server MUST return an error.

If the CVP request does not specify a discovery policy, the server 
response MUST indicate the discovery policy that was used.

The certificate for which certification paths are requested MUST either 
be directly provided in the request or unambiguously referenced, such 
as the CA distinguished 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.

The CVP client MAY optionally provide to the validation server, 
associated with each certificate to be validated, useful certificates, 
as well as useful revocation information. Revocation information 
includes OCSP responses, CRLs, and delta CRLs. 

The CVP server MUST have the certificate for which certification paths 
are requested. When the certificate is not provided in the request, the 
server MUST obtain the certificate and then verify that the certificate 
is indeed the one being unambiguous referenced by the client. The CVP 
server MUST include either the certificate or an unambiguous reference 
to the certificate (in case of a CA key compromise) in the CVP 
response.

Unless, the request cannot be understood due to an error, the CVP 
response indicates one of the following status alternatives:

   1) one or more certification paths was found according to the 
      discovery policy, with all of the requested revocation 
      information present.

   2) one or more certification paths was found according to the 
      discovery policy, with a subset of the requested revocation
      information present.

   3) one or more certification paths was found according to the path
      discovery policy, with none of the requested revocation
      information present.

   4) no certification path was found according to the path discovery
      policy.






Pinkas                                                         [Page 4]

Internet Draft                   CVP                       October 2002


2.4. General

The following applies both for DPV and DPD requests.

The certificate to be validated or for which certification paths 
are requested MUST either be directly provided in the request or 
unambiguously referenced, such as the CA distinguished 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.

The CVP client MAY optionally provide to the validation server, 
associated with each certificate, useful certificates, as well as 
useful revocation information. 

Revocation information includes OCSP responses, CRLs, and delta CRLs. 
As an example, an S/MIME message might include such information, and 
the client can simply copy that information into the CVP request.

The CVP server MUST have the certificate to be validated or for which 
certification paths are requested. When the certificate is not provided 
in the request, the server MUST obtain the certificate and then verify 
that the certificate is indeed the one being unambiguous referenced by 
the client. The CVP server MUST include in its response either the 
certificate or an unambiguous reference to the certificate (in case 
of a CA key compromise) in the CVP response.

Server DPV responses and server DPD responses MAY be signed upon 
request from the client.

When a response is signed, then an unambiguous reference of the 
certificate from the CVP server MUST be included as one of the signed 
parameters. In this way, the CVP server's certificate authenticates the 
response.

Client requests MAY be signed. The CVP server MAY require client 
authentication, therefore, the CVP server MAY refuse the service if the 
request is not authenticated.

When a CVP request is authenticated, the client MAY include a client 
identifier in the request for the CVP server to copy into the response. 
Mechanisms for matching this identifier with the authenticated identity 
depends on local CVP server conditions and/or the validation policy. 
The CVP server MAY choose to blindly copy the identifier, omit the 
identifier, or return an error response.

When confidentiality is needed, this is not achieved at the level of 
this protocol and this may be achieved with a lower-layer security 
protocol, by taking into consideration the properties of the transport 
protocol.




Pinkas                                                         [Page 5]

Internet Draft                   CVP                       October 2002

In order to prevent against replay attacks, if the client has a local 
clock well synchronized with UTC, then the time of the response can be 
used to detect replay attacks; alternatively the client may generate a 
nonce that MUST then be copied by the server in its response.

Upon request, a text field provided by the client into the CVP response 
will be copied in the response. As an example, this field may relate to 
the nature or reason for the CVP query.

3. Policies

3.1. Validation Policy

A validation policy is a set of rules against which the validation of 
the certificate SHALL be performed. In order to succeed, one valid path 
(i.e. none of the certificates from the path must be revoked) must be 
found between a leaf certificate and a trust anchor.

A trust anchor is defined as a public key for a given CA name and 
valid during some time interval, a set of Certification Policy 
constraints and a set of naming constraints. The use of a self-signed 
certificate allows to specify at the same time: the public key to be 
used, the CA name and the validity period of the root key. Additional 
constrains MAY be included in the self-signed certificate.

Additional conditions that apply to the certificates from the chain, 
MAY also be specified in the validation policy rather than in the 
self-signed certificate itself.

3.2. Discovery policy

A discovery policy is a set of rules against which the discovery
of a certification path SHALL be performed. A path discovery policy 
MAY either be a reference to a discovery policy or contain only some 
major elements from a discovery policy, such as the trust anchors.

Since the DPD client SHALL be "PKI aware", it can locally apply 
additional selection criteria to the certification paths returned 
by the server. Thus, simpler policies can be defined and used for 
path discovery.

A discovery policy includes certification path requirements,
revocation requirements, and end-entity certificate specific
requirements. 

4.  Initial validation and re-validation