draft-ietf-pkix-cvp-01.txt

PKIX的RFC英文文档

   according to the validation policy for the validation time, this may 
   be a definitive invalidity (e.g. one of the certificates of the path 
   is revoked), because the revocation status of one of the 
   certificates cannot be obtained or because one of the certificates 
   is on hold at the time of validation. The minor status provides more 
   information.

   MinorStatus ::= CHOICE {
        missingRevocStatus  [0]     IMPLICIT NULL,
        tryLater            [1]     IMPLICIT TryLater,
        revokedInfo         [2]     IMPLICIT RevokedInfo
   }

missingRevocStatus indicates that revocation status information could 
not be obtained or the one that could be obtained was not up to date 
(e.g. an old CRL).

tryLater indicates the time at which another request could be 
attempted. At that time, the certificate could be determined as valid. 
As an example, this may be the case when a certificate is onHold.

   TryLater ::= GeneralizedTime

revokedInfo indicates the reason for the revocation.

   RevokedInfo ::= SEQUENCE {
       revocationTime               GeneralizedTime,
       revokedCert                  CertOrCertRef,
       revocationReason     [0]     EXPLICIT CRLReason   OPTIONAL
   }

Pinkas                                                        [Page 18]

Internet Draft                   CVP                       October 2002


For DPD:

   MajorStatus ::= CHOICE {
       requiredInfoPresent            [0]     IMPLICIT NULL,
       partialRequiredInfoPresent     [1]     IMPLICIT NULL,
       noRequiredInfoPresent          [2]     IMPLICIT NULL
   }

When requiredInfoPresent is present, this means that all the requested 
information has been found; hence at least one path has been able to 
constructed.

When the major status indicated that partialRequiredInfoPresent is 
present then the minor status provides more details:

   MinorStatus ::= CHOICE {
      noRevocationInformation              [0]     IMPLICIT NULL,
      subsetOfRevocationInformation        [1]     IMPLICIT NULL,
      caRevocationInfoMissing              [2]     IMPLICIT NULL,
      certificateRevocationInfoMissing     [3]     IMPLICIT NULL
   }

   noRevocationInformation indicates that no revocation information 
   is present.

   subsetOfRevocationInformation indicates that only a subset of 
   the requested revocation information is present.

   caRevocationInfoMissing indicates that the revocation status of all 
   or of some CAs is missing.

   certificateRevocationInfoMissing indicates that the revocation 
   status of the certificate that was the object of the query could 
   not be found.

certProcessed is the certificate to validate. It MUST be a copy of the 
field present in the request.

policy is either the validation or the discovery policy that has been 
used. It MUST be  a copy of the field present in the request, if that 
field was present. If the field was not present, it MUST be is the 
object identifier that has been used to perform the validation, and any 
parameters when applicable. The caller SHOULD make sure that the policy 
field matches either matches the valOrDiscoPolicy field from the 
Request, if present, or matches its expectations, if missing.

checks MUST be a copy of the corresponding field from the request. It 
allows to know what was the request type, without the need to keep a 
copy of the whole request.

serialNumber MUST be an integer which is unique for the CVP server and 
which thus may be used to unambiguously reference a response together 
with the certificate from the CVP server. 

Pinkas                                                        [Page 19]

Internet Draft                   CVP                       October 2002


producedAt is the time at which the response has been formed.

validationTime is the time in the past for which the validation has 
been performed. If that field was present in the request, then it SHALL 
be a copy of the field present in the request. If that field was 
missing in the request, then it SHALL be missing in the response.

requestHash is hash computed over all the parameters from Request. The 
hash algorithm is chosen by the CVP server.

cVPServerCert is the certificate under which the server is providing 
his signature. ESSCertID is defined in [RFC 2634].

requesterName is a copy of the requesterName present in the request, 
if that field matches one of the identifiers of the requester when the 
requester is authenticated.

requesterData MUST be a copy of the character string contained in the 
requesterData field from the request, if that field was present in the 
request.

validationDataHash SHALL be present when the validationData field from 
the IndividualResponse is present. In that case, it SHALL be computed 
on the hash of the DER encoding of when the validationData field from 
the IndividualResponse.

serverContextInfo, MUST only be present for a DPD response. It contains 
context for a request-response transaction. Since only one path at a 
time is being returned, the client can then use this value (and send 
the same query back to the server) and the server may be able to 
provide additional certification paths (if they may be found).

requestExtensions is a way to allow additional elements to be added 
later on, if needed. Some extensions are defined in section 7.

6. Definition of some simple validation policies

The validation policies which are defined here are very simplified. The 
validation algorithm shall be conformant with the algorithm defined in 
section 6.1 from RFC 3280. This means that all these simple policies 
have a single trust anchor.

Up to three parameters may be defined:

    - one self-signed certificate (trustanchor); 
      (this parameter is mandatory),
    - a set of Certificate Policy (acceptablePolicySet);
    - the length of the certification path (pathLenConstraint).

The validation policies are defined under the following arc:

   id-xy   OBJECT IDENTIFIER ::=  { XXXXXXXXXXXXXXXX }


Pinkas                                                        [Page 20]

Internet Draft                   CVP                       October 2002

6.1. Simple validation policy 1

