<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<br>
<br>
<div class="moz-cite-prefix">On 14/5/2017 2:49 πμ, Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvbK-OhF0_XBQOtcspeS-kmYU5wjR7=r+1qsW-k+WCWjgQ@mail.gmail.com">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Sat, May 13, 2017 at 11:47 AM,
Dimitris Zacharopoulos <span dir="ltr"><<a
href="mailto:jimmy@it.auth.gr" target="_blank"
moz-do-not-send="true">jimmy@it.auth.gr</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div text="#000000" bgcolor="#FFFFFF"> 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.<br>
<br>
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. <br>
<br>
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? <br>
<br>
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.<br>
</div>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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) </div>
</div>
<br>
</div>
</div>
</blockquote>
<br>
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.<br>
<br>
Dimitris.<br>
</body>
</html>