view Side-By-Side changes

draft-ietf-pkix-dpv&dpd-req-01.txt Bull
draft-ietf-pkix-dpv-dpd-req-02.txt       Russ Housley, RSA Laboratories
Target Category: INFORMATIONAL                             January                            February 2002
Expires in six months 


        Delegated Path Validation and Delegated Path Discovery 
                   Protocol Requirements (DPV&DPD-REQ)
                   <draft-ietf-pkix-dpv-dpd-req-01.txt>
                   <draft-ietf-pkix-dpv-dpd-req-02.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.

Abstract

This document specifies the requirements for Delegated Path Validation 
(DPV) and Delegated Path Discovery (DPD). It also specifies the 
requirements for DPV and DPD policy management.

1. Introduction

This document specifies the requirements for Delegated Path 
Validation (DPV) and Delegated Path Discovery (DPD), using two main 
request/response pairs.

These delegated processing provides two primary services: DPV and DPD. 
Some clients require a server to perform path validation and have no 
need for data acquisition, while some other clients require only DPD 
in support of local path validation.

The first one, called Delegated Path Validation (DPV), DPV request/response pair, can be used to fully delegate a path 
validation processing to an DPV server, according to a set of rules, 
called a validation policy. 

The second one, called Delegated Path Discovery (DPD), DPD request/response pair can be used to obtain from a DPD server 
all the information needed (e.g., the end-
entity end-entity certificate, the CA 
certificates, full CRLs, delta-CRLs, OCSP responses) to locally 
validate a certificate. The DPD server uses a set of rules, called 
a path discovery policy, to determine which information to return. 

Pinkas, Housley                                                [Page 1]

Internet Draft               DPV&DPD-REQ                   January 2002

A third request/response pair can be used to allow clients to obtain 
the references for the policies supported by a DPV or DPD server.

This document also defines the requirements for two optional 
request/response request/
response pairs. The first one is used to establish a validation policy 
with a DPV server. The second one is used to establish a discovery 
policy with a DPD server. Either request/response pair provide a 
reference of an existing policy to obtain policy details.

Pinkas                                                         [Page 1]

Internet Draft               DPV&DPD-REQ                   January 2002

1.1. Terminology

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

1. Rationale and benefits

These delegated processing provides two primary services: delegated 
path validation and delegated path discovery. Some clients require 
a server to perform path validation and have no need for data 
acquisition, while some other clients require only delegated path 
discovery in support of local path validation.

2. Rationale and benefits for DPV (Delegated Path Validation)

DPV allows a server to perform a real time certificate validation for 
a validation time T, where T may be the current time or a time in the 
recent past, 
for any certificate in support of any security service. past. 

In order to validate a certificate, a chain of multiple certificates, 
called a certification path, may be needed, comprising a certificate 
of the public key owner (the end entity) signed by one CA, and zero or 
more additional certificates of CAs signed by other CAs.

Offloading path validation to a server may be required by a client 
that lacks the processing, and/or communication capabilities to 
perform path construction first and then a local path validation.

In constrained execution environments, such as telephones and PDAs, 
memory and processing limitations may preclude local implementation of 
complete, PKIX-compliant path validation.

In applications where minimum latency is critical, delegating 
validation to a trusted server can offer significant advantages.
The time required to send the target certificate to the validation 
server, receive the response, and authenticate the response, 
can be considerably less than the time required for the client to 
perform certification path discovery and validation. Even if a 
certification path were readily available to the client, the 
processing time associated with signature verification for each 
certificate in the path might (especially when validating very long 
paths or using very limited processor speed) be greater than the delay 
associated with use of a validation server.

Another motivation for offloading path validation is that it allows 
validation against validation policies defined by the management in a 
consistent fashion across an enterprise. Clients that are able to 
do their own path validation may rely on a trusted server to do path 
validation if centralized management of validation policies is needed, 
or the clients rely on a trusted server to leave centralized traces 
of such activities.



Pinkas

Pinkas, Housley                                                [Page 2]

Internet Draft               DPV&DPD-REQ                   January 2002

When a client uses this service, it inherently trusts the server as 
much as it would its own path validation software (if it contained 
such software). Clients can direct the server to perform path 
validation in accordance with a particular validation policy.

3. Rationale and benefits for DPD (Delegated Path Discovery)

DPD is valuable for clients that do much of the PKI processing 
themselves and simply want a server to collect information for them. 
The server is trusted to return the most current information that is 
available to it (which may not be the most current information that 
has been issued). The client will ultimately perform certification 
path validation.

