Nicolas Williams <> writes:

>Sorry, but this is wrong.  The OCSP protocol itself really is an online
>certificate status protocol.  

It's not an online certificate status protocol because it can provide neither
a yes or a no response to a query about the validity of a certificate.

(For an online status protocol I want to be able to submit a cert and get back
a straight valid/not valid response, exactly as I can for credit cards with
their authorised/declined response.  Banks were doing this twenty years ago
with creaky mainframes over X.25 and (quite probably) wet bits of string, but
we still can't do this today with multicore CPUs and gigabit links if we're
using OCSP).

>Responder implementations may well be based on checking CRLs, but they aren't
>required to be.

They may be, or they may not be, but you as a relying party have no way of 
telling.  OCSP covers not only the three incompatible business models of the 
different authors' employers but, for good measure, an extra "anything else 
you may care to do" option if the first three aren't enough.  A decade after 
it was published, PKI experts are still arguing over what various bits of the 
OCSP spec actually mean (the PKIX list has only just gone through yet another 
round of this... *ten years* later and domain experts still can't agree on how 
it's supposed to work).  So given the schizophrenic nature of the RFC you can 
easily claim "but you can do X" because chances are if you read it just right 
you probably can.  Unfortunately this doesn't give a relying party much to 
rely on, because they have absolutely no idea what they're getting, it could 
be anything from a live database query to a value from a month-old CRL to 
(thanks to the removal of nonces from the protocol a few years ago) an 
attacker replaying an old "not-revoked" value (although I don't know why 
they'd even bother with that, given the state of revocation checking in client 

In any event though since OCSP can't say yes or no, it doesn't matter whether 
the response is coming from a live database or a month-old CRL, since it's 
still a fully CRL-bug-compatible blacklist I can trivially avoid it with a 
manufactured-cert attack.


The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to

Reply via email to