Subject: Re: Open issue: DPV additional information

From: Peter Sylvester <[email-masked]>
Date: Tue, 16 Apr 2002 16:03:30 +0200 (MET DST)

> A CA cannot sign DPV responses.

Is this a statement like 'there is no requirement for relaying'? 
 
Why is it impossible for a CA to sign DPV responses for the certificates 
it has issued, or to delegate this to an 'authorised DPV service'?

> DPV servers are either :

>  - locally trusted by their requesting clients for any policy, or/and
>  - trusted under a given validation policy.

And nothing prohibits you to have DPV servers that are 'authorised
by a CA'. This is an independant category. 

But since the only reason for this comparisons was to convince you
that a DPV response may also contain a DPV response, and since
you finally agreed with this, I do not really think that it absolutely 
necssary at that point to discuss our possible disagreements about 
the operational scenarios of OCSP and DPV servers, so you might
ignore to comment the previous questions. 

Thus:   

I don't think that it is necessary in the following to have the 
'authorised' restrictions for OCSP and CRLs.

Besides you, nobody has asked for this, as far as I remember.

> I would propose the following :
> 
> The DPV request MUST allow the client to request the server to include 
> in its response additional information which will allow relying parties 
> not trusting the requested DPV server to be confident that the 
> certificate validation has correctly been performed. Such information 
> may consist of a certification path, revocation status 
> information from authorised CRL issuers or authorised OCSP responders, 
> time-stamp tokens, or a DPV response from a DPV server that is trusted 
> under the validation policy.  When the certificate is valid according 
> to the validation policy, the server MUST, upon request, include that 
> information in the response. However, the server MAY omit that 
> information when the certificate is invalid or when it cannot determine 
> the validity.
> 
> Denis

---

From: Denis Pinkas <[email-masked]>
Date: Tue, 16 Apr 2002 16:14:06 +0200

Peter,

We need to agree on a common text. So, please focuss on the text.

Since you made no proposal, but only provided a "hint", what about the new
text below ?

The DPV request MUST allow the client to request the server to include 
in its response additional information which will allow relying parties 
not trusting the requested DPV server to be confident that the 
certificate validation has correctly been performed. Such information 
may consist of a certification path, revocation status information from 
authorised CRL issuers or authorised OCSP responders, revocation status 
information from CRL issuers or OCSP responders trusted under the 
validation policy, time-stamp tokens from TSAs responders trusted under 
the validation policy, or a DPV response from a DPV server that is 
trusted under the validation policy.  When the certificate is valid 
according to the validation policy, the server MUST, upon request, 
include that information in the response. However, the server MAY omit 
that information when the certificate is invalid or when it cannot 
determine the validity.

Denis