A client that performs path validation for itself may get benefit in
several ways from using a server to acquire certificates, CRLs, and 
OCSP responses to aid in the validation process. In this context, the 
client is relying on the server to interact with repositories to 
acquire the data that the client would otherwise have to acquire using 
LDAP [LDAP], HTTP [HTTP], FTP [FTP] or another repository access 
protocol. Since these data items are digitally signed, the client need 
not trust the server any more than the client would trust the 
repositories. 

There are several benefits to this approach; for example, a single 
query to a server can replace multiple queries to one or more 
repositories, and caching by the server can reduce latency. Another 
benefit to the client system is that it need not incorporate a diverse 
set of software to interact with various forms of repositories, 
perhaps via different protocols, nor to perform the graph processing 
necessary to discover certification paths, separate from making the 
queries to acquire path validation data.

4. Delegated Path Validation policy and path discovery policy

Policies MAY be Protocol Requirements

The Delegated Path Validation (DPV) protocol allows a priori known by the server, server to 
validate one or policies MAY be 
specified by a client more certificates according to the server.

Because a validation software is controlled by many parameters which, 
if incorrectly set, may result in insecure behavior, it is useful
to rely on pre-defined policies that are already known by policy. 
If the servers, 
where system security administrators carefully manage them. 

Both services (delegated path DPV server does not support the client requested validation and delegated path discovery) 
can be potentially used by 
policy, then the DPV server MUST return an enterprise for enforcing various aspects 
of centralized policies.

Alternatively, system security administrators MAY also define policies.
However, such error.

The client can request that the server determine the certificate 
validity at a time other than the current time. Depending upon the 
validation policy definition being used, the validation time may either be quite complex and only some 
forms of policies can be defined in this way, otherwise testing all the possible variations would lead 
time for which the revocation status information has to non-interoperable implementations be obtained, 
or would increase the time necessary to ensure that two implementations 
are interoperable.


Pinkas                                                         [Page 3]

Internet Draft               DPV&DPD-REQ                   January 2002 for which the event for which the validity is tested took 
place.

Since policy definitions can be quite long and complex, all the 
parameters SHOULD NOT be passed with each individual request; rather, 
they SHOULD be defined using a separate policy definition 
request/response pair. In request/
response pair (see section 9). In this way clients only need to a successful policy definition 
request, be 
aware of the server SHALL return a policy reference (e.g. an OID).

However, some forms of path discovery the validation policy can be simple. In 
that case it MAY to be acceptable used by a given 
application.


Pinkas, Housley                                                [Page 3]

Internet Draft               DPV&DPD-REQ                   January 2002


The certificate to pass the parameters from be validated MUST either be directly provided in 
the path 
discovery policy with each individual request, i.e. a set of trust 
anchors and separate revocation status conditions for request or an unambiguous reference MUST be provided, such as 
the end-entity CA distinguished name, certificate serial number, and for the other certificates (see section 9.2).

The protocol SHALL allow clients to obtain, at any time, the references
for all hash 
of the policies supported by the server by using an additional 
request/response pair. The response can include references to previously certificate, like ESSCertID as defined policies in [ESS] or to a priori known policies.

4.1. Validation Policy

A validation policy is a set of rules against which the validation of 
the certificate is performed. 

A validation policy MAY include several trust anchors. A trust anchor 
is defined 
OtherSigningCertificate as one public key, a CA name, a validity time interval, and 
optionally additional constrains. defined in [ES-F].

The use of a self-signed certificate 
is one way client MUST be able to specify together: the public key provide to be used, the CA 
name, and the validity period of the public key. 

Additional constrains for validation server, 
associated with each trust anchor MAY certificate to be defined. These 
constraints validated, "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 a set of Certification Policy constraints or 
a set of naming constraints. These constrains MAY also be included in 
self-signed certificates.

Additional conditions that apply to the certificates in the path MAY 
also be specified in such information, and the validation policy. For example, specific 
values for user-initial-policy-set, initial-policy-mapping-inhibit, 
initial-explicit-policy, or initial-any-policy-inhibit could be 
provided.

Additional conditions 
client can simply copy that apply to information into the end-entity certificate MAY 
also be specified in DPV request.

The server MUST get the validation policy. For example, a specific 
name form, like an e-mail address either full certificate. If not provided in the rfc822 subject 
alternative name or in 
request, the emailAddress naming attribute in server MUST use the 
subject name, might be required. unambiguous reference provided by the 
client to obtain it.

In order to succeed, one valid certification path (i.e., none of the 
certificates in obtain the path are expired or revoked) MUST be found between 
an end-entity revocation status information of any 
certificate and a trust anchor and all constraints that 
apply to from the certification path MUST be verified.

