[cabfpub] Profiling OCSP & CRLs

[Ryan Sleevi]

On Thu, May 11, 2017 at 10:02 AM, Tim Shirley <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/f1f76c95/attachment-0003.html>