Subject: RE: Open issue: DPV additional information

From: Peter Sylvester <[email-masked]>
Date: Wed, 17 Apr 2002 21:54:10 +0200 (MET DST)

> As entertaining as it is to watch you guys talk past each other, this thread
> is getting tiresome. Let me take a crack at why I don't think there is any
> real disagreement here.

Thanks also for trying to find the core of the 'debate'. Debates are
currently entertainment in France :-)

As far as I remember the claim was 'A CA cannot sign DPV responses'. 
And Mike and I disagree with that statement.

I am not sure whether there is a disagreement in your following
description. It may be a language problem, but I think there are
some logical relations which seem inversed or unclear. 
My commenst may even lead to more obscurity.  

> 
> I think what Denis is saying is that if an entity is a CA, by definition
> they are trusted to issue and revoke the certificates they issue, by virture
> of being a CA. They can also delegate someone else to do the revocation,
> also by virtue of being a CA. If a RP decides to trust their certs, they
> must also trust their revocation arrangements.

To me, the question is not whether RPs 'MUST' trust but whether the CA has set up
some service for which it can be held responsible. For OCSP,
the CA can sign the responses itself or delegate to an authorised responder
to assume this responsibility.

Now, since just by adding for example a certificate as an extension in an OCSP
response, you immediately turn an 'revocation information' into a 
'positive status information', I call this  a particular case of DPV 
(the request consists to ask the status of the cert relative
to the CA that signed it, no intermediate certs involved). 

> In contrast, when somebody sets up a DPV server, whether or not they also
> run a CA, there is an independant decision to trust the DPV server. It does

Where is the difference betwwen OCSP and DPV? (OCSP trusted responders
are something set up by 'somebody'.  

> not follow as an automatic consequence of the fact thet the same
> organization (or key even) may have issued one or more of the certs in the
> chain in question.

Right, it is not automatic. If the CA itself has signed the DPV/OCSP response
for a directly issued cert, why is is a different PROBLEM to trust the CA for
an OCSP response or for a DPV response for this case. 

There is an issue with intermediate CAs for which indeed the higher CA 
is generally not responsible.     

> In other words, a CA may run a DPV server, but the server will be trusted
> because RPs choose to do so, not because they have previously chosen to
> trust certs issued by the CA.

Well, a RP may always choose whatever it wants to do, but IMO t
for direct subordinate CAs an OCSP or DPV service is almost identical.
if there is a DPV response signed by the CA, why should one not believe 
that this is not an authorised statement from the CA as soon as the CA
has indicated in some policy/practise that it provides CRLs, OCSP and/or DPV?

For the general case, there may be more constellations of trust relations 
for DPV services than just the two defined for OCSP. 

Regards
Peter

---

From: "Michael Myers" <[email-masked]>
Date: Wed, 17 Apr 2002 13:08:07 -0700

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of
> Michael Myers
> Sent: Wednesday, April 17, 2002 11:09 AM
>
> Hal,
>
> This works for me.  Thanks for stepping in.
>
> Mike

However, Peter Sylvester does make some good points. But since
this debate doesn't affect the requirements document Russ and
Denis are working to finalize (at least, I hope it doesn't) we
should probably reserve these cycles for the main event.

Mike

> -----Original Message-----
> From: Peter Sylvester [mailto:[email-masked]]
> Sent: Wednesday, April 17, 2002 12:54 PM
> To: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Open issue: DPV additional information
>
>
>
>