Validation policies support security services path, the DPV server might use, in two time contexts:

   - for immediate use (e.g., to use 
accordance with the public key within validation policy, different sources of revocation 
information, e.g. a 
     certificate for symmetric key management), combination of OCSP responses, CRLs, or

Pinkas                                                         [Page 4]

Internet Draft               DPV&DPD-REQ                   January 2002

   - for delta-CRLs.

If the DPV request does not specify a time T in validation policy, the recent past (e.g., to use server 
response MUST indicate the public key 
     within a certificate to verify data origin authentication and 
     integrity).

There is an inevitable delay between one that was used. In such a compromise of key being noticed 
by case, the end-entity and 
client MUST verify that the report of revocation being made one selected by the CA 
(or on behalf server is appropriate.

The DPV response MUST indicate one of four status alternatives:

   1) the CA) certificate is valid according to the relying parties. This delay exists 
even when an OCSP service validation policy.

   2) the certificate is used. So, querying definitively invalid according to the 
      validation policy.

   3) the revocation status 
of a certificate is not yet valid at a time T never proves that this time. If another 
      request could made later on, the private key 
corresponding to that certificate was not compromised could possibly be 
      determined as valid. This condition will occur before a 
      certificate validity period has begun, while a certificate is 
      suspended, or when, at that the time T. 

A the server generated the 
      response, all conditions of the validation policy MAY support could not be 
      met.

   4) the server cannot determine the validity of the certificate.
      This condition will occur when a cautionary period in order to certification path cannot be 
      constructed or some revocation information is unavailable.

The DPV request MUST allow 
time for:

   1) the end-entity client to realize that one of its private keys has been 
      or could possibly be compromised, 

   2) request the end-entity response to report the key compromise,

   3) 
include the certification path and revocation authority status information used 
by the server to process the revocation request from 
      the end-entity, and

   4) request. When requested, the revocation authority to make available server MUST 
include the certification path and revocation status information, e.g. by providing an OCSP service, CRLs, 
      or delta-CRLs information in combination with full CRLs.

When 
the public key within response when the certificate is used immediately, it is 
not possible valid according to apply a cautionary period, the validation 
policy. However, the server MAY omit the certification path and thus, some risk 
revocation status information when the certificate is 
taken, since invalid, not yet 
valid or when it cannot determine the corresponding private key might validity.

Pinkas, Housley                                                [Page 4]

Internet Draft               DPV&DPD-REQ                   January 2002

In order to be compromised at able to be confident that the 
time validation of use.

When the public key within the 
certificate is used to verify some 
usage from has correctly been done, the recent past, it is possible client only requires an 
authenticated response. 

In order for the client to apply a cautionary 
period prove to further reduce another party that trusts the risk. In such 
same DPV server that the certificate validation was correct, the 
client requires a case, signed response. All the policy MAY 
indicate parameters needed to prove 
that the response conforms to the request SHALL be copied from the 
request into the response, so that a minimum delay response is self-sufficient proof.

The server may require client authentication. The authentication 
method to be observed between the time T in the past,
i.e. when the use of used may be dependant upon the private key took was supposed to take place, transport used, and thus 
the time client authentication mechanism need not be an integral part of 
the current verification.

When DPV request.

5. Delegated Path Discovery Protocol Requirements

The Delegated Path Discovery (DPD) protocol allows the end-entity certificate expires before client to use 
a single protocol towards a single server to collect at one time 
the cautionary period 
terminates, then data elements available at the end-entity certificate MUST current time that might be considered as 
invalid. According 
collected using different protocols (e.g. LDAP, DAP, OCSP) or by 
querying multiple servers, according to section 3.3. Revocation from [PKIX-1] "An entry 
may a single path discovery policy.
Then returned information can be removed from the CRL after appearing on used to locally validate one regularly scheduled 
CRL issued beyond or more 
certificates for the revoked certificate's validity period", so current time. 

Clients MUST be able to specify whether they want, in 
that case addition to the 
certification path, the revocation status information is not guaranteed to be 
available at associated with the end of 
path, for the cautionary period. If end-entity certificate only, for the CA certificates are 
not used close to 
only or for both.

If the end of their validity period, then this 
situation will DPD server does not happen. This means that new certificates should be 
issued before support the end of client requested path 
discovery policy, the validity period DPD server MUST return an error. Some forms 
of path discovery policy can be simple. In that case it is acceptable 
to pass the current 
certificate and with a time interval greater than parameters from the cautionary 
period.





