<div dir="ltr">On Mon, Aug 20, 2018 at 1:43 PM Doug Beattie <<a href="mailto:doug.beattie@globalsign.com" target="_blank">doug.beattie@globalsign.com</a>> wrote:<br><div class="gmail_quote"><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_1993634397130872619m_4895025950458080077m_4729844437079147131WordSection1"><p class="MsoNormal"><span style="color:#1f497d">Tim,<u></u><u></u></span></p><p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="color:#1f497d">I agree that Vulnerability is different from key compromise and the actions we take should reflect that and I think we should try to keep 12 and 13 type events in the 5-day list.<u></u><u></u></span></p><p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="color:#1f497d">Is our strategy to have vulnerabilities fall into the 5 day list and exploited vulnerabilities fall into the 24 hour list?<u></u><u></u></span></p><p class="MsoNormal"><b>Key Compromise:</b> A Private Key is said to be compromised if:<u></u><u></u></p><p class="m_1993634397130872619m_4895025950458080077m_4729844437079147131MsoListParagraph"><u></u><span>1)<span style="font:7.0pt "Times New Roman"">      </span></span><u></u>its value has been disclosed to an unauthorized person<u></u><u></u></p><p class="m_1993634397130872619m_4895025950458080077m_4729844437079147131MsoListParagraph"><u></u><span>2)<span style="font:7.0pt "Times New Roman"">      </span></span><u></u>an unauthorized person has had access to the private keys<u></u><u></u></p><p class="m_1993634397130872619m_4895025950458080077m_4729844437079147131MsoListParagraph"><u></u><span>3)<span style="font:7.0pt "Times New Roman"">      </span></span><u></u>a vulnerability has been exploited to disclose private keys<u></u><u></u></p><p class="MsoNormal">And the remainder of the definition can be removed because those are examples of vulnerabilities being exploited ( Debian weak  and poor key generation).  If we want a list of possible vulnerabilities or bad practices, then we can put in an appendix.<u></u><u></u></p><p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="color:#1f497d">I think #13 is a special case of #12 (both vulnerabilities), so I still recommend removing it.  Is the distribution of a private key in in a software package any different than the distribution of a private key in any other (insecure) method?  <u></u><u></u></span></p><p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="color:#1f497d">Here’s what I’d recommend:<u></u><u></u></span></p><p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="color:#1f497d">a) Use the new definition I listed above<u></u><u></u></span></p><p class="MsoNormal"><span style="color:#1f497d"> <u></u><u></u></span></p><p class="MsoNormal"><span style="color:#1f497d">b) change:<u></u><u></u></span></p><p class="MsoNormal"><span style="color:#1f497d">12. The CA is made aware of a vulnerability that exposes the Subscriber's Private Key to compromise; or<u></u><u></u></span></p><p class="MsoNormal"><span style="color:#1f497d">to<u></u><u></u></span></p><p class="MsoNormal"><span style="color:#1f497d">12. The CA is made aware of a vulnerability that has been exploited to disclose the Subscriber's Private Key; or<u></u><u></u></span></p><p class="MsoNormal"><span style="color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="color:#1f497d">c) Delete #13<u></u><u></u></span></p><p class="MsoNormal"><span style="color:#1f497d"><br></span></p></div></div></blockquote><div>Thanks for the proposal Doug. I like the direction, but:</div><div><br></div><div>* The new definition proposed for #12 makes it equivalent to key compromise, because to know that a vulnerability has been exploited the CA is going to prove key compromise. I'd propose:</div><div><br></div><div>12. <span style="color:rgb(31,73,125)"> The CA is made aware of a practical technique that exposes the Subscriber's Private Key to compromise; or</span></div><div><br></div><div>The intent being that disclosing a vulnerability isn't enough to trigger revocation, but a practical exploit is.</div><div><br></div><div>* if we adopt that definition for 12, then I agree that 13 can be removed.</div><div><br></div><div>* I think we should keep the language on weak keys in the definition of Key Compromise. Without it, I can see it being argued that weak keys fall under 12 and thus allow 5 days for revocation, or worse, don't require revocation at all.<br></div></div></div>