Subject: Re: roadmap

From: Peter Sylvester <[email-masked]>
Date: Fri, 26 Apr 2002 19:36:46 +0200 (MET DST)

>  
> > - A "trusted" OCSP responder which is not a CA or an authorized responder
> >   can also issue status information based on his own local policy not
> >   established by a CA, it can have its own 'revocation service' based
> >   on the needs of the relying party.
> 
> So a trusted OCSP responder provides the revocation status information of a
> *single* certificate and has nothing to do with a DPV server that does much
> more on a *chain* of certificates.
The point was that the structure of OCSP trust delegations, i.e., the modes
of CA, authorized responder and trusted responder provide sufficient possibilities
so that trust among a DPV client and services can be establish in a same way.

A potential addition to the OCSP protocol you turn a server which was is trusted
by the client using one of the existing OCSP trust mechanism into a service that
is implmenting the DPV requirements, i.e. into a DPV server that youses an enhanced 
OCSP protocol.

> 
> > - An 'authorised' CA DPV responder can create status information about
> 
> An " 'authorised' CA DPV responder" is not a correct wording: either it is a
> CA or a DPV responder.
I am talking about an extended OCSP protocol implementing the DPV
requirements operated by an authorized OCSP responder. 

> 
> >   its immediately subordinate certs, i;e. the single OCSP response that you
> >   mention, and at the same time include some DPV response that validate
> >   the path from the intermediate CA to the trusted root, either
> >   as an entity extension or as a global extension.
>  
> > - An OCSP server can also be any entity, and not just an authorised
> >   CA responder. An OCSP responder can respond to whatever the service
> >   provider likes to provide to its clients or what they need. OCSP is
> >   not a 'A CS service'.
> 
> An OCSP server basically provides the revocation status of a certificate and
> may support extensions in addition to that basic response. Up to now, such
> extensions have not been defined.
Obviously not, since we are not at the point of defining a protocol. As far
as I have understood, Mike is waiting until the DPV reqs get settled. 

> 
> Since a DPV response is far richer than a DPV response, it would be quite
> strange to use the content of the extension and to discard the main
> response.
Who has proposed to discard something?

> Picky-backing the DPV structure in an extension of the OCSP structure would
> also lead to a strange behaviour. You could get a "valid OCSP answer" with
> an "invalid DPV answer" (e.g. because a certificate from the chain is
> revoked). These two statuses do not match together.
Why do you think that the DPV server should indicate that the
certificate is good. Again, I am not advocating OCSPv2 which some people
may consider as repaied/enhanced by technique to similar as for
the Hubble telescope.

---

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

Peter,

I believe that we fixed the wording of the roadmap. So the original goal of
this thread is met.

On the other topic whereas OCSP could be extended to support DPV
requirements, we have different views.

Let wait until the DPV requirement document is finished and come back to
that topic later on, if needed.

Denis