view Side-By-Side changes

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


        Delegated Path Validation and Delegated Path Discovery 
                   Protocol Requirements (DPV&DPD-REQ)
                    <draft-ietf-pkix-dpv-dpd-req-00.txt>
                   <draft-ietf-pkix-dpv-dpd-req-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 specifies requirements for two main request/response 
pairs.

The first one, called Delegated Path Validation (DPV), 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), can be used to 
obtain from a DPD server all the information needed (e.g. leaf 
certificates, (e.g., the end-
entity certificate, the CA certificates, full CRLs, delta-CRLs, OCSP 
responses) to locally validate a certificate according to certificate. The DPD server uses a 
set of rules, called a path discovery policy. 

It policy, to determine which 
information to return. 

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

This document also defines the requirements for two optional 
request/response 
pairs, either for allowing to indicate pairs. The first one is used to establish a 
validation server policy with a 
validation policy, or DPV server. The second one is used to 
establish a path discovery server policy with a DPD server. Either 
request/response pair provide a path discovery 
policy; or giving the reference of a an existing policy to get 
obtain details of an 
already defined policy. policy details.

Pinkas                                                         [Page 1]

Internet Draft               DPV&DPD-REQ                  November 2001                   January 2002


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

1. Rationale and benefits

These delegated processing provides two primary services: delegated 
signature validation, delegated 
path validation and delegated path discovery. Not all clients require both services in all scenarios. Some clients have requirements for offloaded require 
a server to perform path validation and have no need for data 
acquisition, while some other clients require only delegated path 
discovery to help them perform their own in support of local path validation.

3. Rational

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

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

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 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 verify the signature on authenticate the response, 
can be considerably less than the time required by for the client to 
perform certification path discovery and validation. Even if a 
certification path were readily available to the client, the delay 
processing time associated with 
processing the signatures signature verification for each 
certificate in the path might (under 
some circumstances such as (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. Even clients Clients that are able to 
do their own path validation may rely on a trusted server to do path 
validation if clients are in an environment where centralized management of validation policies is needed for some applications. needed, 
or the clients rely on a trusted server to leave centralized traces 
of such activities.



Pinkas                                                         [Page 2]

Internet Draft               DPV&DPD-REQ                  November 2001                   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).

Servers Clients can also take directions from the client about how path 
validation SHALL be done (such as which validation policy SHALL be 
used).

In all these cases, direct the client will delegate server to perform path 
validation to in accordance with a 
fully-trusted server. 

4. Rational 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 need is trusted to return the most current information that is 
available to it (which may not even be trusted, because 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, HTTP, and so on. 
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 to return the "right" data any more than the client would have to 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 directories 
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.

In these cases, the client will delegate path discovery to an untrusted 
server. 

5.

4. Validation policy and path discovery policy

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

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

Both services (delegated path validation and delegated path discovery) 
can be potentially used by the an enterprise for enforcing various aspects 
of centralized policy.




Pinkas                                                         [Page 3]

Internet Draft               DPV&DPD-REQ                  November 2001 policies.

Alternatively, clients system security administrators MAY also define policies.
However, such policy definition may be quite complex and only simple some 
forms of policies 
SHOULD can be defined in this way, otherwise testing all 
the possible variations would lead to non-interoperable implementations
or would 
delay increase the time necessary to make sure ensure that two implementations 
are really interoperable.


Pinkas                                                         [Page 3]

Internet Draft               DPV&DPD-REQ                   January 2002

Since policy definitions can be quite long and complex, all the 
parameters SHOULD not NOT be passed with each individual request but request; rather, 
they SHOULD be defined using a 
reference separate policy definition 
request/response pair. In response to either an a priori known policy (e.g. an OID) or an 
already pre-defined successful policy (e.g. definition 
request, the server SHALL return a policy reference returned by the server) 
SHOULD be used.

Some (e.g. an OID).

However, some forms of path discovery policy can be simple enough, e.g. a set 
of self-signed certificates. simple. In 
that case it MAY be acceptable to pass 
all the parameters from the path 
discovery policy with each individual 
request.

Policies allows to support security services, such as an entity 
authentication service, a data origin authentication service, an 
integrity service or request, i.e. a confidentiality service or some combination set of 
these services. 

This can be trust 
anchors and separate revocation status conditions for immediate use, e.g. to use a the end-entity 
certificate in order and for the other certificates (see section 9.2).

The protocol SHALL allow clients to 
support a confidentiality service by using a certificate that contains obtain, at any time, the key exchange bit set or references
for all of the key agreement bit set or policies supported by the digital 
signature bit set when server by using an ephemeral-ephemeral Diffie-Hellman key 
exchange is being used.

This additional 
request/response pair. The response can be for a time T in the past, e.g. include references to use a certificate in 
order previously 
defined policies or to verify data protected by a data origin authentication service 
in combination with an integrity service, using priori known policies.

4.1. Validation Policy

A validation policy is a certificate that 
contains the digital signature bit set.

There is an inevitable delay between a compromise set of key being noticed 
by the end-entity, and rules against which the report validation of revocation being made by 
the certificate is performed. 

A validation policy MAY include several trust anchors. A trust anchor 
is defined as one public key, a CA 
(or on behalf name, a validity time interval, and 
optionally additional constrains. The use of a self-signed certificate 
is one way to specify together: the CA) public key to be used, the relying parties. This delay exists in 
any case, even when an OCSP service is being used. So querying CA 
name, and the 
revocation status validity period of a certificate the public key. 

Additional constrains for each trust anchor MAY be defined. These 
constraints might include a time T never proves that the 
private key corresponding to that certificate was not revoked at that 
time T. 

Ideally, set of Certification Policy constraints or 
a cautionary period SHOULD set of naming constraints. These constrains MAY also be defined included in 
self-signed certificates.

Additional conditions that apply to the policy, certificates in order 
to allow some time for 

   1) the end-entity to realize that a private key has been path MAY 
also be specified in 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 possibly be compromised, and for 

   2) the revocation Authority 
provided.

Additional conditions that apply to make available the revocation 
      status information, e.g. by providing end-entity certificate MAY 
also be specified in the validation policy. For example, a specific 
name form, like an OCSP service, CRLs 
      or delta-CRLs e-mail address either in combination with full CRLs.



Pinkas                                                         [Page 4]

Internet Draft               DPV&DPD-REQ                  November 2001


When the key included rfc822 subject 
alternative name or in the certificate is for immediate use, it is 
not possible to apply a cautionary period and thus it should be 
realized that some risk is taken, since emailAddress naming attribute in the corresponding private key 
subject name, might indeed be compromised at the time required.

In order to succeed, one valid certification path (i.e., none of use.

When the key included 
certificates in the path are expired or revoked) MUST be found between 
an end-entity certificate is for and a trust anchor and all constraints that 
apply to the verification of 
some usage certification path MUST be verified.

Validation policies support security services in the past, then it is possible two time contexts:

   - for immediate use (e.g., to apply a cautionary 
period. In such a case, use the policy SHOULD indicate public key within a 
     certificate for symmetric key management), or

Pinkas                                                         [Page 4]

Internet Draft               DPV&DPD-REQ                   January 2002

   - for a minimum delay to 
be observed between the time T in the past, i.e. when the recent past (e.g., to use of the 
private public key took was supposed 
     within a certificate to take place, verify data origin authentication and the time of the 
current verification.

5.1. Validation Policy

A validation policy 
     integrity).

There is an inevitable delay between a set compromise of rules against which key being noticed 
by the validation end-entity and the report of revocation being made by the certificate is performed. 

A validation policy MAY include several trust anchors. A trust anchor 
is defined as one public key value (root key) for a given CA name, 
valid during some time interval. The use 
(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 self-signed certificate 
allows to specify at a time T never proves that the same time: the public private key 
corresponding to be used, the CA 
name and the validity period of the root key. 

Additional constrains for each trust anchor that certificate was not compromised at that time T. 

A validation policy MAY be defined, such as a 
set of Certification Policy constraints and support a set of naming 
constraints. In some cases, these constrains MAY also be included cautionary period in 
self-signed certificates.

Additional conditions that apply order to allow 
time for:

   1) the certificates from the chain, 
(e.g. user-initial-policy-set, initial-policy-mapping-inhibit, initial-
explicit-policy, or initial-any-policy-inhibit) or end-entity to the end-
certificate (e.g. a name form realize that must be present in the end-
certificate, like an e-mail address either in the rfc822 subject alt 
name one of its private keys has been 
      or in could possibly be compromised, 

   2) the emailAddress attribute in end-entity to report the subject name) MAY also be 
