[cabfpub] [EXTERNAL]Re: Profiling OCSP & CRLs

[Ryan Sleevi]

On Wed, May 10, 2017 at 5:10 PM, Bruce Morton <
Bruce.Morton at entrustdatacard.com> wrote:

> In addition to CRLs, are revocations of issuing CAs not also addressed
> with CRLSets, OneCRL and certificate blacklisting?
>

Well, only in as much as CAs' practices related to revocation haven't been
good enough ;)

I haven't touched on CRLs yet in the profile, if only to make sure we have
opportunity to discuss the general goals and concerns, since applying them
to CRLs is much simpler (due to the nature of generation), and figured
let's get the contentious stuff discussed first :) But I certainly would
want to see CRLs required for intermediates, and with a (more frequent)
issuance practice.

So please don't take the asymmetry from OCSP / CRLs as a final state -
rather, let's figure out the shape of revocation for the hard stuff, and
then I'll happily work to bring the same to CRLs :)


>
>
> For OCSP, an approach for an off-line root is to have the OCSP response
> signed daily by an OCSP responder. This means that we would not have any 1
> year OCSP responses.
>

For OCSP, however, if that OCSP Responder is compromised (and realize we
don't have any/many controls around it), then it will invalidate the
trustworthiness of _all_ responses for a year.

This is what I meant by not trying to be disagreeable, and why transparency
from CAs is good, so we can find how the best practices to ensure an
appropriate/equivalent level of security. For example, an 'insecure' OCSP
responder is one which is signing responses on the fly and live-generating
responses. I know several member CAs do that, and in those cases, you want
the lifetime of the OCSP responder (and the key) to be low, since the key
is at greater risk.

You could make that more secure by having the OCSP responder 'airgapped' or
directional in some form - meaning the CA's "secure" system generates the
OCSP responses and then pushes them from a secure zone to an insecure zone
(a CDN).

Of course, we also have to address pre-generating OCSP responses and OCSP
responder certificates (that is, cases where thisUpdate/notBefore is
'later' than the current time by some period, say, 2 weeks). But that's
what I meant by the broader spectrum of parameters that we want to nail
down.

Happy to elaborate the security concerns, although they're captured in 5280
and pretty well clear from technical implications :)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170510/1ba99ab0/attachment-0003.html>