Pinkas                                                         [Page 5]

Internet Draft               DPV&DPD-REQ                   January 2002


4.2. Path discovery policy

A path discovery policy is with each 
individual request, i.e. a set of rules against which trust anchors and separate 
revocation status conditions for the discovery 
of a certification path is performed. A end-entity certificate and for 
the other certificates. More elaborated path discovery policy is policies SHOULD 
be defined using a 
subset separate policy definition request/response pair 
(see section 9). Most of a validation policy. A the time, clients only need to be aware of 
the reference of the path discovery policy MAY either be 
a reference to be used by a validation policy given 
application.

The server response includes zero, one, or contain only some major elements 
from several certification 
paths. Each path consists of a validation policy, such as sequence of certificates, starting with 
the certificate to be validated and ending with one issued by a trust anchors. 

Since 
anchor. The trust anchor self-signed certificate, if issued, is not 
included. In addition, if requested, the revocation information 
associated with each certificate in the path MUST also be returned.

The client needs to be able to limit the number of paths returned. 
Therefore the client must MUST be "PKI aware", it can locally apply additional 
constraints able to indicate the maximum number of 
certification paths that SHOULD be returned by the server. Thus, 
a "crude" (i.e. simpler) criteria (provided that they can be defined and used for DPD.

5. Delegated Path Validation Protocol Requirements

The Delegated Path Validation (DPV) protocol allows a server to 
validate one or more certificates according to a validation policy. 
A time other than 
found). If the current time number is not specified, that number defaults to one. 


Pinkas, Housley                                                [Page 5]

Internet Draft               DPV&DPD-REQ                   January 2002


The paths that are returned may be used need to determine the 
validity. The validation policy SHALL be known match some additional local 
controls done by the DPV server. client, e.g. verifying some certificate 
extensions. 

The validation policy MAY returned paths may not be defined using an additional request/
response pair (see section 10) prior appropriate to the DPV request. In this way 
clients only need to be aware client when it 
locally applies additional tests. Instead of asking one by one the reference of 
paths (which would require state information at the validation 
policy to be used by a given application.

The certificate to be validated MUST either be directly provided in server), the 
client specifies with every request or an unambiguous reference MUST be provided, such as 
the CA distinguished name, certificate serial number, and the hash maximum number of the certificate, like ESSCertID as defined in [ESS] or 
OtherSigningCertificate as defined in [ES-F].

The client MUST be able to provide paths 
to be returned.

If that number cannot be reached by 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. As an example, indication SHOULD 
be returned by the server showing that an S/MIME message 
might include such information, and additional query will not 
return more paths.

If the client can simply copy paths that 
information into are returned do not match the DPV request.

In order to obtain local conditions, then 
the revocation status information number of any 
certificate from number of certification paths to be returned can be 
extended, by augmenting this value. Previously found paths will likely 
be returned, but the certification path, client can easily discard them. This avoids 
requirements for state information at the DPV server, but does not prevent 
a server might use, in 
accordance with from maintaining a cache of previous responses.

Avoiding the validation policy, different sources maintenance of revocation 
information, e.g. a combination state information for previous requests 
minimizes potential denial of OCSP responses, CRLs, service attacks or delta-CRLs.

If the DPV request does not specify a validation policy, the other problems 
associated with server 
response crashes.

Path discovery MUST indicate the one that was used. In such a case, the 
client must verify that the one selected by be performed according to the server is appropriate. path discovery policy. 

The DPV DPD response MUST indicate one of four status alternatives:

   1) the certificate is valid according to the validation policy.

   2) the certificate is definitively invalid one or more certification paths was found according to the 
      validation policy.



Pinkas                                                         [Page 6]

Internet Draft               DPV&DPD-REQ                   January 2002


   3) the certificate is not yet valid at this time. If another 
      request could made later on, the certificate could possibly be 
      determined as valid. This condition will occur before a 
      certificate validity period has begun, while a certificate is 
      suspended, or when the validation is made at a time where the 
      cautionary period has not yet ended. 

   4) the server cannot determine the validity 
      path discovery policy, with all of the certificate.
      This condition will occur when a certification path cannot be 
      constructed or some requested revocation 
      information is unavailable.

The DPV request MUST allow the client present.

   2) one or more certification paths was found according to request the response to 
include 
      path discovery policy, with a subset of the certification path and requested revocation status 
      information used 
by the server present.

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

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

The information that is returned consists of one or more certification 
paths and optionally its associated revocation status information in for 
each element from the response when path. 

