<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body 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>
<br>
<br>
Thanks,<br>
Dimitris.<br>
<br>
<br>
<div class="moz-cite-prefix">On 11/5/2017 10:00 μμ, Ryan Sleevi via
Public wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CACvaWvZPN6JF3mi3KBh5FtPv5KTsyjNm3WD67PcYc9R+xwucmA@mail.gmail.com">
<div dir="ltr"><br>
<div class="gmail_extra"><br>
<div class="gmail_quote">On Thu, May 11, 2017 at 2:28 PM, Tim
Shirley <span dir="ltr"><<a
href="mailto:TShirley@trustwave.com" target="_blank"
moz-do-not-send="true">TShirley@trustwave.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div class="m_-2348860531962428775WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">Ah
yes, good point. Both the private key of the
responder cert AND the system used to generate the
OCSP responses need to have comparable
protections/controls to the private key of the
associated online CA AND the system used to
generate certificates from that CA. I believe if
you achieve that, then you’ve done all you can do
there, especially since the CA itself could be
used to sign the responses directly if you’ve
compromised the system to that degree.</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yup. Exactly this - it's trying to find how to capture
this in the BRs in a meaningful way :)</div>
<div> <span
style="color:rgb(31,73,125);font-family:Calibri,sans-serif;font-size:11pt"> </span></div>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div link="blue" vlink="purple" lang="EN-US">
<div class="m_-2348860531962428775WordSection1">
<p class="MsoNormal"><span
style="font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1f497d">That
being said, I don’t see any insurmountable issues
with requiring 30 day lifespans for online CA OCSP
responders either. Since the CA is online,
renewal of its OCSP responders could be
automated. The challenging one is the offline CA
case. I’m not particularly fond of pre-production
either, but didn’t have any better suggestions. I
agree the pre-produced responder certificates
would have to be very carefully protected (ideally
offline) in that scenario to provide any
meaningful security improvement. But perhaps the
mechanism of deploying those responders wouldn’t
have to be as much of a production as accessing
the offline CA would be, since a leaked responder
would only be useful if there was also a
non-administrative need to revoke an online CA
during (or prior to) the responder’s validity
period. That would enable the rotation to be
performed more frequently than would otherwise be
practical. You’re still going to want a hard
limit on how far in advance you could pre-produce
them, but maybe that can be on the order of 6-12
months instead of having to access your root CA
keys every 3 weeks or so to meet a 30 day
requirement.</span></p>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yup. You've exactly hit on what the goal is - and now
trying to figure out how to word the requirements to
capture. I put 30 days as what I would like to see the
_effective security goal_ as, and with the hope that if we
can reasonably agree on that as the desirable goal, we can
figure out how to design/require the system to achieve
that, even if the functional validity is greater than :) <br>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
Public mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Public@cabforum.org">Public@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://cabforum.org/mailman/listinfo/public">https://cabforum.org/mailman/listinfo/public</a>
</pre>
</blockquote>
<br>
</body>
</html>