On Jul 28, 2010, at 10:23 AM, Peter Gutmann wrote:

> Nicolas Williams <nicolas.willi...@oracle.com> 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.  

It might not be hard to determine whose OCSP responders are CRL based and whose 
are database backed instead.  

> 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).

Yes we can, and some actually do.

>> 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.  

Even the most savvy of relying parties probably has no way of caring.  They 
want to know when something is positively revoked, and having a definitive Yes 
is a nice distinction, but having a definitive Not-Revoked appears to be good 
enough for most.  

> 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.

You're right: a manufactured-cert attack is going to really hurt that kind of 
an OCSP responder.

Is a manufactured-cert a trivial thing to create?  

Paul Tiemann

The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majord...@metzdowd.com

Reply via email to