Subject: RE: OCSP identifiers

From: Simon Tardell <[email-masked]>
Date: Mon, 20 Nov 2000 13:45:07 +0100

> Margus,
> 
> We agree, especially regarding the observation that OCSP 
> isn't and should't be tied to CRLs.  
> 
> I don't see any problem against including cert hash among
> OCSP's certificate identification options.  Unless somebody
> raises a significant objection, I'll put it in.

Mike,

I object. In principle issuerAndSerial should be enough. 

The public key hash (of CertId) was introduced to guarantee that the client
and responder agreed on what the issuer cert was, but I think this is better
done in an out-of-band manner (the responder cert, or its issuer's cert,
which may very well be the same cert, must still be installed into the
client in an out-of-band manner). The hashing of the issuer DN (by an
algorithm of the client's choice) I think was a bad move, it creates
unnecessary complexity in the responder. 

CertHash is proposed to solve the problem of compromise of the issuer key.
It turns the question from a revocation query to an issuance query. It also
turns the responder from being someone who answers on delegation into
someone who is an authority on its own (i.e. it can, in effect, invalidate
the issuer). While the solution is fine as a solution to that problem (and
also is mandated in certain PKIs), it is not the only solution to that
problem, and it brings complication if you don't want to use that solution,
or don't care about that problem. Hence certHash should not be the primary
identifier of a certificate. It could be used as a single request extension,
to qualify the query, though. (Question: A query about an identifier that
the responder can't resolve, e.g. a certHash, is it 'unknown' or
'malformedRequest'?)

While CRLs are a bad way of answering revocation queries, I don't think they
are irrelevant to OCSP responders. CRLs are a way to serialize (snapshot)
the revocation status of a CA's issued certs at one point in time, and as
such useful to bootstrap the cache of an OCSP responder. This is important
if you want availability. If certHash is made a primary certificate
identifier, this doesn't work anymore. There is no corresponding format for
making a snapshot of the issuance status of CA's issued certs (a CIL?). Nor,
do I think, should there be.

Simon.

Simon Tardell, Software Architect, SmartTrust
voice +46 8 7755225, fax +46 8 7267912, cell +46 70 3198319
[email-masked], http://www.smarttrust.com

---

From: Margus Freudenthal <[email-masked]>
Date: Mon, 20 Nov 2000 16:22:20 +0200

Hello.

Simon Tardell wrote:
> the issuer). 

Well, OCSP response is currently signed by OCSP responder (which may or
may not be the CA).  If you do not trust the OCSP responder, then even
CRL-based OCSP service can't give you satisfactory answers because they
do not contain CA's signature.  If you want assurance given by CA, you
should download the CRL and ceck it (and steer clear of the OCSP
protocol).

-- 
Margus Freudenthal                               [email-masked]
Cybernetica                                      http://www.cyber.ee/