On 14/5/2017 2:49 πμ, Ryan Sleevi wrote:
On Sat, May 13, 2017 at 11:47 AM, Dimitris Zacharopoulos
<[email protected] <mailto:[email protected]>> 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.
_______________________________________________
Public mailing list
[email protected]
https://cabforum.org/mailman/listinfo/public
