view Side-By-Side changes

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


        Delegated Path Validation and Delegated Path Discovery 
                   Protocol Requirements (DPV&DPD-REQ)
                   <draft-ietf-pkix-dpv-dpd-req-02.txt>
                   <draft-ietf-pkix-dpv-dpd-req-03.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). (DPD) for Public Key Certificates. 
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), (DPD) for Public Key Certificates, 
using two main request/response pairs.

These delegated

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

The 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 DPD request/response pair can be used to obtain from a DPD server 
all the information needed (e.g., the 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                     April 2002

A third request/response pair can be used to allow allows 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 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.

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

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.

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 certification path validation. validation [PKIX-1].

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 a limited processor speed) processor) 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 maintain centralized traces records 
of such activities.

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.


Pinkas, Housley                                                [Page 2]

Internet Draft               DPV&DPD-REQ                     April 2002

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, repository queries, 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 Protocol Requirements

The Delegated Path Validation (DPV) protocol allows a server to 
validate one or more public key certificates according to a validation 
policy.

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

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

Policy definitions can be quite long and complex, and some policies 
may allow for the setting of a few parameters (e.g. root self-signed 
certificates). The protocol MUST allow the client to include these 
policy dependant parameters in the DPV request. It is expected that 
most clients will simply reference a validation policy for a given 
application or accept the DPV serverĘs default validation policy.

The client can request that the server determine the certificate 
validity at a time other than the current time. Depending upon the 
validation policy being used, The DPV server MUST 
obtain revocation status information for the validation time may either be 
in the 
time for which client request. 

In order to obtain the revocation status information has to be obtained, 
or of any 
certificate from the time for which certification path, the DPV server might use, in 
accordance with the event validation policy, different sources of revocation 

Pinkas, Housley                                                [Page 3]

Internet Draft               DPV&DPD-REQ                     April 2002

information, e.g. a combination of OCSP responses, CRLs, or delta-CRLs. 
If the revocation status information for which the validity requested validation time 
is tested took 
place.

Since policy definitions can be quite long and complex, all unavailable, then the 
parameters SHOULD NOT be passed with each individual request; rather, 
they SHOULD be defined using DPV server MUST return a separate policy definition request/
response pair (see section 9). In this way clients only need to be 
aware of the reference of status indicating 
that the validation policy to be used by a given 
application.


Pinkas, Housley                                                [Page 3]

Internet Draft               DPV&DPD-REQ                   January 2002 certificate is invalid.

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

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

The DPV server MUST get have the full certificate. If not provided in the 
request, the server MUST use the unambiguous reference provided by in the 
client 
request to obtain it.

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

If the DPV request does not specify a validation policy, the server 
response MUST indicate an unambiguous reference to the one that was used. In such certificate (in case of 
a case, the 
client MUST verify that the one selected by CA key compromise) in the server is appropriate. DPV response.

The DPV response MUST indicate one of four the following two status alternatives:

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

   2) the certificate is definitively invalid not valid according to the validation policy.

   3)

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

    a) the DPV server cannot determine the validity of the certificate 
       because a certification path cannot be constructed.

    b) the DPV server successfully constructed a certification path, but
       it was not valid according to the validation algorithm in 
       [PKIX-1].

    c) 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 may occur before a 
       certificate validity period has begun, begun or while a certificate is 
      suspended, or when, at 
       suspended.

In order to prevent replay attacks, the time DPV client MUST be able to 
include a nonce in the server generated DPV request. When the 
      response, all conditions of nonce is present in the validation policy could not be 
      met.

   4) 
request, then the DPV server cannot determine MUST include the validity of same nonce in the certificate.
      This condition will occur when a certification path cannot be 
      constructed or some revocation information is unavailable. 
response.

The DPV request MUST allow the client to request that the response to 
include the certification path and revocation status information used 
by the DPV server to process the request. When requested, the DPV 

Pinkas, Housley                                                [Page 4]

Internet Draft               DPV&DPD-REQ                     April 2002

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, not yet 
valid or when it cannot determine the validity.

Pinkas, Housley                                                [Page 4]

Internet Draft               DPV&DPD-REQ                   January 2002

In order invalid.

The DPV response MUST be bound to the DPV request. This can be able 
accomplished by repeating the important components from the request in 
the response or by including a one-way hash of the request in the 
response.

For the client to be confident that the certificate validation of was 
handled by the 
certificate has correctly been done, expected DPV server, the client only requires an 
authenticated response. 

In order for DPV response MUST be 
authenticated.

