[cabfpub] Profiling OCSP & CRLs

[Tim Shirley]

Ah yes, good point.  Both the private key of the responder cert AND the system used to generate the OCSP responses need to have comparable protections/controls to the private key of the associated online CA AND the system used to generate certificates from that CA.  I believe if you achieve that, then you’ve done all you can do there, especially since the CA itself could be used to sign the responses directly if you’ve compromised the system to that degree.



That being said, I don’t see any insurmountable issues with requiring 30 day lifespans for online CA OCSP responders either.  Since the CA is online, renewal of its OCSP responders could be automated.  The challenging one is the offline CA case.  I’m not particularly fond of pre-production either, but didn’t have any better suggestions.  I agree the pre-produced responder certificates would have to be very carefully protected (ideally offline) in that scenario to provide any meaningful security improvement.  But perhaps the mechanism of deploying those responders wouldn’t have to be as much of a production as accessing the offline CA would be, since a leaked responder would only be useful if there was also a non-administrative need to revoke an online CA during (or prior to) the responder’s validity period.  That would enable the rotation to be performed more frequently than would otherwise be practical.  You’re still going to want a hard limit on how far in advance you could pre-produce them, but maybe that can be on the order of 6-12 months instead of having to access your root CA keys every 3 weeks or so to meet a 30 day requirement.



From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Thursday, May 11, 2017 12:18 PM
To: Tim Shirley
Cc: public at cabforum.org
Subject: Re: [cabfpub] Profiling OCSP & CRLs







On Thu, May 11, 2017 at 10:02 AM, Tim Shirley <TShirley at trustwave.com<mailto:TShirley at trustwave.com>> wrote:

Certainly the risk profile is greater for long-lived CRLs and long-lived OCSP responses than it is for long-lived OCSP responder certificates, since CRLs and OCSP responses could be replayed to hide a subsequent revocation without compromising the CA’s infrastructure, whereas doing bad things with a long-lived OCSP responder certificate would require the private key of the OCSP responder certificate to be compromised.



Well, no - it doesn't require the private key be compromised. I think that's an important and subtle point here.



Say I put my key in a FIPS 140-2 Level 3/4 HSM. That's great. I now connect a Web Server do it that talks to the HSM and says "Sign this Response" (e.g. to sign nonces). An attacker doesn't need to compromise the HSM to cause badness - they just need to compromise the Web Server.



That's the whole point - it requires a systemic design.



   So the most obvious suggestion to me is that we should have the same key protection requirements (e.g. HSMs) for OCSP responder keys as for online CA keys, at least for OCSP responder certificates with lifetimes over a certain threshold.  In that scenario, I don’t see a disadvantage to allowing validity that matched the lifetime of the CA itself, since the responder is no more vulnerable than the CA (assuming it’s an online CA.)



   See above for a specific scenario (for which I know of CAs having deployed) that substantially increases the risk.



   I recognize that there’s still a gap in security level for offline CAs though, in that their responders are at the security level of an online CA.  That’s the harder problem.  But addressing it with shorter validity requirements pushes a CA towards making their offline roots easier to access, which could cause more security harm than good.  Perhaps we could allow pre-production of a year’s worth of shorter-validity OCSP responder certificates as a mitigation against this without requiring the offline CAs to be accessed more frequently?  To get value out of this approach, though, the not-yet-in-service responders would need to be protected differently than the in-service one, so we’d need to come up with some rules around that to strike a balance between operational feasibility and security.



   I'm pretty staunchly opposed to pre-production, because it just means that the responses, if they leak, can be just as abused as a one-off access to the Web Server above. We'd almost have to keep the pre-generated responses 'offline' and only ensure one of them is 'online' at the time.



   I do agree though that there's a lot of flexibility here with how we guide the design of the system to achieve the overall security goals. PKIX affords substantial knobs and sliders - we just have to find the way to hit the security mark with them in a way that works for everyone :)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170511/83f60395/attachment-0003.html>