This validation policy has the following characteristics:

 - the self-signed certificate starts (or ends) the certificate path 
   processing. It SHALL not contain extensions like basicConstraints.

 - the revocation requirements are as follows: for each certificate 
   from the path either a valid CRL or a valid OCSP response MUST be 
   obtained.

 - there are no Time-Stamping requirements.

 - there are no specific requirements on the certificate to be 
   validated.

This validation policy has the following OID:

   id-xX   OBJECT IDENTIFIER ::=  { XXXXXXXXXXXXXXXX }

6.2. Simple validation policy 2

This validation policy has the following characteristics:

 - the self-signed certificate SHALL not contain extension like 
   basicConstraints.

 - the revocation requirements are as follows: for each CA certificate 
   from the path a valid CRL MUST be obtained. For the certificate 
   under test, if that certificate is a CA certificate then a valid CRL 
   MUST be obtained, whereas if that certificate is an end-entity 
   certificate then a valid OCSP response MUST be obtained.

 - there are no Time-Stamping requirements.

 - there are no specific requirements on the certificate to be 
   validated.

This validation policy has the following OID:

   id-yy   OBJECT IDENTIFIER ::=  { XXXXXXXXXXXXXXXX }

7. Extensions to support relaying and re-direction

In some network environments, especially ones that include firewalls, 
a CVP server might not be able to obtain all of the information that 
it needs to process a request. However, the CVP server might be 
configured to use the services of one or more other CVP servers to 
fulfill all requests. In such cases, the client is unaware that the 
queried CVP server is using the services of other CVP servers, and 
the client-queried CVP server acts as a CVP client to another CVP 
server. Unlike the original client, the CVP server is expected to have 
moderate computing and memory resources, enabling the use of relay, 
re-direct or multicasting mechanisms. 

Pinkas                                                        [Page 21]

Internet Draft                   CVP                       October 2002


The features mentioned in this section support CVP server-to-CVP server 
exchanges without imposing them on CVP client-to-CVP server exchanges.

All these features are provided using non-critical extensions that are 
included either in requests or responses.

Each extension is associated with an OID.  These OIDs are members of 
the id-xy arc, which is defined by the following:

   id-xy   OBJECT IDENTIFIER ::=  { XXXXXXXXXXXXXXXX }

For relaying, the CVP server must leave a trace that it has relayed the 
request, in case, the request is relayed back. This information will 
allow to detect and stop loops. Ordinary servers may ignore this 
extension, since it is non-critical. However server that supports 
relaying using that protocol MUST understand and process that 
extension.

For referrals, the CVP server may provide in the response additional 
information specifying the referrals. Since the extension is non 
critical, it may be ignored by the client.

7.1. Extensions for relaying

This extension may only be present in a the requestExtensions field 
from a Request.

This extension MUST NOT be marked critical.

   id-xy-relaying OBJECT IDENTIFIER ::=  { id-xy Z }

   Relaying ::= SEQUENCE OF RelayInfo

RelayInfo ::= ESSCertID

RelayInfo allows to unambiguously identify the CVP server. 

When a CVP server wishes to relay a request towards another CVP server 
using this protocol, then, for each single request, it SHALL support 
the relaying extension.

If a relaying extension was present in the request, then an additional 
RelayInfo SHALL be added to the content of the Relaying extension and 
included in the next request.

If a Relaying extension was not present in the request, then a Relaying 
extension field shall be created and included in the next request.

When a CVP server receives a request that includes a Relaying 
extension, then :

   - if it does not support relaying, the processing can continue.


Pinkas                                                        [Page 22]

Internet Draft                   CVP                       October 200


   - if it supports relaying, it SHALL check if its identifier is 
     present in any of the RelayInfo data:

        - If this is not the case, then there is no loop and 
          ordinary processing can continue. 

        - If this is the case, then there is a loop and it shall
          return to the caller an unknown major status in order 
          to stop the loop. 

7.2. Extensions for referrals

This extension may only be present in a responseExtensions field from 
IndividualResponseData.

   This extension MUST NOT be marked critical.

   id-xy-referrals OBJECT IDENTIFIER ::=  { id-xy W }

   Referrals ::= SEQUENCE OF Referral

Referral ::= GeneralName

Referral is defined as a GeneralName, which can take several forms.

   Where the information is available via http, then it MUST be 
   a uniformResourceIdentifier.  

   Where the information is available via electronic mail, it MUST be 
   an rfc822Name. 

The client may ignore this extension, since it is non-critical or may 
use it to access another CVP server.

8.  Transports

There is no mandatory transport mechanism. However one of the three 
transport mechanisms described in this document MUST be supported.

8.1. CVP via sockets

The following simple TCP-based protocol is to be used for transport of 
CVP messages.  This protocol is suitable for cases where an entity 
initiates a transaction and can poll to pick up the results.

The protocol basically assumes a listener process on a CVP server that 
can accept CVP messages on a well-defined port (IP port number XXX).

Typically an initiator binds to this port and submits the initial CVP 
message.  The responder replies with a CVP message and/or with a 
reference number to be used later when polling for the actual CVP 
message response.


Pinkas                                                        [Page 23]

Internet Draft                   CVP                       October 2002


The initiator of a transaction sends a "direct TCP-based CVP message"
to the recipient.  The recipient responds with a similar message.

A "direct TCP-based CVP message" consists of:

         length (32-bits), flag (8-bits), value (defined below)

The length field contains the number of octets of the remainder of the 
message (i.e., number of octets of "value" plus one).  All 32-bit
values in this protocol are specified to be in network byte order.

   Message name   flag     value