specified in key compromise,

   3) the validation policy.

In order revocation authority to succeed, one valid path (i.e. none of process the certificates revocation request from 
      the path must be revoked) must be found between a leaf certificate 
and a trust anchor end-entity, and all constraints that apply

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

When the public key within the certificate 
chain must be verified.

5.2. Path discovery policy

A path discovery policy is a set of rules against which the discovery 
of a certification path used immediately, it is performed.

A path discovery policy MAY either be a reference 
not possible to apply a validation 
policy or contain only cautionary period, and thus, some major elements from a validation policy, 
e.g. risk is 
taken, since the root keys to corresponding private key might be used to construct compromised at the path. 





Pinkas                                                         [Page 5]

Internet Draft               DPV&DPD-REQ                  November 2001

Since 
time of use.

When the client MUST be "PKI aware", public key within the certificate is used to verify some 
usage from the recent past, it SHALL be able is possible to locally apply additional constraints on a cautionary 
period to further reduce the certification paths that risk. In such a case, the policy MAY be 
returned. Thus "crude" (i.e. simpler) criteria can be defined and used 
in that case.

The client needs 
indicate a minimum delay to be able to limit observed between the number time T in the past,
i.e. when the use of paths the private key took was supposed to be returned 
so that take place, 
and the server does not loose time to find out more paths than 
requested. While making that limitation, of the returned paths MAY not current verification.

