[cabfpub] Profiling OCSP & CRLs

[Dimitris Zacharopoulos]

On 14/5/2017 2:49 πμ, Ryan Sleevi wrote:
>
>
> On Sat, May 13, 2017 at 11:47 AM, Dimitris Zacharopoulos 
> <jimmy at it.auth.gr <mailto:jimmy at it.auth.gr>> wrote:
>
>     This is a very good description of the situation and the
>     comparison of the security concerns between the Certificate
>     issuing system (certificates signed by a CA) and the OCSP
>     responder system (responses signed by either the CA or a delegated
>     OCSP responder), is fair.
>
>     Could we try to focus what should be expected for the off-line
>     Root CAs and their delegated OCSP responders? Roots that delegate
>     OCSP responses via OCSP responder Certificates and issue responses
>     for 12 months (per BRs 4.9.10), should probably have a minimum
>     lifetime of 12 months to match the validity of the OCSP response.
>     Currently, the BRs are silent about how an OCSP responder should
>     protect its key, so perhaps we could have similar (or the same)
>     protection controls for Private Keys associated with OCSP
>     Responder Certificates that are delegated from Roots, as the
>     Private keys associated with the Root Certificates.
>
>     Would it be reasonable to allow for 1-year OCSP responder
>     Certificates if the Private Key associated with that responder
>     certificate is treaded/protected similarly as the Root Private Keys?
>
>     Of course, it would take a while before CAs adapt to such a
>     change, especially for pre-generating OCSP responses and serving
>     them to web clients through a separate layer.
>
>
> As I mentioned to Tim, it takes more than 'just' protecting the 
> private key. You need a whole systemic architecture that ensures the 
> flow of information (and thus the inverse flow of compromise) 
> constantly flows down from the secure zone to the insecure zone.
>
> Obviously, there's a lot of loopholes in the current text for all 
> sorts of unquestionably insecure and unadvisable practices (of which 
> some CAs are engaged in), but it's certainly trying to work through 
> the security goal - which is that the 'worst case' for a revocation 
> should be bounded by some O(days) [with the text proposing O(30) as 
> the absolute upper bound], with leaf certificates bounded by less 
> (currently specified by MSFT as O(7 days), although they tried for 
> shorter)
>

Agreed. So, if we change the systemic architecture and add another layer 
and OCSP responses always flow from a secure zone to an insecure zone, 
but the "secure zone" is in fact a "high secure zone" which is where the 
Root Keys are stored, would this justify 1-year validity for the OCSP 
responder Certificate? As Tim said, CAs should not have to visit their 
off-line/air-gapped Root keys too often unless they have too (in case of 
a revocation of an Intermediate CA Certificate). That should include the 
keys associated with the Root OCSP responder certificate that would also 
be required to remain off-line or air-gapped per 1.c of the Network 
Security Controls.

Dimitris.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170514/eb6c6ce9/attachment-0003.html>