Re: fast review of draft-ietf-pkix-ocsp-06.txt

[Peter Sylvester <Peter.Sylvester@xxxxxxxxxx>]

> All,
You :-) ,

> 
> The intent was to provide an alternative to CRLs.  Following that model,
> there's an underlying assumption that the end-entity is in possession of
> the CA's certificate (as would be needed to validate the signature on a CRL.)
This is a description that is somewhat strange.

What is an alternative to CRLs? Read part1 of pkix. An alternative is 
something that replace completely the usage of CRLs. CRLs by definition
are one means to detect revoked certs, YOUR intention was to have just
access to a remotely manged CRL. 

There has been a lot of discussion that OCSP is a service that allows
what it says in its definition, online status verification, and not just
lookup of a remote CRL base. A lot of effort has been made to ensure that
a minimal OCSP service can actually implemented using CRLs, otherwise
one may have just used a certHash in the request, and not used the
serial number.

Anyway, an alternative has not a defined model, so what do we have to follow?
And why is there any underlying model. This is NOT documented in OCSP, and
the contrary seems to be indicated in pkix part 1. 

Splitting a local logic that looks into a list a CRLs into a client server
protocol MAY require additional security (as it is mentioned in pkix part1).

You MAY require that a request an a response to be signed by requestor
and the responder sign the response. A server MAY require that the client
proves in some way that it is actually in possession of a cert, or
whatever else you can image. 

Or: CRLs are ONE way to obtain status information of certs OCSP is not
a client server implemention of CRL lookup but a general mecanism to
obtain status information about certificates, and it CAN be implemented
using just CRLs on the server side but it is open to provide MORE service.
     

> 
> OCSP never had a requirement to validate an end-entity certificate in the
> absence of the CA certificate at the requestor end.  It's not just a
> requirement on syntax at the request.  This would also imply path
> validation logic on the server.  The consensus has been conclusively
> established that full certificate validation is beyond the scope of this
> protocol.
> 
The first version of the protocol allowed just to present a certificate
in a request. Whether the client actually has the corresponding cert
before or after the validation is left to the client.

Denis proposal does not put any requirement for path validation on the 
server, on the contrary,

The server otherwise tell: I know about ONE CA and it's public key hash
is what I return in the response. It the request needs to contain a key
hash, the server MUST validate the public key in order to return 'unknown'
if it doesn't match. Thus, in some sense the actual text requires
validation on the server, and Denis' proposal removes that requirement. 

The only TECHNICAL problem that can happen is that the server KNOWS about
more than ONE certificate having the SAME serial number and the same CA name.
In this case the server should return the status of all of them, 
and let the client decide. 


> There's consequently no need to alter the request syntax.

You can always deduce everything from an empty or false premises.

Peter