When the end-entity certificate expires before the cautionary period 
terminates, then the end-entity certificate MUST be 
appropriate considered as 
invalid. According to section 3.3. Revocation from [PKIX-1] "An entry 
may be removed from the client when it then locally applies additional 
tests. Instead of asking one by CRL after appearing on one regularly scheduled 
CRL issued beyond the paths (which would mandate to 
manage state revoked certificate's validity period", so in 
that case the revocation status information is not guaranteed to be 
available at the server), the client will specify with 
every request the maximum number end of paths that MAY be returned.

If that number cannot be reached by the server, an indication SHOULD 
be returned by cautionary period. If certificates are 
not used close to the server showing that an additional query end of their validity period, then this 
situation will not 
return more paths.

When that number is reached, and when more paths are needed, happen. This means that 
number can be increased. Previously found paths will likely new certificates should be 
returned, but 
issued before the client can easily discard them. This avoids to 
mandate end of the management validity period of state information at the server, but does 
not prevent current 
certificate and with a server to maintain time interval greater than the cautionary 
period.





Pinkas                                                         [Page 5]

Internet Draft               DPV&DPD-REQ                   January 2002


4.2. Path discovery policy

A path discovery policy is a cache set of previous responses.

6. rules against which the discovery 
of a certification path is performed. A path discovery policy is a 
subset of 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, such as the trust anchors. 

Since the client must be "PKI aware", it can locally apply additional 
constraints to the certification paths returned by the server. Thus, 
a "crude" (i.e. simpler) criteria 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 certificate for the current time and certificates according to a single set of 
rules, called a validation policy. 
A time other than the current time may be used to determine the 
validity. The validation policy SHALL be known by the DPV server. When it isn't, it 
The validation policy MAY be defined using an additional protocol request/
response pair (see section 10). 10) prior to the DPV request. In this way 
clients only need to be aware of the reference of the validation 
policy to be used by a given application.

The certificate to be validated MAY MUST either be directly provided in 
the request or alternatively an unambiguous reference MAY MUST be provided, 
e.g. such as 
the CA name and distinguished name, certificate serial number together with number, and the hash 
of the certificate certificate, like ESSCertID as defined in RFC 2634.

In order to help the server, the [ESS] or 
OtherSigningCertificate as defined in [ES-F].

The client MAY MUST be able to provide to the validation 
server server, associated
with each certificate to be validated, "useful certificates", as well 
as "useful revocation 
information" that MAY be used by the validation server (e.g. of information". Revocation information includes 
OCSP 
requests, CRLs or delta-CRLs). responses, CRLs, and delta-CRLs. As an example, an S/MIME message may 
might include such information information, and the client can simply provide copy that 
information. 
information into the DPV request.

In order to obtain the revocation status information of any 
certificate from the certification path, the DPV server MAY might use, in 
accordance with the validation policy, different sources of revocation 
information, e.g. a combination of OCSP requests, CRLs responses, CRLs, or delta-CRLs.

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

Pinkas                                                         [Page 6]

Internet Draft               DPV&DPD-REQ                  November 2001 appropriate.

