On Thu, May 11, 2017 at 10:02 AM, Tim Shirley <[email protected]> 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 :)
_______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