To provide confidence that the certificate is valid according to response originates from the validation 
policy. However, DPD server,
the server MAY omit provide an authenticated response. For example, the certification path 
server might sign the response.



Pinkas, Housley                                                [Page 6]

Internet Draft               DPV&DPD-REQ                   January 2002

6. Requirements common both to DPV and 
revocation status information when DPD

The protocol SHALL allow clients to obtain the certificate is invalid references
for all of the policies supported by the server by using an additional 
request/response pair. The response can include references to previously 
defined policies or 
when to a priori known policies.

7. Rationale and benefits for PDP (Policy Definition Protocol)

Policies can be a priori known by the server, or policies can be 
specified by a client to the server.

Because policies are controlled by many parameters which, 
if incorrectly set, can result in insecure behavior, it cannot determine is useful
to rely on pre-defined policies that are already known by the validity.

In order clients and the 
servers, 
Such policies are likely to be able to defined by system security 
administrators who carefully manage them. 

However, policy definitions may be confident that quite complex and only some 
forms of policies can be defined using the request/response pair.

7.1. Validation Policy

A validation policy is a set of rules against which the 
certificate has correctly been done, the client only requires an 
authenticated response. 

In order for the client to prove to another party that trusts the 
same DPV server that validation of 
the certificate is performed. 

A validation was correct, the 
client requires policy MAY include several trust anchors. A trust anchor 
is defined as one public key, a signed response. All the parameters needed to prove 
that the response conforms to the request SHALL be copied from the 
request into the response, so that CA name, a response is self-sufficient proof.

The server may require client authentication. validity time interval, and 
optionally additional constrains. The authentication 
method use of a self-signed certificate 
is one way to be used may be dependant upon specify together: the transport public key to be used, the CA 
name, and thus the client authentication mechanism need not be an integral part validity period of the DPV request.

6. Delegated Path Discovery Protocol Requirements

The Delegated Path Discovery (DPD) protocol allows the client to use public key. 

Additional constrains for each trust anchor MAY be defined. These 
constraints might include a 
single protocol towards set of Certification Policy constraints or 
a single server to collect at one time all the 
data elements that might set of naming constraints. These constrains MAY also be collected using different protocols (e.g. 
LDAP, DAP, OCSP) or by querying multiple servers, according included in 
self-signed certificates.

Additional conditions that apply to a 
single the certificates in the path discovery MAY 
also be specified in the validation policy. Then returned information can For example, specific 
values for user-initial-policy-set, initial-policy-mapping-inhibit, 
initial-explicit-policy, or initial-any-policy-inhibit could be used 
provided.

Additional conditions that apply to 
locally validate one or more certificates for the current time. 

Clients MUST end-entity certificate MAY 
also be able to specify whether they want, specified in addition to the 
certification path, validation policy. For example, a specific 
name form, like an e-mail address either in the revocation information associated with rfc822 subject 
alternative name or in the 
path, for emailAddress naming attribute in the end-entity certificate only, for 
subject name, might be required.

In order to succeed, one valid certification path (i.e., none of the CA 
certificates 
only or for both.

The in the path discovery policy are expired or revoked) MUST be known by the DPD server. The path 
discovery policy MAY defined using found between 
an additional request/response pair
(see section 7) prior end-entity certificate and a trust anchor and all constraints that 
apply to the DPD request.


Pinkas certification path MUST be verified.

Pinkas, Housley                                                [Page 7]

Internet Draft               DPV&DPD-REQ                   January 2002

The server response MUST include zero, one, or several certification 
paths. Each path consists of

There is an inevitable delay between a sequence compromise of certificates, starting with key being noticed 
by the certificate to be validated end-entity and ending with one issued the report of revocation being made by a trust 
anchor. The trust anchor self-signed certificate, if issued, the CA 
(or on behalf of the CA) to the relying parties. This delay exists 
even when an OCSP service is used. So, querying the revocation status 
of a certificate at a time T does not 
included. prove that the private key 
corresponding to that certificate was not already compromised at an 
earlier time T' where the private key has been used. 

In addition, case of a key compromise, the absolute difference between the time 
where a private key (corresponding to a given end-entity certificate) 
has been used and the time for which the revocation status information associated with 
each 
of that end-entity certificate in is available for the path MUST also be returned, if it time of use is 
composed of the sum of several time intervals: 

   1) the end-entity realizes that its private key has been 
requested.

The client needs to 
      or could possibly be able to limit compromised, 

   2) the number of paths returned. 
Therefore end-entity reports the client MUST be able to indicate key compromise,

   3) the maximum number revocation authority processes the revocation request from 
      the end-entity, and

   4) the revocation authority makes available the revocation 
      status information, e.g. by providing an OCSP service, CRLs, 
      or delta-CRLs in combination with full CRLs.