The status of the DPV response MAY be MUST indicate one out of three types: four status alternatives:

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

   2) the certificate is definitively invalid according to the 
      validation policy, 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 of the certificate
      (e.g. certificate.
      This condition will occur when a certification path cannot be constructed). 
      constructed or some revocation information is unavailable.

The DPV request MUST allow the client to request the response to 
include the certification path and revocation status information used 
by the server to process the request. When requested, the server MUST 
include the certification path and revocation status information in 
the response when the certificate is valid according to the validation 
policy. However, the server MAY omit the certification path and 
revocation status information when the certificate is invalid or 
when it cannot determine the validity.

In order to be able to be confident that the validation of the 
certificate has correctly be been done, the client will only require requires an 
authenticated response. 

7. Delegated Path Discovery Protocol Requirements

The Delegated Path Discovery (DPD) protocol allows 

In order for the client to use a single 
protocol towards a single server prove to collect at one time all another party that trusts the data 
elements 
same DPV server that might be collected using different protocols (e.g. LDAP, 
DAP, OCSP) or by querying multiple servers. Then this information can 
locally be used to validate one or more certificates for the current 
time certificate validation was correct, the 
client requires 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 a response is self-sufficient proof.

The server may require client authentication. The authentication 
method to be used may be dependant upon the transport used, and thus 
the client authentication mechanism need not be an integral part of 
the DPV request.

6. Delegated Path Discovery Protocol Requirements

The Delegated Path Discovery (DPD) protocol allows the client to use a 
single protocol towards a single server to collect at one time all the 
data elements that might be collected using different protocols (e.g. 
LDAP, DAP, OCSP) or by querying multiple servers, according to a 
single path discovery policy. Then returned information can be used to 
locally validate one or more certificates for the current time. 

Clients MUST be able to specify whether they want, in addition to the 
certification path, the revocation information associated with the 
path, for the end-entity certificate only, for the CA certificates 
only or for both.

The path discovery policy MAY MUST be known a priori by the DPD server. 
When it isn't, it The path 
discovery policy MAY defined using an additional protocol request/response pair
(see section 8).

None, one 7) prior to the DPD request.


Pinkas                                                         [Page 7]

Internet Draft               DPV&DPD-REQ                   January 2002

The server response MUST include zero, one, or several certification paths MAY be returned. 
paths. Each path consists of a sequence of certificates, starting after with 
the certificate to validate be validated and ending with one issued by a trust 
anchor. The trust anchor self-signed certificate. certificate, if issued, is not 
included. In addition, the revocation information associated with 
each certificate in the path MAY MUST also be 
returned. returned, if it has been 
requested.

The paths that are returned MAY need client needs to match some additional local 
controls done by be able to limit the number of paths returned. 
Therefore the client, e.g. verifying some certificate 
extensions. 

The client MAY MUST be able to indicate the maximum number of 
certification paths that 
MUST SHOULD be returned (provided that they may can be 
found). If the number is not specified, that number is defaulted defaults to one. 

The paths that are returned may need to match some additional local 
controls done by the client, e.g. verifying some certificate 
extensions. The returned paths may not be appropriate to the client 
when it locally applies additional tests. Instead of asking one by 
one the paths (which would require state information at the server), 
the client specifies with every request the maximum number of paths 
to be returned.

If that number cannot be reached by the server, an indication SHOULD 
be returned by the server showing that an additional query will not 
return more paths.

If the paths that are returned do not match the local conditions, then 
the number of number of certification paths to be returned can be 
extended, by augmenting this value.

The server may use a local cache to avoid to search again the same 
elements, Previously found paths will likely 
be returned, but is not mandated to maintain any local the client can easily discard them. This avoids 
requirements for state information at the server, but does not prevent 
a server from any maintaining a cache of previous request. responses.

The goal is to avoid to maintain the maintenance of state information on for previous 
requests: if this is done, it optimizes the 
response time. minimizes potential denial of service 
attacks or other problems associated with server crashes.

Path discovery is MUST be performed according to the path discovery policy. 



Pinkas                                                         [Page 7]

Internet Draft               DPV&DPD-REQ                  November 2001 

The status of the DPD response MAY be MUST indicate one out of three types: four status alternatives:

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

   2) one or more certification paths could be was found according to the 
      path discovery policy, with no 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 could be was found according to the path 
      validation criteria, 
      discovery criteria.

