<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal>I think the ROCA vulnerability shows pretty clearly that even generation by secure hardware can have its issues, so I think it’s premature to attempt to shut down the discussion by pointing to all the pomp and ceremony around ICA generation.<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><p class=MsoNormal>-Tim<o:p></o:p></p><p class=MsoNormal><o:p> </o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b>From:</b> Ryan Sleevi <sleevi@google.com> <br><b>Sent:</b> Thursday, September 3, 2020 12:45 PM<br><b>To:</b> Tim Hollebeek <tim.hollebeek@digicert.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><br><b>Cc:</b> Christopher Kemmerer <chris@ssl.com><br><b>Subject:</b> Re: [Servercert-wg] Proposed ballot: Minimum expectations regarding weak keys<o:p></o:p></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>Tim,<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>While in principle, I agree that it would be extremely unfortunate, I don't see the same gap as you. That is, it seems like that's an issue already controlled for with respect to key generation and protection requirements. Could you more concretely describe (perhaps using past issues, i.e. those that CAs would be looking for) a scenario that would make it through the existing controls?<o:p></o:p></p></div><div><p class=MsoNormal><o:p> </o:p></p></div><div><p class=MsoNormal>As you note, the fact that these are not Subscriber keys is extremely relevant: the CA has controls (for self-generated) and assurances (for 3P CA generated, via audit reports and the requirements) on key generation that don't apply to Subscriber certs. As such, I'm having trouble seeing the same risk, and if there is any (from Roots or Sub CAs), it seems like we can and should tackle that through the ceremonies/generation time, rather than at signing time. So I don't support tweaking this for ICAs, now or in the future, but am open to understanding more about the problems you see, so we can look for a more systemic fix, if the existing controls aren't sufficient.<o:p></o:p></p></div><p class=MsoNormal><o:p> </o:p></p><div><div><p class=MsoNormal>On Thu, Sep 3, 2020 at 12:33 PM Tim Hollebeek via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<o:p></o:p></p></div><blockquote style='border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-right:0in'><div><div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>One of the things we’ve noticed before is the fact that these requirements are in the section for Subscriber keys, therefore there are no weak key check requirements for roots and ICAs.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>We think that’s worth fixing. If CAs have to implement these checks for subscriber certificates, it should be pretty straightforward to run these checks when creating ICAs as well.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>The requirements for ICAs may need some tweaking, since there are some substantial differences in use cases, but I wanted to find out if there is any interest from others on fixing this loophole as well, either in this ballot or another one.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>It would be extremely unfortunate if a certification authority issued an ICA with a key that is known to be compromised, for example.<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'>-Tim<o:p></o:p></p><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><div style='border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt'><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'><b>From:</b> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank">servercert-wg-bounces@cabforum.org</a>> <b>On Behalf Of </b>Christopher Kemmerer via Servercert-wg<br><b>Sent:</b> Thursday, September 3, 2020 10:48 AM<br><b>To:</b> Doug Beattie via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br><b>Subject:</b> [Servercert-wg] Proposed ballot: Minimum expectations regarding weak keys<o:p></o:p></p></div></div><p class=MsoNormal style='mso-margin-top-alt:auto;mso-margin-bottom-alt:auto'> <o:p></o:p></p><p style='margin-bottom:12.0pt'>Greetings,<br><br>We propose the following amendments to language in the CA/B Forum in Baseline Requirements, taking into account the proposed changes from SC35: Cleanups and Clarifications (as documented in <a href="https://github.com/cabforum/documents/pull/208" target="_blank">https://github.com/cabforum/documents/pull/208</a>). <br><br>The purpose of this ballot is to set minimum expectations for CAs regarding industry-proven methods to generate weak private keys, and more specifically to ROCA and Debian weak keys. This topic was discussed in m.d.s.p. on several occasions and in various CA public incidents.<br><br>Regards,<br><br>Chris Kemmerer<br>SSL.com<br><br>=====<br><br>Proposed ballot language:<o:p></o:p></p><p>4.9.1.1 Reasons for Revoking a Subscriber Certificate <o:p></o:p></p><p><br><b>Replace: </b><br><br>The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: <br><br>[…] <br><br>11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise or if there is clear evidence that the specific method used to generate the Private Key was flawed. <br><br><b>With </b><br><br><br>The CA SHALL revoke a Certificate within 24 hours if one or more of the following occurs: <br><br>[…] <br><br>11. The CA is made aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise; <br><br>12. There is clear evidence that the specific method used to generate the Private Key was flawed; or <br><br>13. The certificate was issued with a weak key (such as a Debian weak key, see 6.1.1.3). <br><br>--- <br><br>6.1.1.3. Subscriber Key Pair Generation <br><br><b>Replace: </b><br><br>The CA SHALL reject a certificate request if one or more of the following conditions are met: <br><br>The Key Pair does not meet the requirements set forth in Section 6.1.5 and/or Section 6.1.6; <br><br>There is clear evidence that the specific method used to generate the Private Key was flawed; <br><br>The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise; <br><br>The CA has previously been made aware that the Applicant's Private Key has suffered a Key Compromise, such as through the provisions of Section 4.9.1.1; <br><br>The CA is aware of a demonstrated or proven method to easily compute the Applicant's Private Key based on the Public Key (such as a Debian weak key, see <a href="https://wiki.debian.org/SSLkeys" target="_blank">https://wiki.debian.org/SSLkeys</a>). <br><br>If the Subscriber Certificate will contain an extKeyUsage extension containing either the values id-kp-serverAuth [RFC5280] or anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA. <br><br><b>With: </b><br><br>The CA SHALL reject a certificate request if one or more of the following occurs: <br><br>1. The requested Public Key does not meet the requirements set forth in Sections 6.1.5 and/or 6.1.6; <br><br>2. The CA is aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise; <br><br>3. The CA has previously been made aware that the Subscriber's Private Key has suffered a Key Compromise, such as through the provisions of Section 4.9.1.1; <br><br>4. It has an industry demonstrated weak Private Key, in particular: <br><br>(i) In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at <a href="https://github.com/crocs-muni/roca" target="_blank">https://github.com/crocs-muni/roca</a> or equivalent. <br><br>(ii) In the case of Debian weak keys (<a href="https://wiki.debian.org/SSLkeys" target="_blank">https://wiki.debian.org/SSLkeys</a>), the CA SHALL reject at least keys generated by the flawed OpenSSL version with the following parameters: <br> a. Architectures supported by the flawed Debian distribution (alpha, arm, armel, hppa, i386, amd64, ia64, mips, mipsel, powerpc, s390, sparc); <br> b. Process ID of 0 to 32767, inclusive; <br> c. All RSA Public Key lengths supported by the CA up to and including 4096 bits; <br> d. rnd, nornd, and noreadrnd OpenSSL random file state; <br>For Debian weak keys not covered above, the CA SHALL take actions to minimize the probability of certificate issuance. <br><br>If the Subscriber Certificate will contain an extKeyUsage extension containing either the values id-kp-serverAuth [RFC5280] or anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key Pair on behalf of a Subscriber, and SHALL NOT accept a certificate request using a Key Pair previously generated by the CA. <br><br>=====<o:p></o:p></p><pre>-- <o:p></o:p></pre><pre>Chris Kemmerer<o:p></o:p></pre><pre>Manager of Operations<o:p></o:p></pre><pre>SSL.com<o:p></o:p></pre><pre> <o:p></o:p></pre><pre>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<o:p></o:p></pre><pre>~~~~~ To find the reefs, look~~~~~~~~<o:p></o:p></pre><pre>~~~~ for the wrecks. ~~~~~~~~~<o:p></o:p></pre><pre>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<o:p></o:p></pre></div></div></div><p class=MsoNormal>_______________________________________________<br>Servercert-wg mailing list<br><a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br><a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></p></blockquote></div></div></div></div></body></html>