The sum of 
certification paths that SHOULD be returned (provided that they can be 
found). If all these time intervals is called a cautionary period.
When the number public key within the certificate is not specified, that number defaults to one. 

The paths that are returned may need used to match verify some additional local 
controls done by 
usage from the client, e.g. verifying some certificate 
extensions. The returned paths recent past, it is possible to apply a cautionary 
period. This cautionary period may not be appropriate to applied either by the client 
when or 
by the server. 

When it locally applies additional tests. Instead of asking one is applied by 
one the paths (which would require state information at client, the server), policy will consider the client specifies with every request time at 
which the maximum number of paths validity has to be determined as being directly the time for 
which the revocation status information has to be returned.

If that number cannot be reached obtained.

When it is applied by the server, an indication SHOULD 
be returned by the server showing that an additional query policy will not 
return more paths.

If the paths that are returned do not match consider the local conditions, then time at 
which the number of number of certification paths validity has to be returned can be 
extended, by augmenting this value. Previously found paths will likely determined as being time when the private 
key (corresponding to the given end-entity certificate) was supposed 
to be returned, but used, i.e. the client can easily discard them. This avoids 
requirements time for state information at which the server, but does not prevent 
a server from maintaining a cache of previous responses.

The goal event for which the validity 
is to avoid be tested took place. In such a case, the maintenance of state information for previous 
requests: if this is done, it minimizes potential denial policy includes 
the definition of service 
attacks or other problems associated with server crashes. a cautionary period.

7.2. Path discovery MUST be performed according to the policy

A path discovery policy. 

The DPD response MUST indicate one policy is a set of four status alternatives:

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

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

   3) one or more certification paths was found according to the a validation policy. A path discovery policy MAY either be 
a reference to a validation policy or contain only some major elements 
from a validation policy, with none of such as the requested revocation 
      information present.

   4) no certification path was found according trust anchors. 

Since the DPD client is "PKI aware", it can locally apply additional 
constraints to the path 
      discovery criteria.

Pinkas certification paths returned by the server. Thus, 
a simpler criteria can be defined and used for DPD.

Pinkas, Housley                                                [Page 8]

Internet Draft               DPV&DPD-REQ                   January 2002


The information that is returned consists of one or more certification 
paths and optionally its associated revocation status information for 
each element from the path. 

To provide confidence that the response originates from the DPD server,
the server MAY provide an authenticated response. For example, the 
server might sign the response.

7.


8. Policy definition protocol Definition Protocol (PDP) requirements

The support of these request/response pairs is OPTIONAL, or they might 
be implemented in a separate protocol from DPD or DPV.

These request/response pairs allow the client to define a policy, 
i.e. a validation policy and/or a path discovery policy, and to 
receive back a reference for that policy. The server may provide a 
reference to a previously defined policy, if it fulfills the request 
requirements.

The support of these request/response pairs is OPTIONAL, or they might 
be implemented in a separate protocol from DPD or DPV. 

The policies locally defined at the server may can be more precise than 
the policies defined using these request/response pairs, since such an 
exchange will not have all the flexibility necessary to describe any 
kind of policy. So, in practice, these request/response pairs will be 
restricted to the definition of relatively simple policies.

Usually, these request/response pairs will be used by security managers to 
register the policies to be used by ordinary clients, such as those 
within an organization for use with various applications.

Policy definition requests SHALL MUST be able to be authenticated so that 
only authorized clients can register policies.

Policy definition response, if successful, SHALL MUST return a policy 
reference. The policy reference MAY be specific to the request, or 
it MAY be a reference to a policy that has already been established 
and fulfills the request requirements.

It is up to server to decide how long a temporary defined policy defined through this 
protocol will be maintained.

When a obtaining a policy reference from the server, it would be 
interesting to consider providing natural language information about 
the purpose of the policy, rather than the technical description of 
the policy.

When using DPV, there are two possibilities:

   a) The client is PKI-unaware, and thus fully delegates the 
      validation to the server. It appears more difficult to remotely 
      define such "complete policies" since the tests on the end-entity 
      certificate are made by the server and may be quite complex.

   b) The client is a little bit slightly PKI-aware, in the sense that it is 
      only able to parse the end-entity certificate to check some 
      properties of a certificate, and delegates the validation of the 
      rest of the path to the server. It appears easier to remotely 
      define such "partial policies" since some tests on the end-
      entity certificate are left to the client.

Pinkas                                                         [Page 9]

