Subject: Re: <draft-ietf-pkix-dpv-dpd-req-04.txt>

From: Peter Sylvester <[email-masked]>
Date: Fri, 19 Apr 2002 15:27:17 +0200 (MET DST)

Here some proposals for a text change. 

> 
> The client can request that the server determine the certificate
> validity at a time other than the current time. The DPV server MUST
> obtain revocation status information for the validation time
> in the client request.
> In order to obtain the revocation status information of any
> certificate from the certification path, the DPV server might use, in
> accordance with the validation policy, different sources of revocation
> information, e.g. a combination of OCSP responses, CRLs, or delta-CRLs.
> If the revocation status information for the requested validation time
> is unavailable, then the DPV server MUST return a status indicating
> that the certificate is invalid.
replace by: 

The DPV server MUST produce certificate status information for
the validation time in the client request. In order to do this,
the server might use, in accordance with the validation policy,
different sources of external information concerning revocation 
information, e.g., a combination of OCSP responses, CRLs, or
delta-CRLs, or other status information from other DPV servers. 

If the certificate status information for the requested validation
time is cannot be created, then the DPV server MUST return a status 
indicating that the certificate is invalid.

> 
> 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.
replace by: 

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 information" e.g., revocation
information of OCSP responses, CRLs, and delta-CRLs, or status
information from other DPV servers.
 
> The DPV response MUST be bound to the DPV request. This can be
> 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.
add:

In some environments it may be necessary to present only a response
to another relying party without the corresponding request. 
In this case the response MUST be sufficient self contained.  

> 
> For the client to be able prove to a third party that trusts the
> same DPV server that the certificate validation was handled correctly,
> the DPV response MUST be digitally signed, unless an error is reported
> (e.g. a badly formatted request, etc.). The certificate from the DPV
> server SHALL be used to identify the DPV server.

Replace 'identify' with 'authenticate'.

> another DPV server. Unlike the original client, the DPV server is
> expected to have moderate computing and memory resources, enabling the
                   sufficient ???

----- End Included Message -----

---

From: Denis Pinkas <[email-masked]>
Date: Thu, 25 Apr 2002 15:15:45 +0200

Peter,

> indicating that the certificate is invalid.

The last sentence you propose is not English. I simply propose to add to the
current sentence: "or a response from another DPV server".

> information from other DPV servers.

No. If there is one DPV answer, then that answer is self-sufficient and
there is no reason for the client to make another query.

> In this case the response MUST be sufficient self contained.

Accepted.

> Replace 'identify' with 'authenticate'.

Accepted. 

Denis