Subject: More problems with OCSP

From: [email-masked] (Peter Gutmann)
Date: Fri, 6 Nov 1998 22:03:07 (NZDT)

I knew there was something I forgot in the previous message...
 
The use of CertID isn't at all clear.  Firstly, I assume that "hash of the 
subject key field" means a hash of the subjectPublicKey rather than the 
subjectPublicKeyInfo (is this correct)?  However once you've done that, there 
isn't really much you can do with the result.  How are you supposed to look up 
a certificate with the resulting OCTET STRINGs and whatnot without enumerating 
each one and hashing whatever you need until you find a match?  The only way I 
can see for doing this is by adding a whole series of extra attributes to your 
key database/directory containing every possible combination of hash algorithm 
and hash type for the different fields - each cert would need to be stored 
with the hash of issuer DN and key for every conceivable hash algorithm type 
which someone might use in a request.
 
I'm assuing here that the OCSP server acts as a go-between between some CA/CRL 
repository and the user (ie that it consults some sort of directory for 
certificate information and uses that to build a local cache of info which it 
doles out to requestors).  However since you can't consult a directory based 
on a CertID you don't really get very far unless the OCSP server is run by the 
issuer, who has an unambiguous means of mapping a serialNumber to a 
certificate which it issued.  For anyone else, a random octet string and 
integer as a cert ID aren't useful for anything because finding the issuer 
involves reversing the hash function.
 
Has anyone actually tried to implement OCSP before?
 
[If you need a way to uniquely identify a cert, might I suggest the 160-bit 
 SHA-1 hash of:
 
  SEQUENCE {
    issuerKey           SubjectPublicKeyInfo,
    serialNumber        CertificateSerialNumber
    }
 
 Then define a new attribute certificateID and get everyone to store this 
 alongside the cert.  Given the unhealthy practice of renewing keys, it may be 
 necessary to include some sort of generational qualifier as well]
 
Peter.

---

From: Rich Salz <[email-masked]>
Date: Fri, 6 Nov 1998 20:18:11 -0500 (EST)

>As an OCSP server, you would need to build an index of the hashes of either
>the issuerDN or the issuerpublickey for all the CAs you plan to serve as an
>OCSP responder.
 
 This is why I thought it a mistake why removing the ability to send the
 whole cert was a mistake at the end of the OCSP development.  For the
 sake of some network traffic, a severe implmentation constraint was
 imposed.  Unfortunately my view wasn't in the consensus.

---

From: Alan Lloyd <[email-masked]>
Date: Tue, 17 Nov 1998 10:58:39 +1100

> -----Original Message-----
> From:	Peter Gutmann [SMTP:[email-masked]]
> Sent:	Saturday, 7 November 1998 22:19
> To:	[email-masked]; [email-masked]
> Subject:	Re: More problems with OCSP
> 
	[Alan Lloyd]  snip
>   Given a query with an arbitrary
> CertID, it's not possible for an OCSP responder to provide a useful
> response.
	[Alan Lloyd]  Yes - thats precisely why I said OCSP is a
mechanism - not a system design. No information or system model or HOW
it relats to the real world of scaleable systems and their knowledge
properties - makes OCSP a "mechanism".
	regards alan