<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, May 10, 2017 at 5:10 PM, Bruce Morton <span dir="ltr"><<a href="mailto:Bruce.Morton@entrustdatacard.com" target="_blank">Bruce.Morton@entrustdatacard.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">





<div lang="EN-US">
<div class="gmail-m_-487759326483859446WordSection1">
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">In addition to CRLs, are revocations of issuing CAs not also addressed with CRLSets, OneCRL and certificate blacklisting?</span></p></div></div></blockquote><div><br></div><div>Well, only in as much as CAs' practices related to revocation haven't been good enough ;)</div><div><br></div><div>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.</div><div><br></div><div>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 :)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div lang="EN-US"><div class="gmail-m_-487759326483859446WordSection1"><p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="font-size:11pt;font-family:calibri,sans-serif;color:rgb(31,73,125)">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.</span></p></div></div></blockquote><div><br></div>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.<div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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.</div><div><br></div><div>Happy to elaborate the security concerns, although they're captured in 5280 and pretty well clear from technical implications :)</div></div><br></div></div>