I agree 2560's lack of algorithm agility is a problem and RFC6960's lack of specifying an indicator of which algorithm to use is also a little problematic; that said it is one that can be worked around in most cases.
One likely way is that responders will rely on the User Agent header to determine platform support for a given behavior and if algorithm support isn't explicitly known fallback to SHA1; this can help accelerate the adoption of SHA2 in OCSP but the larger platform adoption problem still exists. It takes roughly 10 years from release of Windows to 98% ubiquity; that mean we better hope Windows adds support for RFC6960 soon so that clock can start ticking. Has support been added to OpenSSL yet? -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Jakob Bohm Sent: Friday, June 14, 2013 5:00 PM To: [email protected] Subject: Re: Why CA-signed OCSP responders are a bad idea [WAS:Is it me or is ocsp.comodoca.com doing something wrong?] On 6/15/2013 1:15 AM, Ryan Hurst wrote: Thanks for your reply, just one tidbit that surprised me: > > CAs are required to produce responses every 7 days, we comply with > that but as part of our new infrastructure investment we will be > bringing that time down quite a bit; the largest issue here being time > skew on the broader internet. This introduces practical limits that > mean that you cant be "too fresh" on your revocation times. > > It also means producing fresher responses 100s of times a day isn't of > much value, you can of course update the changes in the cached > responses set to be accurate but fresher / shorter lived responses end > up breaking things for a reasonably large % of users. > Ahh, I never heard about this 7 day rule, the closest I had previously heard was a CSP for a (now essentially defunct) national CA, which required CRL update delays of 1 minute or less from compromise reports, and those were not even qualified certs! From this I kind of surmised that OCSP validity times > 5 minutes would be as unsupported as DNS TTLs > 1 month. > I believe this approach addresses most of the concerns you mentioned > bellow, a few exceptions: > > ... You missed another concern: The need to use old dubious signature algorithms for the next 10 years, due to the late publication of RFC6277, the failure to require in the spec that clients must accept the alg used to sign the cert and the failure of even the latest RFC6960 to specify anything other than SHA-1 and SHA-256, and the failure to provide any request indication that a client implements anything post-RFC2560 (you could be lucky to receive a redundant algorithm list specifying the defaults from some post RFC6277 clients). Enjoy Jakob -- Jakob Bohm, CIO, Partner, WiseMo A/S. http://www.wisemo.com Transformervej 29, 2730 Herlev, Denmark. Direct +45 31 13 16 10 This public discussion message is non-binding and may contain errors. WiseMo - Remote Service Management for PCs, Phones and Embedded ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected] ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List [email protected] Automated List Manager [email protected]
