Re: draft-ietf-pkix-dpv-dpd-req-00.txt

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

here some comments to DPV/DPD


- Ceterum censeo: I'd prefer to have the text in several documents,
  one for DPV and another for DPD, and a third one containing policy 
  management. 
 
- Abstract

  Instead of 'request/response pairs' I propose something like
  'service accessible by a client-server protocol' 

- Section 2:

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

There are only two services. "signature validation" is not here.

Are there clients that require both services in any scenario?

> Some clients have requirements for offloaded path validation and have 
> no need for data acquisition, while some other clients require only 
> delegated path discovery to help them perform their own path 
> validation.

Is 'data acquisition' a synonym for 'path discovery' ? 

chapter 3:

I second Russ's comment about the last paragraph. To what degree a DPV
client 'trusts' the contents of the response is outside of the 
scope of the protocol. Nevertheless tha protocol should allow
a client to trust either in a blind or reproducing way depending
on policy, i.e. a server may be required to return all information
that has led to its decision. 

> The time required to send the target certificate to the validation 
> server, receive the response, and verify the signature on the response, 

The sentence should only say: 'authenticate the response'. There
is no unconditional requirement of having a signature. (see also below)

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

There is also the case where 'centralised validation of certificates'
is a 'MUST' for all client contexts of some applications. For example 
in order to leave centralised traces of such activities, or simply
because in some contexts the trust management performed in
a centralised way. 

chapter 6:

> The Delegated Path Validation (DPV) protocol allows to validate one or 
> more certificate for the current time and according to a single set of 
> rules, called a validation policy. 

I propose:

  The Delegated Path Validation (DPV) protocol allows to validate
  one or more certificate according to a validation policy selected
  by the client and/or the server. A time other than the current 
  time may be usable to determine the validity.


Here is a list of some requirements for a DPV protocol. Some of
them may be already in the actual text.

- Requirements for obtaining a status

  - a method to authenticate a server before sending any request 
    (for example this can be achieved by SSL).

  - a method to authenticate a client (idem or by mail encryption)

  - a method that client and server provide their identity
    in the requests and responses: 'You, the client X, has
    asked me, the server Y, the following question, and
    I, the server Y, with the help of server Z respond.' 
 
  - a way to link a request from the response, i.e., the
    response MUST include links to determine the essential
    parts of the request. (essential to be determined, this
    is said in order to avoid 'response must include a
    copy of the request.')

  - a method to ensure confidentiality of the transport

- Requirements for later verification of the status.
  
  - the server should be able (depending on piolicy) to return all
    information that had been used to determine the validity status
    of a set of certificates.  

  - a method to determine the authenticity of a response
    independantly of the authentication of the server
    communication (signature validation on a signed response
    for example).

  - a long term method to determine the authenticity of a response 
    may be provided.   

  - information to be collected by a client (for example
    from a previous response) may be provided as a hints to the
    server. 

- Relaying requirements: 

  - depending on policy, a server may just impersonate another
    server, i.e., take the responses of another server, and create
    its own reponse out of them. 

  - a server should be able to include the response of a relayed
    server into his response. 

  - a server should be able to simple add another authentication
    scheme to a response from another server (for example by
    using a second signature or a counter signature.)

  - a server that acts as a relay should be able to tell to the
    next server that it is acting on behalf of a end user, and
    the final server should be able to note this in the response. 

  - For relaying, the protocol MUST provide an efficient means
    to detect loops. 
 
  - The DPV protocol should be usable to determine the validity
    of CA certificates in a path.

- Requirements for incomplete answers:
  
  - a server may indicate an incomplete response, 
    and provide a method to update the response later.  


PS