Internet Draft               DPV&DPD-REQ                   January 2002


   b) The client is fully PKI-unaware, and thus fully delegates the 
      validation to the server. It appears more difficult to remotely 
      define such "complete policies" since the some tests on the end-
      entity certificate are made by left to the server and may be quite complex.

When using DPD, simpler validation policies may be defined since 
all DPD clients are fully PKI-aware.

8. client.




Pinkas, Housley                                                [Page 9]

Internet Draft               DPV&DPD-REQ                   January 2002


8.1 Components for a validation policy

A validation policy is build from four components:

   1. Certification path requirements,
   2. Revocation requirements,
   3. End-entity certificate specific requirements,
   4. optionally, cautionary period requirements.

Note: [ES-P] defines ASN.1 data elements that may be useful while 
defining the components of a validation policy.

8.1.

8.1.1. Certificate chain requirements

The PDP protocol MUST allow the client to specify certification path 
requirements. The path requirements identify a sequence of trust 
anchors used to start certification path processing and initial 
conditions for certification path validation as defined in [PKIX-1]. 

8.2. 

8.1.2. Revocation Requirements

The PDP protocol MUST allow the client to specify revocation checking 
requirements. Revocation information may be obtained through CRLs, 
delta-CRLs or OCSP responses. Certificate revocation requirements are 
specified both in terms of checks required on the end-entity 
certificate (i.e. the certificate for which a path is required) and on 
checks required on CA certificates.

Revocation requirements for the end-entity certificate may not be the 
same as the requirements for the CA certificates. For example, an OCSP 
response may be needed for the end-entity certificate while CRLs may 
be sufficient for the CA certificates. Therefore, the PDP protocol 
MUST allow the client to specify separate requirements for the 
end-entity certificate and for the CA certificates.

The PDP protocol MUST allow the client to specify the source of 
revocation information, in particular if :

   - full CRLs (or full Authority revocation lists) have to be 
     collected,

   - OCSP responses, using [OCSP], have to be collected,

   - delta-CRLs and the relevant associated full CRLs (or full 
     Authority revocation lists) are to be collected.

Pinkas                                                        [Page 10]

Internet Draft               DPV&DPD-REQ                   January 2002

   - any available revocation information has to be collected.

8.3.

8.1.3. End-entity certificate specific requirements

The PDP protocol MUST allow the client to specify requirements that 
apply only to the end-entity certificate (i.e. the certificate that 
is the object of the query).

Pinkas, Housley                                               [Page 10]

Internet Draft               DPV&DPD-REQ                   January 2002

The client might require the end-entity certificate to contain 
specific extensions with specific types or values (it does not matter 
whether they are critical or non-critical). 

For example, the client might need an end-entity certificate that 
contains an electronic mail address (either in the rfc822 subject alt 
name or in the emailAddress naming attribute in the subject name).

8.4.

8.1.4. Cautionary period requirements

The PDP protocol SHALL allow the client to specify a cautionary period 
for a validation policy. The cautionary period specifies a minimum 
delay to be observed between a time T in the recent past, where the 
use of the private key or the public key is supposed to take place, 
and the time of the current validation.

9. production of revocation status information.

8.2. Components for a path discovery policy

The PDP protocol SHALL be able to support certification path 
requirements and revocation requirements. It MAY support end-entity 
certificate specific requirements. These requirements are specified in 
sections 8.1, 8.2, 8.1.1, 8.1.2, and 8.3, 8.1.3, respectively.

10.

9. DPV versus DSV

DPV performs the validation of a certificate against a policy, but 
does not necessarily provide all the information needed to prove to 
someone else that is not trusting the same DPV server that a digital 
signature from a signer was produced while the signer's certificate 
was valid. 

A Delegated Signature Validation (DSV) service could be specified to 
allow to prove later on to someone else, not trusting the same DSV 
server, that a digital signature was applied while the certificate 
was valid. Requirements for a Delegated Signature Validation (DSV) 
service that allows to fully delegate the validation of a digital 
signature to a DSV server might be addressed in a separate document at 
a future time. 

11. 

10. Security considerations

A client must trust a DPV server to provide the correct answer. 
However, this does not mean that all clients will trust the same 
servers. While a positive answer might be sufficient for one client, 
that positive answer will not necessarily convince another client. 

Pinkas                                                        [Page 11]

Internet Draft               DPV&DPD-REQ                   January 2002 

Other clients may trust their own servers, or they might perform 
certification path validation themselves. Clients operating under 
an organizational policy must ensure that each of the servers they 
trust is operating under that organizational policy. 

