RE: OCSP - Wait A Minute!

[Anders Rundgren <anders.rundgren@xxxxxxxxx>]

Well,
Of course OCSP is implementable but the provider part seems impossible
to supply as a *packaged product*.  Why?  The connection between the OCSP
provider and the rest is not practical to cast in stone as there is no unified
system to connect to.  Or is it?  Seems like a component type of SW.

Now to a thing that you have misinterpreted.  The OCSP++ provider does not
have to do verification.  But it should be able to return issuer
certificates after a status check in order to let the client do validation
without requiring the certificate-user to use any other unspecified
method to acquire issuer certificates.  That is IMO a major *useful* addition
(but technically simple) and would make OCSP the *only* *protocol*
*you* *need* to access the "certificate store".  Would that not be something?

My TLS-thing was really just a specific implementation to support encrypted
certificates which apparently is not a concern in OCSP of today.  An addition
in the form of encrypted certificate should do the same job but complicates
things a bit.

You are right, signing does replace authentication.   Assuming that you *must*
encrypt certificate data, TLS authentication could replace signing.

I understand your concern for SW-manufacturers.  I am working for one myself :-)
that will depend on OCSP.

Anders

----------
From:  Dan Weinstein [SMTP:danw@netscape.com]
Sent:  Monday, August 17, 1998 01:34
To:  Anders Rundgren; ietf-pkix@imc.org
Subject:  Re: OCSP - Wait A Minute!

Anders Rundgren wrote:
> 
> 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.

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

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

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

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

 
Dan Weinstein
danjw1@hotmail.com