For the client to be able prove to another a third party that trusts the 
same DPV server that the certificate validation was correct, the 
client requires a signed response. All the parameters needed to prove 
that handled correctly, 
the DPV response conforms to the request SHALL MUST be copied from the 
request into the response, so that a response is self-sufficient proof. digitally signed.

The DPV server may 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 authentication, therefore, the DPV request. 
request MUST be able to be authenticated.

5. Delegated Path Discovery Protocol Requirements

The Delegated Path Discovery (DPD) protocol allows the client to use 
a single protocol towards a single server request to collect at one time from a single server the data 
elements available at the current time that might be collected using 
different protocols (e.g. LDAP, DAP, HTTP, FTP, OCSP) or by querying 
multiple servers, to locally validate a public key certificate 
according to a single path discovery policy.
Then The 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, certificate, for the CA certificates 
only certificates, 
or for both.

If the DPD server does not support the client requested path 
discovery policy, the DPD server MUST return an error. Some forms 
of path discovery policy can be simple. In that case it is acceptable 
to pass the parameters from the path discovery policy with each 
individual request, i.e. request. For example, the client might provide a set of 
trust anchors and separate revocation status conditions for the 
end-entity certificate and for the other certificates. More The DPD request 
MUST allow more elaborated path discovery policies SHOULD to be defined using a separate policy definition request/response pair 
(see section 9). Most referenced. 
It is expected that most of the time, time clients will only need to be aware of 
the reference of the referenced path discovery policy to be used by for a given application.

The DPD server response includes zero, one, or several certification 
paths. Each path consists of a sequence of certificates, starting with 
the certificate to be validated and ending with one issued by a trust 
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.

Pinkas, Housley                                                [Page 5]

Internet Draft               DPV&DPD-REQ                     April 2002


The DPD client needs to be able to limit the number of paths returned. 
Therefore the client MUST be able to indicate the maximum number of 
certification paths that SHOULD to be returned (provided that they can be 
found). If the number is client does not specified, that number defaults to one. 


Pinkas, Housley                                                [Page 5]

Internet Draft               DPV&DPD-REQ                   January 2002 specify a maximum number, then 
the DPD server MUST return a single certification path.

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 
criteria known only 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), client. For example, the client specifies with every request 
might require the maximum number presence of paths 
to be returned. a particular certificate 
extension. 

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

If the paths that are returned do not match the clientĘs local conditions, 
criteria, then the number of number of certification paths to be 
returned can be 
extended, extended by augmenting increasing this value. Previously found 
paths will likely be returned, but the client can easily discard them. 
This avoids requirements for state information at the server, but does 
not prevent a server from maintaining a cache of previous responses.

Avoiding the maintenance of state information for previous requests 
minimizes potential denial of service attacks or other problems 
associated with server crashes.

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

The DPD response MUST indicate one of four status alternatives:

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

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

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

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

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

To provide confidence

For the client to be confident that the response originates from the 
expected DPD server, the server MAY provide an authenticated response. 
For example, the server might sign the response.


Pinkas, Housley                                                [Page 6]

Internet Draft               DPV&DPD-REQ                   January                     April 2002

The DPD server MAY require client authentication, therefore, the DPD 
request MUST be able to be authenticated.

6. Requirements common both to DPV and DPD

The protocol SHALL allow clients client MUST be able to obtain the references for the default policy 
or 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 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 is useful
to rely on pre-defined policies that are already known by the clients and the 
servers, 
Such policies are likely to be defined by system security 
administrators who carefully manage them. 

However, policy definitions may be 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 validation of 
the certificate is performed.

A validation policy MAY include several trust anchors. A trust anchor 
is defined as one public key, a CA name, and a validity time interval, and interval; 
a trust anchor optionally includes additional constrains. The use of a 
self-signed certificate is one way to specify together: the public key to be 
used, the CA name, and the validity period of the public key.

Additional constrains for each trust anchor MAY be defined. These 
constraints might include a set of Certification Policy 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 the validation policy. For example, specific 
values could be provided for the inputs to the certification path 
validation algorithm in [PKIX-1], such as user-initial-policy-set, 
initial-policy-mapping-inhibit, initial-explicit-policy, or initial-any-policy-inhibit could be 
provided. 
initial-any-policy-inhibit.

Additional conditions that apply to the end-entity certificate MAY 
also be specified in the validation policy. For example, a specific 
name form, like an e-mail address either in the rfc822 subject 
alternative name or in the emailAddress naming attribute in the 
subject name, might be required.

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

Pinkas, Housley                                                [Page 7]

Internet Draft               DPV&DPD-REQ                   January 2002

