Re: [TLS] [pkix] Possible revocation delay issue with TLS stapling

[Sean Leonard <[e-mail]>]

On 3/25/2010 7:15 PM, Yngve N. Pettersen wrote:
>
>
> Hi,

Hi Yngve,

Thanks for the e-mail. I think that your idea has merit. However, I have 
three general questions/concerns that perhaps you could think about and 
respond to:

1. Technically, neither OCSP responses nor CRLs expire. Both have 
thisUpdate and nextUpdate fields--see RFC 2560 and RFC 5280. While one 
can causally refer to OCSP responses or CRLs expiring, think about the 
implications. If a certificate is identified as "revoked" in an OCSP 
response or appears in a CRL without a reason code or with any reason 
code other than "certificateHold", that is it for the certificate--the 
certificate is dead forever. nextUpdate is basically just a 
recommendation about when new information should be available.

As a thought exercise, consider having a CRL (or OCSP response) at time 
t > nextUpdate date. You look for a certificate c, and c's serial number 
appears on the list/in the response as "revoked" due to 
"privilegeWithdrawn". You try to fetch a new CRL or OCSP response. No 
dice--network down. What should you do? Validation of c should fail, 
because it has been revoked (specifically, it has been revoked at least 
as of the thisUpdate date, and possibly earlier). The fact that the CRL 
or OCSP response is "old" does not mean that it should be ignored.

(Note that if the OCSP response is "old" and the OCSP response says 
"good", you may want to ignore that response, effectively treating it 
like expiration. But see point 3 below.)

2.(a) Your suggestion says that "servers" must include this extension in 
requests. How does the OCSP responder verify that the requester is a 
"server"? It cannot. So, if the CA is concerned about the staleness 
problem, why not just update OCSP information for all OCSP requests on a 
shorter interval?

2.(b) Technically your proposal addresses the security issue (where a 
malicious server would just find a "long", good response by lying about 
whether it's a server) by modifying the client's behavior to check for 
the proposed extension, and if it's not present, then fetch a response 
directly from the responder. But if the OCSP responder (run by the CA or 
on behalf of the CA) is so concerned about load, it can just increase 
the delay time back to the interval that it used to use, and put the 
extension in. The net effect is that we wouldn't see much change.

3. As a practical matter, most OCSP responders rely on a master CRL 
list, which is published with the same frequency as OCSP responder 
thisUpdate and nextUpdate fields. If you are so concerned about the 
delay problem, it may make more sense for the CA to update all 
revocation information sources more often.

Thanks,

Sean