Re: OCSP - Wait A Minute!

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

I am voluntarily mixing up two issues here: 

- I think that some clean up of the text and maybe the content
  is necessary.
- I think that the proposed OCSP++ can be provided using the
  OCSP protocol as it stands today (with one small change).

> > 
> > Hi Dan,
> > I don't see how Netscape or anybody else can do packaged product
> > based on the OCSP-specification.
> 
> I am speaking as myself, NOT for Netscape.

OCSP is not a protocol that can be seem WITHOUT the client application
environment and the certification context. A client OCSP API is
easy to provide but it is not much more than a low level DNS lookup.
That's good and bad: 
It's good because the protocol allows other usages than the pure
revocation status test.
It's bad because what seems missing to me and others is a better
abstraction of what clients should validate. Building path building
logic and other stuff into a client seems bad to me but that's another
story, I would prefer this in an independant client service
In the current spec an OCSP++ or OCVP this is not part of OCSP,
so be it. It would be nice anyway if the author's could consider some
rewording to allow a reuse of great parts of OCSP for other
applications, i.e. to consider that revocation status test is
just one usage of the 'lower level' exchange of the data units etc.

> 
> > Will it be provided as a framework
> > where the customer does the actual implementation?  Particularly
> > the provider part seems pretty impossible to implement in a totally
> > general way.  And that is probably the way it should be.
> 
> What, specifically, isn't implementable?  How do you reconcile your
> assertion with the fact that a number of companies have been tracking
> the draft with implementations?
There arec two aspects: Server implementation, and client implementation.

I repeat that the specification of version 5 had silently dropped
the possibility of using a certificate in a request. This has been done
WITHOUT changing several parts of the text that still mention it. As 
a consequence the specification of certid should be revised 
and the text concerning certificates in a request be removed/corrected. 

I don't consider this as a big deal. One suggestion was for example to
have a null value(an octet string of length 0?) as a hash for the
issuer certificate. Although this is possible, I think this violates
the specification today. At least support for this in a server is
at least as difficult as implementing an optional context tagged value.

Furthermore, the ASN.1 spec is not correct: The definition for Extensions
is missing, probably because the orginal definition contains a list
of POSSIBLE extensions. :-)


> 
> > Anyway, I think you should put OCSP *on hold* to make it more universal.
> > In particular the requirement to have issuers certificates requires every
> > certificate user to also rely on other certificate service protocols or
> > other unspecified methods for acquiring issuer certificates.
> >
> > OCSP could *easily* do it all!
I support this idea, but I don't think that is necessary to put the
protocol definition on hold just for that reason, version 1 can support
this, it depends on how a server and a client INTERPRETE the protocol. 
A client should add an extension that says: "This is OCSP++" in the
request, adn check whether this is returned in the response.   

> 
> If all you are after is additional capabilities for OCSP, both requests
> and responses support extensions.  Extensions that prove that they are
> interesting in real world implementations will be folded back into
> version 2.  It seems foolish to me, to hold up version 1 for features
> that have already been discussed and rejected once for this version of
> the draft (which covers most of the changes I have heard suggested
> recently).
As far as I see nothing has been rejected that would require another
version of the protocol: please distinguish between version as
indicated in the value of version field or of a version of the document.
Extensions do not need a change in the version field. 

> 
> > 
> > Please take a look on
> > 
> > http://www.jaybis.com/specifications/pkix/ocsp.html
> 
> I took a look at this.  The best I can tell, you suggest 2 changes for
> OCSP, required TLS/SSL and the ability for the server to perform
> validation.  Requiring TLS/SSL is a bad idea.  One reason you suggest
> this is to allow client auth, but that is not necessary because a signed
> request buys you the same thing, with less overhead.  The other reason
> that you suggest requiring TLS/SSL is for encryption of requests and
> responses.  I can imagine quite a few uses for OCSP where encrypting the
> sessions would just add overhead.  The option of using TLS/SSL is
> already in the OCSP draft, requiring its use only adds what may be
> unnecessary overhead.  As for the server being capable of certificate
> validation, I think that is already well covered teritory.
I seem to support this view. Privacy between verifier and provider can
also be provided using lower level protection, authentication and 
integrity are provide by OCSP as it stands today. 

Peter Sylvester