12. 

According to section 3.3 of [PKIX-1]: "An entry may be removed from 
the CRL after appearing on one regularly scheduled CRL issued beyond 
the revoked certificate's validity period". When the difference 

Pinkas, Housley                                               [Page 11]

Internet Draft               DPV&DPD-REQ                   January 2002

between the end of the validity period of the end-entity certificate 
and the time of the event for which the validity is to be tested is 
smaller than the cautionary period, then the end-entity certificate 
must be considered as invalid, since it is not guaranteed to be able 
to get the revocation status information of that certificate. If 
certificates are not used close to the end of their validity period, 
then this situation will not happen.

This means that new certificates should be issued and used before the 
end of the validity period of the current certificate and with a time 
interval greater than the cautionary period.

11. Acknowledgments

These requirements have been refined after some valuable inputs from 
Ambarish Malpani and Paul Hoffman.

13.

12. References

   [PKIX-1]

      Internet X.509 Public Key Infrastructure.
      Certificate and CRL Profile. RFC 2459
      R. Housley, W. Ford, W. Polk, D. Solo.
      or its successor as soon as it can be referenced.

   [OCSP] 

      X.509 Internet Public Key Infrastructure. 
      Online Certificate Status Protocol - OCSP. RFC 2560
      M. Myers, R. Ankney, A. Malpani, S. Galperin, C. Adams.

   [ES-F]

      Electronic Signature Formats for long term electronic signatures
      RFC 3126. D. Pinkas, J. Ross, N. Pope. September 2001.

   [ES-P]

      Electronic Signature Policies. RFC 3125.
      D. Pinkas, J. Ross, N. Pope. September 2001.

   [CMS] 

      Cryptographic Message Syntax. RFC 2630. R. Housley June 1999.
      or its successor as soon as it can be referenced.

   [ESS] 

      Enhanced Security Services for S/MIME. RFC 2634. P. Hoffman. 
      RFC 2634, June 1999.




Pinkas, Housley                                               [Page 12]

Internet Draft               DPV&DPD-REQ                   January 2002


   [ISO-X509] 

      ISO/IEC 9594-8/ITU-T Recommendation X.509, "Information
      Technology - Open Systems Interconnection: The Directory:
      Authentication Framework," 1997 edition. (Pending publication
      of 1997 edition, use 1993 edition with the following amendment
      applied: Final Text of Draft Amendment DAM 1 to ISO/IEC 9594-8
      on Certificate Extensions, June 1996.)


Pinkas                                                        [Page 12]

Internet Draft               DPV&DPD-REQ                   January 2002

   [FTP]

      Internet X.509 Public Key Infrastructure. Operational Protocols:
      FTP and HTTP. RFC 2585. R. Housley, P. Hoffman. May 1999.

   [HTTP]

      Internet X.509 Public Key Infrastructure. Operational Protocols:
      FTP and HTTP. RFC 2585. R. Housley, P. Hoffman. May 1999.

   [LDAP]

      Internet X.509 Public Key Infrastructure Operational Protocols 
      LDAPv2. RFC 2559. S. Boeyen, T. Howes, P. Richard. April 1999.

14.

13. Authors' addresses

   Denis Pinkas
   Integris,
   Bull.
   68, Route de Versailles
   78434 Louveciennes CEDEX
   FRANCE
   e-mail: Denis.Pinkas@bull.net

   Russell Housley
   RSA Laboratories
   918 Spring Knoll Drive
   Herndon, VA 20170
   USA
   rhousley@rsasecurity.com

15.

Full Copyright Statement

   Copyright (C) The Internet Society (2001). (2002).  All Rights Reserved.

   This document and translations of it may be copied and furnished to
   others, and derivative works that comment on or otherwise explain it
   or assist in its implementation may be prepared, copied, published
   and distributed, in whole or in part, without restriction of any
   kind, provided that the above copyright notice and this paragraph
   are included on all such copies and derivative works.  However, this
   document itself may not be modified in any way, such as by removing
   the copyright notice or references to the Internet Society or other


Pinkas, Housley                                               [Page 13]

Internet Draft               DPV&DPD-REQ                   January 2002


   Internet organizations, except as needed for the purpose of
   developing Internet standards in which case the procedures for
   copyrights defined in the Internet Standards process must be
   followed, or as required to translate it into languages other than
   English.

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.



Pinkas                                                        [Page 13]

Internet Draft               DPV&DPD-REQ                   January 2002

   This document and the information contained herein is provided on an
   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
















































Pinkas







































Pinkas, Housley                                               [Page 14]

----