Pinkas                                                         [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. 

In order to be able to be confident 

To provide confidence that the values returned are coming response originates from the DPV DPD server,
the client server MAY require provide an authenticated response. 

8. Components for a validation policy

A validation policy is build from four components:

   1. Certificate chain requirements,
   2. Revocation requirements,
   3. End-certificate specific requirements,
   4. optionally, a cautionary period requirements.

8.1. Certificate chain For example, the 
server might sign the response.

7. Policy definition protocol (PDP) requirements

The certificate requirements identifies a sequence support of trust anchors 
used 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 start (or end) certification define a policy, 
i.e. a validation policy and/or a path processing discovery policy, and initial 
conditions to 
receive back a reference for certification path validation as that policy. The server may provide a 
reference to a previously defined in [PKIX-1]. 

8.2. Revocation Requirements

Revocation information MAY policy, if it fulfills the request 
requirements.

The policies locally defined at the server may be obtained through CRLs, delta-CRLs or 
OCSP responses. Certificate revocation requirements are specified both 
in terms 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 checks required on policy. So, in practice, these request/response pairs will be 
restricted to the end-certificate (i.e. definition of relatively simple policies.

Usually, these request/response pairs will be used by managers to 
register the 
certificate policies to be used by ordinary clients, such as those 
within an organization for which a path is required) and on checks required on CA 
certificates.

It use with various applications.

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

Policy definition response, if :

   - full CRLs (or full Authority revocation lists) have to successful, SHALL return a policy 
reference. The policy reference MAY be 
     collected,

   - OCSP responses, using RFC 2560, have specific to the request, or 
it MAY be collected,

   - delta-CRLs a reference to a policy that has already been established 
and fulfills the relevant associated full CRLs (or full 
     Authority revocation lists) are request requirements.

It is up to server to decide how long a temporary defined policy will 
be collected.

None, one or more of maintained.

When a obtaining a policy reference from the above conditions MAY apply.

Pinkas                                                         [Page 8]

Internet Draft               DPV&DPD-REQ                  November 2001


8.3. End-certificate specific requirements

There MAY server, it would be requirements that apply only 
interesting to consider providing natural language information about 
the end-certificate (i.e. purpose of the certificate that is policy, rather than the object technical description of 
the query). 

For example, the end-certificate must contain specific extensions with 
specific types or values (it does not matter whether they policy. 

When using DPV, there are critical 
or non critical). As an example, the end-certificate must contain two possibilities:

   a) The client is a 
name form like an e-mail address either little bit PKI-aware, in the rfc822 subject alt name 
or in sense that it is 
      only able to parse the emailAddress attribute in end-entity certificate to check some 
      properties of a certificate, and delegates the subject name.

8.4. Cautionary period requirements

When applicable, validation of the cautionary period will define a minimum delay 
      rest of the path to 
be observed between a time T in the past, where server. It appears easier to remotely 
      define such "partial policies" since some tests on the end-
      entity certificate are left to the use of client.

Pinkas                                                         [Page 9]

Internet Draft               DPV&DPD-REQ                   January 2002


   b) The client is fully PKI-unaware, and thus fully delegates the private 
key or 
      validation to the public key is supposed server. It appears more difficult to take took place, and remotely 
      define such "complete policies" since the time of tests on the current validation.

9. end-
      certificate are made by 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. Components for a path discovery validation policy

A validation policy is build from four components:

   1. Certification path discovery must include certificate chain requirements, and MAY 
include revocation
   2. Revocation requirements, and end-certificate
   3. End-entity certificate specific requirements,
   4. optionally, cautionary period requirements.

10. Policy definition protocol (PDP) requirements

The support of these request/response pairs is OPTIONAL. These 
request/response pairs allow either to define a policy, i.e. a 
validation policy and/or a path discovery policy, and to receive back a 
reference for

Note: [ES-P] defines ASN.1 data elements that policy or to provide a reference to a previously 
defined policy and to receive back may be useful while 
defining the definition components of that a validation policy.

Policies locally predefined at the server may be more precise than 
policies defined using this optional protocol. 

Thus this OPTIONAL

8.1. Certificate chain requirements

The PDP protocol exchanges will never have all MUST allow the 
flexibility client to describe any kind specify certification path 
requirements. The path requirements identify a sequence of policy. So in practice it will be 
restricted trust 
anchors used to define relatively simple policies.

