Re: Candidate for moving OCSP to a Draft Standard

[pgut001@xxxxxxxxxxxxxxxxx (Peter Gutmann)]

Juergen Brauckmann <brauckmann@xxxxxxxxxxxxxx> writes:

>In the ISISMTT stuff there is a similar OCSP extension which is intended to
>allow the server to send the hash of the certificatein question back to the
>client.
>
>The problem with a simple boolean is IMO that it's not sure whether server and
>client are talking about the same certificate.

I gave up on all the strange identifiers which people keep inventing for certs
in PKI protocols and just put an ESSCertID in all my requests (OCSP, CMP, etc
etc), which solves the problem nicely :-).

>If we worry about certificates with a valid signature that may not be issued
>by a CA, than it should be possible for the client to check somehow that the
>server knows not only about a certificate which happen to have an IssuerDN and
>a serialnumber identical to that the client has, but that is entirely
>identical to it. This can be achieved by a server which sends a hash of a
>certificate back to the client, and the client then checking this hash.

That's another way of doing it... I went for the client-supplied-hash because
then the responder can be implemented as a straight lookup in an in-memory hash
table, which is extremely fast and efficient.

>In a normal PKIX way of doing status checking and path validation, you don't
>need to worry about never issued certificates.

You do for CMP, which speculatively issues certs to EEs.

(You also have the problem that if you design a system in which you wish away
 certain hard security problems, you end up in serious trouble if any of those
 problems do ever occur.  I'd rather be paranoid and cover all the angles, even
 the ones which should never occur).

Peter.