<div dir="ltr"><div dir="ltr">Hi all,<div><br></div><div>Following on to what Corey said: using the explicit list of 12 platforms, many of which are virtually inaccessible today and do not have pre-existing lists of weak keys generated, seems like a suboptimal way to specify this behavior.</div><div><br></div><div>According to contemporaneous research (<a href="https://www.cs.umd.edu/class/fall2017/cmsc818O/papers/private-keys-public.pdf">https://www.cs.umd.edu/class/fall2017/cmsc818O/papers/private-keys-public.pdf</a>, PDF link) the set of weak keys generated by a given platform is completely determined by</div><div>a) endianness (big or little),</div><div>b) word size (32 or 64 bits), and</div><div>c) the other factors included in the draft above (key size, process id, and behavior regarding the ~/.rnd file)</div><div>In addition, at the time there were no supported 64-bit big-endian architectures, so only three out of the four possible combinations of factors (a) and (b) are relevant.<br></div><div><br></div><div>I see that a previous draft of this proposal was phrased in exactly this way:</div><div>> ...Big-endian 32-bit, little-endian 32-bit, and little-endian 64-bit </div>architecture;...<div>But I do not see any discussion on that previous thread that would have led to this change. I have seen a few messages which assert that it is necessary to enumerate all platforms, rather than enumerating word size and endianness, but have seen none which provide an explanation for why that is necessary. What motivated this change?</div><div><br></div><div>Thanks,</div><div>Aaron</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Sep 4, 2020 at 11:30 AM Corey Bonnell via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">servercert-wg@cabforum.org</a>> wrote:<br></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_5630151461635187084WordSection1"><p class="MsoNormal">Hi Chris,<u></u><u></u></p><p class="MsoNormal">I am curious why the clause on exponents as seen on the previous version of the draft (<a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-May/001954.html" target="_blank">https://archive.cabforum.org/pipermail/servercert-wg/2020-May/001954.html</a>) was removed, as I believe it is a useful clarification alongside the modulus lengths.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Additionally, for the list of architectures, my understanding is that different architectures may yield a separate set of keys (<a href="https://archive.cabforum.org/pipermail/servercert-wg/2020-April/001846.html" target="_blank">https://archive.cabforum.org/pipermail/servercert-wg/2020-April/001846.html</a>) due to different word widths/widths of the pid_t type and endianness. Several of the architectures listed are moribund, which makes this an increasingly challenging requirement for CAs as hardware becomes increasingly rare. Given this, it may be desirable to target a few of the architectures in common use at the time of the vulnerability and restrict to those.<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><p class="MsoNormal">Thanks,<u></u><u></u></p><p class="MsoNormal">Corey<u></u><u></u></p><p class="MsoNormal"><u></u> <u></u></p><div style="border-top:none;border-right:none;border-bottom:none;border-left:1.5pt solid blue;padding:0in 0in 0in 4pt"><div><div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in"><p class="MsoNormal"><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<u></u><u></u></p></div></div><p class="MsoNormal"><u></u> <u></u></p><p style="margin-bottom:12pt">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://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxZwSuiVmgg&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fpull%2f208" 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><a href="http://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxclAunBhgA&s=5&u=http%3a%2f%2fSSL%2ecom" target="_blank">SSL.com</a><br><br>=====<br><br>Proposed ballot language:<u></u><u></u></p><p>4.9.1.1 Reasons for Revoking a Subscriber Certificate <u></u><u></u></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://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxcwTuiRi0A&s=5&u=https%3a%2f%2fwiki%2edebian%2eorg%2fSSLkeys" 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://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxZkSvSE73w&s=5&u=https%3a%2f%2fgithub%2ecom%2fcrocs-muni%2froca" target="_blank">https://github.com/crocs-muni/roca</a> or equivalent. <br><br>(ii) In the case of Debian weak keys (<a href="https://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxcwTuiRi0A&s=5&u=https%3a%2f%2fwiki%2edebian%2eorg%2fSSLkeys" 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>=====<u></u><u></u></p><pre>-- <u></u><u></u></pre><pre>Chris Kemmerer<u></u><u></u></pre><pre>Manager of Operations<u></u><u></u></pre><pre><a href="http://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxclAunBhgA&s=5&u=http%3a%2f%2fSSL%2ecom" target="_blank">SSL.com</a><u></u><u></u></pre><pre><u></u> <u></u></pre><pre>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<u></u><u></u></pre><pre>~~~~~ To find the reefs, look~~~~~~~~<u></u><u></u></pre><pre>~~~~     for the wrecks.    ~~~~~~~~~<u></u><u></u></pre><pre>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~<u></u><u></u></pre></div></div></div>_______________________________________________<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" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div></div>