There is an inevitable delay between a compromise of key being noticed 
by the end-entity and the report of revocation being made by 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 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 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 
of that end-entity certificate is available for the time of use is 
composed of the sum of several time intervals: 

   1) the end-entity realizes that its private key has been 
      or could possibly be compromised, 

   2) the end-entity reports the key compromise,

   3) the 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 all these time intervals is called a cautionary period.
When the public key within the certificate is used to verify some 
usage from the recent past, it is possible to apply a cautionary 
period. This cautionary period may be applied either by the client or 
by the server. 

When it is applied by the client, the policy will consider the time at 
which the validity has to be determined as being directly the time for 
which the revocation status information has to obtained.

When it is applied by the server, the policy will consider the time at 
which the validity has to be determined as being time when the private 
key (corresponding to the given end-entity certificate) was supposed 
to be used, i.e. the time for which the event for which the validity 
is to be tested took place. In such a case, the policy includes 
the definition of a cautionary period.

7.2. Path discovery policy

A path discovery policy is a set of 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 DPD client is "PKI aware", it can locally apply additional 
constraints to the 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


8. Policy Definition Protocol (PDP) requirements

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 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 MUST be able to be authenticated so that 
only authorized clients can register policies.

Policy definition response, if successful, 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 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 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, Housley                                                [Page 9]

Internet Draft               DPV&DPD-REQ                   January 2002


8.1 Components for

7.1. Components for a validation policy

A validation policy is build from four three 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.1.

Pinkas, Housley                                                [Page 7]

Internet Draft               DPV&DPD-REQ                     April 2002


7.2. Certificate chain requirements

The PDP protocol MUST allow the client to specify certification path 
requirements. 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.1.2.

7.3. Revocation Requirements

The PDP protocol MUST allow the client to specify revocation checking 
requirements.

Revocation information may might 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 validation policy MUST allow the client to specify the source of revocation information, in particular if : 
information:

   - full CRLs (or full Authority revocation lists) 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) Revocation Lists) are to be collected.


   - any available revocation information has to be collected.

8.1.3.

   - no revocation information has to be collected.

7.4. 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 requirements

The client validation policy 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 
validation policy might need require 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.1.4. Cautionary period requirements

The PDP protocol SHALL allow

8. Path Discovery Policy

A path discovery policy is a set of rules against which the client to specify discovery 
of a cautionary period 
for certification path is performed. A path discovery policy is a 
subset of a validation policy. The cautionary period specifies A path discovery policy MAY either be 
a minimum 
delay reference to be observed between a time T in the recent past, where the 
use of the private key validation policy or contain only some major elements 
from a validation policy, such as the public key trust anchors.

Since the DPD client is supposed "PKI aware", it can locally apply additional 
selection criteria to take place, 
and the time of production of revocation status information.

8.2. certification paths returned by the server. 
Thus, a simpler policy can be defined and used for path discovery.

Pinkas, Housley                                                [Page 8]

Internet Draft               DPV&DPD-REQ                     April 2002


8.1. Components for a Path Discovery Policy

The path discovery policy

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

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. 

10. sections 7.2, 7.3, 
and 7.4, respectively.

9. Security considerations

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

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

According to section 3.3 of [PKIX-1]: "An entry may be removed from 

When no policy reference is present in the CRL after appearing on one regularly scheduled CRL issued beyond DPV request, the revoked certificate's validity period". When DPV client 
should verify that the difference 

Pinkas, Housley                                               [Page 11]

Internet Draft               DPV&DPD-REQ                   January 2002

between policy selected by the end of DPV server is appropriate.

The revocation status information is obtained for the validity period validation time. 
In case of a digital signature, it is not necessarily identical to the end-entity certificate 
and 
time when the private key was used. The validation time of should be 
adjusted by the event DPV client to compensate for:

   1) time for which the validity is end-entity to realize that its private key has 
      been or could possibly be tested is 
smaller than the cautionary period, then compromised,

   2) time for the end-entity certificate 
must be considered as invalid, since it is not guaranteed to be able to get report the key compromise,

   3) time for the revocation status information of that certificate. If 
certificates are not used close authority to process 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 revocation 
      request from the validity period of end-entity, or

   4) time for the current certificate revocation authority to update and with a time 
interval greater than distribute the cautionary period.

11. 
      revocation status information.

10. Acknowledgments

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

12.

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


Pinkas, Housley                                                [Page 9]

Internet Draft               DPV&DPD-REQ                     April 2002


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

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

13.





Pinkas, Housley                                               [Page 10]

Internet Draft               DPV&DPD-REQ                     April 2002


12. Authors' addresses

   Denis Pinkas
   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

Full Copyright Statement

   Copyright (C) The Internet Society (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.

   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, Housley                                               [Page 14] 11]
----