Subject: Re: roadmap

From: Peter Sylvester <[email-masked]>
Date: Fri, 26 Apr 2002 15:23:29 +0200 (MET DST)

> Michael,
> 
> > Peter,
> > 
> > v2's status mostly tracks that of the DPV and DPD requirements,
> > which have only recently settled down after about a year's worth
> > of effort.  
> 
> OCSP *cannot* be the right vector to support DPV requirements since the role
> of a CA is different from the role of a DPV server: a CA is only responsible
> for the certificates that it has issued. A DPV server can be any entity
> provided that it supports the appropriate validation policy which is *not*
> established by a CA. As another argument: having at the same time in the
> same response both a *single* OSCP response and a DPV response would be
> quite odd. The DPV response provides information which would make the
> *single* OCSP response useless. However the DPV response may include
> *several* OCSP responses *and* the full certification path, if requested by
> the client.
Without saying whether I support or not the idea of using OCSP, I
do not exactly understand the reasoning given above: 

  I do not see why your comparison a CA role and he possibilities of
  an DPV service has any relation with OCSP as a protocol:

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

- An 'authorised' CA DPV responder can create status information about
  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'.   

> 
> So my request is the same as made on the mailing list: RFC250bis should only
> be updated to allow to specify a certificate using additional ways. OCSPv2
> should be discontinued or at least the name "OCSPv2" dropped. This does not
> mean that some ideas from that protocol cannot be re-used to fit with the
> DPV requirements.

It might be a useful exercise to replace in 2650 all identifiers and structure 
names in the ASN1 definitions of RFC 2560 by i1, i2, .. and S1, S2 and see whether
one nderstand the text, in particular reqCert and CertID. 

> 
> However, this discussion is not directly related to the roadmap. ;-)
> 
> Denis
> 
> > As I said before, it didn't make much sense to track
> > that moving target with incremental I-Ds.  I once had three
> > separate I-Ds but that got so hard to manage and work due to
> > syntatic and editorial overlap (not to mention review) that I
> > put them all in one.  I prefer to keep that structure together
> > while we see how things shake out re: DPV/DPD.  Since 2560bis is
> > pretty well on its way, I think we should let that go forward
> > cleanly rather than force a reset due to adding new syntax.
> > 
> > Mike
> > 
> > Michael Myers
> > t: +415.819.1362
> > e: mailto:[email-masked]
> > w: http://www.traceroutesecurity.com
> > 
> > > -----Original Message-----
> > > From: [email-masked]
> > > [mailto:[email-masked]]On Behalf Of
> > > Peter Gutmann
> > > Sent: Tuesday, April 23, 2002 8:33 PM
> > > To: [email-masked]
> > > Cc: [email-masked]
> > > Subject: Re: roadmap
> > >
> > >
> > >
> > > Peter Sylvester <[email-masked]> writes:
> > >
> > > >Thus, it is not just a question of whether OCSP v2
> > > being alive or not.
> > >
> > > Can I also add a general complaint about the vague
> > > status of OCSPv2, there's
> > > already software deployed which uses the extended
> > > range of cert IDs in the v2
> > > draft, which makes it annoying to have it fading in
> > > and out of consciousness
> > > every few months.  Perhaps the new cert IDs (which
> > > are a trivial change) could
> > > be moved into 2560-bis, without requiring all the
> > > extra stuff which was added
> > > in the rest of the v2 draft.
> > >
> > > Peter.
> > >
>

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 26 Apr 2002 17:43:20 +0200

Peter,

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

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

>   provider likes to provide to its clients or what they need. OCSP is

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.

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.

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.

Denis