<div dir="ltr">Doug,<br><div><br><div class="gmail_quote"><div dir="ltr">On Thu, Aug 23, 2018 at 12:26 PM Doug Beattie <<a href="mailto:doug.beattie@globalsign.com">doug.beattie@globalsign.com</a>> wrote:<br></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_-6343484738600091898WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Wayne and Ryan,<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">I received some good out-of-band suggestions so I’m passing those along.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Generally - though not always (e.g. zero days) - attacks are seen as 'possible', then 'feasible' before they become 'demonstrable'; there's nothing stopping CAs (at their own discretion) from requiring reissuance of customer certs based on a possible/feasible attacks - long before the risk of the attack becoming demonstrable.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">CAs adopting this methodology may stay ahead of the game (as much as one can) by proactively reissuing certs for keys that 'may' (possibly/feasibly/reasonably) be at risk of an attack‎. This provides better security to customers, the ecosystem, and has the large potential to drastically reduce the number of certs that need to be revoked and reissued within 5 days if this methodology becomes proven or economically feasible. Regardless of how CAs handle these in the possible/feasible/reasonable categories, drawing the line at demonstrated/proven seems like a reasonable statement for triggering the 5 day revocation rule.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> </span></p></div></div></blockquote><div>></div><div>If this is to be a 5-day requirement, then I think it needs to move out of the definition of Key Compromise as you originally suggested. Key Compromise is inextricably linked to the 24-hour revocation window. Are there concerns with allowing 5-days to revoke vulnerable certificates?<br></div><div>><br></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_-6343484738600091898WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">How about something like this:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">**Key Compromise**: A Private Key is said to be compromised if: a) its value has been disclosed to an unauthorized person, b) an unauthorized person has had access to the private key, or c) there exists a demonstrated or proven method to obtain the Private Key.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> </span></p></div></div></blockquote><div>></div><div>This is awfully close to the new #11: <span class="gmail-blob-code-inner gmail-blob-code-marker-addition">The CA is made aware of a practical technique that exposes the Subscriber's Private Key to compromise.</span></div><div><span class="gmail-blob-code-inner gmail-blob-code-marker-addition"><br></span></div><div><span class="gmail-blob-code-inner gmail-blob-code-marker-addition">I would still like to have the example of Debian weak keys somewhere, but it could be under #11 if we agree that 5-days for revocation is acceptable. I'm also okay with tweaking the language to "demonstrated or proven method" if you prefer, resulting in:</span></div><div><span class="gmail-blob-code-inner gmail-blob-code-marker-addition"><br></span></div><div>11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise, methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see <a href="http://wiki.debian.org/SSLkeys">http://wiki.debian.org/SSLkeys</a>), or if there is clear evidence that the specific method used to generate the Private Key was flawed.<span class="gmail-blob-code-inner gmail-blob-code-marker-addition"><span class="gmail-blob-code-inner gmail-blob-code-marker-addition"></span></span>
        
</div><div><br></div><div>- Wayne</div><div><br></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_-6343484738600091898WordSection1"><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Doug<u></u><u></u></span></p><p class="MsoNormal"><a name="m_-6343484738600091898__MailEndCompose"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></a></p><span></span><div><div style="border:none;border-top:solid #e1e1e1 1.0pt;padding:3.0pt 0in 0in 0in"><p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Public <<a href="mailto:public-bounces@cabforum.org" target="_blank">public-bounces@cabforum.org</a>> <b>On Behalf Of </b>Doug Beattie via Public<br><b>Sent:</b> Thursday, August 23, 2018 1:38 PM<br><b>To:</b> Ryan Sleevi <<a href="mailto:sleevi@google.com" target="_blank">sleevi@google.com</a>><br><b>Cc:</b> <a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>; CABFPub <<a href="mailto:public@cabforum.org" target="_blank">public@cabforum.org</a>><br><b>Subject:</b> Re: [cabfpub] [Servercert-wg] [EXTERNAL]Re: Ballot SC6 - Revocation Timeline Extension<u></u><u></u></span></p></div></div><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Exactly, let’s try to improve the language.<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">If anyone has some better idea for how to replace this with the intended purpose, let’s hear it!<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">“A Private Key is also considered compromised if methods have been developed that can easily calculate it based on the Public Key (such as a Debian weak key, see <a href="http://wiki.debian.org/SSLkeys" target="_blank">http://wiki.debian.org/SSLkeys</a>) or if there is clear evidence that the specific method used to generate the Private Key was flawed.”<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Maybe:<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">“a vulnerability has been exploited to disclose private keys”<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">“there exist documented methods that can be used to easily extract and release Private Keys”  (we may need to define easily in terms of some measure of difficulty)<u></u><u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d"><u></u> <u></u></span></p><p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1f497d">Doug<u></u><u></u></span></p></div></div></blockquote></div></div></div>