Usually, these start certification path processing and initial 
conditions for certification path validation as defined in [PKIX-1]. 

8.2. Revocation Requirements

The PDP protocol exchanges will be used by managers to register MUST allow the policies client to specify revocation checking 
requirements. Revocation information may be used, e.g. within an organization for various 
applications. As a result obtained through CRLs, 
delta-CRLs or OCSP responses. Certificate revocation requirements are 
specified both in terms of checks required on the registration, managers will receive a 
reference of end-entity 
certificate (i.e. the policy.

These requests SHALL be able to be authenticated so that only 
authorized clients can register policies (and thus avoid denial of 
service attacks by registering useless policies).

The reference of certificate for which a path is required) and on 
checks required on CA certificates.

Revocation requirements for the policy MAY end-entity certificate may not be specific to the request or MAY be a 
reference that has already been provided 
same as the result of a previous 
request with requirements for the CA certificates. For example, an identical definition.



Pinkas                                                         [Page 9]

Internet Draft               DPV&DPD-REQ                  November 2001


It is up to server to decide how long a temporary defined policy will OCSP 
response may be kept.

In case the policy is locally defined at needed for the server, when querying a 
policy reference, it would end-entity certificate while CRLs may 
be interesting sufficient for the CA certificates. Therefore, the PDP protocol 
MUST allow the client to consider specify separate requirements for the 
end-entity certificate and for the CA certificates.

The PDP protocol MUST allow the client to provide back 
information about specify the purpose source of the policy revocation 
information, in a natural language. 

When particular if :

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

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

   - delta-CRLs and the relevant associated full CRLs (or full 
     Authority revocation lists) are two possibilities:

   a) to be collected.

Pinkas                                                        [Page 10]

Internet Draft               DPV&DPD-REQ                   January 2002


   - any available revocation information has to be collected.

8.3. End-entity certificate specific requirements

The PDP protocol MUST allow the client is a little bit PKI-aware, in the sense to specify requirements that it is 
apply only able to parse the end-certificate to check some properties 

      in end-entity certificate (i.e. the certificate that certificate, and delegates 
is the validation object of the rest 
      of query). 

The client might require the path 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 server. It appears easier to remotely define 
      such "partial policies" since client might need an end-entity certificate that 
contains an electronic mail address (either in the tests on rfc822 subject alt 
name or in the end-certificate 
      are left to emailAddress naming attribute in the client.

   b) subject name).

8.4. Cautionary period requirements

The PDP protocol SHALL allow the client is fully PKI-unaware, and thus fully delegates the 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 server. It appears more difficult to remotely 
      define such "complete policies" since recent past, where the tests on 
use of the end-
      certificate are made by private key or the server and may be quite complex.

When using DPD, simpler validation policies may be defined since 
anyway clients need public key is supposed to take place, 
and the time of the current validation.

9. Components for a path discovery policy

The PDP protocol SHALL be fully PKI-aware able to do other tests.

11. 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, and 8.3, respectively.

10. DPV versus DSV

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

Another document [DSV-REQ] specifies requirements for a 

A Delegated Signature Validation (DSV) service that allows to fully delegate the 
validation of a digital signature could be specified to a DSV (Delegated Signature 
Validation) server. In particular, DSV allows 
allow to prove later on to someone else, not trusting the same DSV 
server, that the a digital signature was applied while the certificate 
was valid.

12. 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. Security considerations

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

Pinkas                                                        [Page 11]

Internet Draft               DPV&DPD-REQ                   January 2002

Other clients will may trust their own servers and will query them. Queries 
relative to servers, or they might perform 
certification path validation themselves. Clients operating under 
an organizational policy must ensure that each of the current time can easily be done to another server. 

13. servers they 
trust is operating under that organizational policy. 

12. Acknowledgments

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



Pinkas                                                        [Page 10]

Internet Draft               DPV&DPD-REQ                  November 2001


14.

13. References

   [DSV-REQ] 

       Delegated Signature Validation Protocol Requirements 
       <draft-ietf-pkix-dsv-req-00.txt>

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

   [TSP]

      Internet X.509 Public Key Infrastructure
      Time-Stamp Protocol (TSP). RFC 3161
      C. Adams, P. Cain, D. Pinkas, R. Zuccherato. August 2001.

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

   [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 11] 12]

Internet Draft               DPV&DPD-REQ                  November 2001                   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. Authors' address 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).  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
   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                                                        [Page 12] 14]
----