<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, May 2, 2022 at 11:25 AM Karina Sirota 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" style="overflow-wrap: break-word;">
<div class="gmail-m_4396735143588477670WordSection1">
<p class="MsoNormal"><span style="color:rgb(31,73,125)">There are some primary concerns about this-  mainly, how would a CA be aware of gathering the information mentioned in most of the methods below? </span></p></div></div></blockquote><div><br></div><div>At a minimum, problem reports that credibly demonstrate this information. Equally, a broadcast to the CA/Browser Forum Members list (e.g. for security relevant disclosures) could also be argued as the CA being made aware.</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" style="overflow-wrap: break-word;"><div class="gmail-m_4396735143588477670WordSection1"><p class="MsoNormal"><span style="color:rgb(31,73,125)">Can we get more specific about the methods that expose private
 keys or how a CA should gather this information: “</span>b) In the case of Debian weak keys (<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ATNh%2BnLhaXmkh8bFEh6LVti4l5wVi%2FGnnvy2fm32bio%3D&reserved=0" target="_blank">https://wiki.debian.org/SSLkeys</a>),
 the CA SHALL reject at least keys generated by the flawed OpenSSL version with the combination of the following parameters: i) Big-endian 32-bit, little-endian 32-bit, and little-endian 64-bit architecture; ii) Process ID of 0 to 32767, inclusive; iii) All
 RSA Public Key lengths supported by the CA up to and including 4096 bits; iv) rnd, nornd, and noreadrnd OpenSSL random file state“ </p></div></div></blockquote><div><br></div><div>This can be empirically tested/compared (as the discussion on the list).</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" style="overflow-wrap: break-word;"><div class="gmail-m_4396735143588477670WordSection1"><p class="MsoNormal">and "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;"</p></div></div></blockquote><div><br></div><div>I'm not sure I follow? This would be the CA consulting their own list of compromised keys (e.g. as they're required to retain records for)</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" style="overflow-wrap: break-word;"><div class="gmail-m_4396735143588477670WordSection1"><p class="MsoNormal"><u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">There are concerns that CAs wouldn’t be able to get the visibility into the subscriber’s key generation process to verify this.
<u></u><u></u></p>
<p class="MsoNormal"><u></u> <u></u></p>
<p class="MsoNormal">For "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;", can we also clean up the language to be clear that the CA cannot issue only
 for the compromised key? The way this is phrased sounds like it could also mean that a CA should not issue ANYTHING to a subscriber who previously have a key compromise, which I don’t believe is the goal here.
<u></u><u></u></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<div>
<table border="0" cellspacing="0" cellpadding="0" width="624" style="width:6.5in;border-collapse:collapse">
<tbody>
<tr>
<td width="468" colspan="2" valign="top" style="width:351pt;padding:0in">
<p class="MsoNormal" style="vertical-align:baseline"><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:rgb(80,80,80)">Best,
<u></u><u></u></span></p>
<p class="MsoNormal" style="vertical-align:baseline"><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:rgb(80,80,80)">Karina<u></u><u></u></span></p>
<p class="MsoNormal" style="vertical-align:baseline"><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:black"><u></u> <u></u></span></p>
<p class="MsoNormal" style="vertical-align:baseline"><b><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:black">Ka</span></b><span style="font-size:10pt;font-family:"Segoe UI",sans-serif;color:black">rina
<b>Sirota</b> | Security Program Manager 2</span><span style="color:rgb(80,80,80)"><u></u><u></u></span></p>
</td>
</tr>
<tr style="height:50.25pt">
<td width="360" valign="top" style="width:269.8pt;padding:0in;height:50.25pt">
<p class="MsoNormal" style="vertical-align:baseline"><span style="font-size:9pt;font-family:"Segoe UI",sans-serif;color:rgb(89,89,89)">Trusted Root Program, Trust Governance and Resilience</span><span style="font-size:9pt;font-family:"Segoe UI",sans-serif;color:rgb(31,73,125)"> <u></u><u></u></span></p>
<p class="MsoNormal" style="vertical-align:baseline"><span style="font-size:8pt;font-family:"Segoe UI",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
<p class="MsoNormal"><i><span style="font-size:9pt;color:rgb(31,73,125)">After-hours responses neither required nor expected.
</span></i><span style="color:rgb(31,73,125)"><u></u><u></u></span></p>
<p class="MsoNormal" style="vertical-align:baseline"><span style="font-size:9pt;font-family:"Segoe UI",sans-serif;color:rgb(31,73,125)"><u></u> <u></u></span></p>
</td>
<td style="border:none;padding:0in" width="144">
<p class="MsoNormal"> </p>
</td>
</tr>
</tbody>
</table>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
</div>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"><u></u> <u></u></span></p>
<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>Chris Kemmerer via Servercert-wg<br>
<b>Sent:</b> Friday, April 15, 2022 5:07 PM<br>
<b>To:</b> Martijn Katerbarg <<a href="mailto:martijn.katerbarg@sectigo.com" target="_blank">martijn.katerbarg@sectigo.com</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br>
<b>Subject:</b> Re: [Servercert-wg] [EXTERNAL]-Re: SCXX Ballot proposal: Debian Weak keys<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><u></u> <u></u></p>
<p>Thanks for your suggestion, Martijn. We ourselves wouldn't object to this addition, though we'd certainly like to poll the community on their thoughts.<br>
<br>
We see that the vulnerability you address has been assigned <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fnvd.nist.gov%2Fvuln%2Fdetail%2FCVE-2022-26320&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=prmP%2BEnjpTv5UE9elnyOWm9zGi0jQFZ4Pl%2BQhX9%2Fbig%3D&reserved=0" target="_blank">
https://nvd.nist.gov/vuln/detail/CVE-2022-26320</a>, with <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ffermatattack.secvuln.info%2F&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XWYdDEfOGcQ5ahAGCyRl7o%2BoJnUjmYsULjoefO%2Fex%2B8%3D&reserved=0" target="_blank">
https://fermatattack.secvuln.info/</a> looking like the main resource for this issue. We also note (per that latter site) that Let's Encrypt has updated Boulder to check for this vulnerability (<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fletsencrypt%2Fboulder%2Fpull%2F5853&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sNfdCK05Ti1ahvBy9DSAVROj%2BJKux7GUFB0NS0BC4sg%3D&reserved=0" target="_blank">https://github.com/letsencrypt/boulder/pull/5853</a>).<br>
<br>
The Debian weak key and ROCA vulnerabilities have been known lo these many years (although not all CAs had sufficient safeguards in place, and the sections of the BRs provided less than comprehensive guidance on what those safeguards should be - hence this
 ballot  initiative).<br>
<br>
Since CVE-2022-26320 was only published March 14 2022, one alternative would be would be to defer a decision on the Fermat attack language to another, later ballot, but we again invite community input on incorporating this suggestion into our current proposed
 ballot.<br>
<br>
One practical question (not addressed in our current language) would be the deadline for CAs to add the checks required in this ballot, with our thought being to place it in the nearer term (some few months after ballot passage/review) but not immediately upon
 adoption of the ballot. This particularly is of interest for any changes/checks required for CVE-2022-26320, but in our view any deadline should be considered to apply to all vulnerabilities addressed in this ballot.<br>
<br>
Thanks,<br>
<br>
Chris K<u></u><u></u></p>
<div>
<p class="MsoNormal">On 4/5/2022 4:53 AM, Martijn Katerbarg wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal">Hi Chris,<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">I would like to propose an additional check to the proposed language so it includes checking for the Close Primes vulnerability. For this I’d like to propose we add to 6.1.1.3 (4):<br>
<br>
<br>
<u></u><u></u></p>
<p class="MsoNormal">“c) In the case of Close Primes vulnerability, the CA SHALL reject weak keys identified within 100 rounds using Fermat’s factorization method”<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<p class="MsoNormal">Martijn<u></u><u></u></p>
<p class="MsoNormal"> <u></u><u></u></p>
<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>Chris Kemmerer via Servercert-wg<br>
<b>Sent:</b> Thursday, 31 March 2022 16:43<br>
<b>To:</b> Jaime Hablutzel via Servercert-wg <a href="mailto:servercert-wg@cabforum.org" target="_blank">
<servercert-wg@cabforum.org></a><br>
<b>Subject:</b> Re: [Servercert-wg] [EXTERNAL]-Re: SCXX Ballot proposal: Debian Weak keys<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div style="border:1pt solid black;padding:2pt">
<p class="MsoNormal" style="line-height:12pt;background:rgb(250,250,3)"><span style="font-size:10pt;color:black">CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the
 content is safe.</span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">We are pleased to return to discussion of this proposed ballot, which we've reprinted immediately below.<br>
<br>
Based on the discussion thus far, we've addressed Corey's point by adding the <b>
bolded </b>line re: which modulus/exponents a CA MUST check. (We generally agree with Jaime's suggestion that CAs
<i>should </i>check the modulus only but don't see it as crucial to explicitly state this in the ballot.)<u></u><u></u></p>
<p>We've also updated the version in the proposal.<u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:12pt">If this ballot proceeds the next available designation would be SC55.<br>
<br>
Many thanks,<br>
<br>
Chris K<br>
<br>
<br>
===== <br>
<br>
--- Motion Begins --- <br>
<br>
 <br>
This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based on Version 1.8.2:
<br>
<br>
 <br>
Proposed ballot language: <br>
<br>
 <br>
<i>4.9.1.1 Reasons for Revoking a Subscriber Certificate </i><br>
<br>
 <br>
Replace: <br>
<br>
 <br>
4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see
<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ATNh%2BnLhaXmkh8bFEh6LVti4l5wVi%2FGnnvy2fm32bio%3D&reserved=0" target="_blank">
https://wiki.debian.org/SSLkeys</a>) <br>
<br>
 <br>
With: <br>
<br>
 <br>
4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key (such as those identified in 6.1.1.3(4)).
<br>
<br>
--- <br>
<br>
<i>6.1.1.3. Subscriber Key Pair Generation </i><br>
<br>
 <br>
Replace: <br>
<br>
 <br>
The CA SHALL reject a certificate request if one or more of the following conditions are met:
<br>
<br>
1. The Key Pair does not meet the requirements set forth in Section 6.1.5 and/or Section 6.1.6;
<br>
2. There is clear evidence that the specific method used to generate the Private Key was flawed;
<br>
3. The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise;
<br>
4. 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>
5. 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ATNh%2BnLhaXmkh8bFEh6LVti4l5wVi%2FGnnvy2fm32bio%3D&reserved=0" target="_blank">
https://wiki.debian.org/SSLkeys</a>). <br>
<br>
 <br>
With: <br>
<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>
2) The CA is aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise;
<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>
4) The Public Key corresponds to an industry demonstrated weak Private Key, in particular:
<br>
a) In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at
<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcrocs-muni%2Froca&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=7UfsVU%2BiqjZOWsJ8n2JokRUxQTeiPgzOFX%2FjdMpuuXo%3D&reserved=0" target="_blank">
https://github.com/crocs-muni/roca</a> or equivalent. <br>
b) In the case of Debian weak keys (<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ATNh%2BnLhaXmkh8bFEh6LVti4l5wVi%2FGnnvy2fm32bio%3D&reserved=0" target="_blank">https://wiki.debian.org/SSLkeys</a>),
 the CA SHALL reject at least keys generated by the flawed OpenSSL version with the combination of the following parameters:
<br>
<br>
i) Big-endian 32-bit, little-endian 32-bit, and little-endian 64-bit architecture;
<br>
ii) Process ID of 0 to 32767, inclusive; <br>
iii) All RSA Public Key lengths supported by the CA up to and including 4096 bits;
<br>
iv) rnd, nornd, and noreadrnd OpenSSL random file state. <br>
<br>
For Debian weak keys not covered above, the CA SHALL take actions to minimize the probability of certificate issuance.
<br>
<br>
<b>CAs MUST check for Debian weak keys for all RSA modulus lengths and exponents that they accept.</b>
<br>
 <br>
--- Motion Ends ---<br>
<br>
=====<u></u><u></u></p>
<div>
<p class="MsoNormal">On 10/28/2021 3:55 PM, Jaime Hablutzel via Servercert-wg wrote:<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<p class="MsoNormal">It could be helpful to be a little bit more explicit on the fact that the required check is against the modulus only as it could avoid d<span style="border:1pt none windowtext;padding:0in">evelopers to implement this check against full
 public keys, which </span>can lead to:<u></u><u></u></p>
</div>
<div>
<ol start="1" type="1">
<li class="MsoNormal">
Some CAs could unknowingly embark themselves in the onerous task of generating the affected key pairs for each different public exponent, which is not really required.<u></u><u></u></li><li class="MsoNormal">
Because of the higher amount of work required for supporting/maintaining the check in this way, some CAs might mistakenly omit checking some subscriber keys, e.g. they might have in their blocklists only the affected public keys with the public exponent set
 to 65537, even when they (unintentionally) support subscriber keys with other values for the public exponent.<u></u><u></u></li></ol>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">On Thu, 28 Oct 2021 at 03:02 Rob Stradling <<a href="mailto:rob@sectigo.com" target="_blank">rob@sectigo.com</a>> wrote:<u></u><u></u></p>
</div>
<blockquote style="border-top:none;border-right:none;border-bottom:none;border-left:1pt solid rgb(204,204,204);padding:0in 0in 0in 6pt;margin:5pt 0in 5pt 4.8pt">
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">> I think we can merely state that CAs must check for Debian weak keys for all RSA modulus lengths and exponents that they accept. Using a comparison of the modulus (or its hash) is essentially
 an implementation detail that we don’t need to explicitly mandate.</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">Thanks Corey.  That makes sense.</span><u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span><u></u><u></u></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:12pt;color:black">
<hr size="1" width="98%" align="center">
</span></div>
<p class="MsoNormal"><b><span style="font-size:12pt;color:black">From:</span></b><span style="font-size:12pt;color:black"> Corey Bonnell<br>
<b>Sent:</b> Wednesday, October 27, 2021 18:43<br>
<b>To:</b> Rob Stradling; Jaime Hablutzel; CA/B Forum Server Certificate WG Public Discussion List<br>
<b>Cc:</b> Christopher Kemmerer<br>
<b>Subject:</b> RE: [EXTERNAL]-Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
</span><u></u><u></u></p>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">> <span style="font-size:12pt;color:black">Hi Jaime.  Ooh, you're right!  The affected OpenSSL versions generate the same predictable moduli regardless of the public exponent value.</span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">Yes, that’s great to know; thanks for pointing it out.<u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">> <span style="font-size:12pt;color:black">What's the best way to capture all this in the ballot?</span><u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">I think we can merely state that CAs must check for Debian weak keys for all RSA modulus lengths and exponents that they accept. Using a comparison of the modulus (or its hash) is essentially an implementation detail that we don’t need
 to explicitly mandate.<u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal">Corey<u></u><u></u></p>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<div>
<p class="MsoNormal"><b>From:</b> Rob Stradling <<a href="mailto:rob@sectigo.com" target="_blank">rob@sectigo.com</a>>
<br>
<b>Sent:</b> Wednesday, October 27, 2021 5:31 AM<br>
<b>To:</b> Jaime Hablutzel <<a href="mailto:jhablutz@WISEKEY.COM" target="_blank">jhablutz@WISEKEY.COM</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br>
<b>Cc:</b> Corey Bonnell <<a href="mailto:Corey.Bonnell@digicert.com" target="_blank">Corey.Bonnell@digicert.com</a>>; Christopher Kemmerer <<a href="mailto:chris@ssl.com" target="_blank">chris@ssl.com</a>><br>
<b>Subject:</b> Re: [EXTERNAL]-Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys<u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">Hi Jaime.  Ooh, you're right!  The affected OpenSSL versions generate the same predictable moduli regardless of the public exponent value.</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">So yes, the optimal approach seems to be for CAs to use Debian weak key blocklists that are based on only the RSA modulus.</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">Corey's point applies if a CA chooses instead to implement a Debian weak key blocklist of (for example) SubjectPublicKeyInfos with public exponent 65537.</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span><u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">What's the best way to capture all this in the ballot?</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span><u></u><u></u></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:12pt;color:black">
<hr size="1" width="98%" align="center">
</span></div>
<div>
<p class="MsoNormal"><b><span style="font-size:12pt;color:black">From:</span></b><span style="font-size:12pt;color:black"> Jaime Hablutzel<br>
<b>Sent:</b> Sunday, October 24, 2021 23:25<br>
<b>To:</b> Rob Stradling; CA/B Forum Server Certificate WG Public Discussion List<br>
<b>Cc:</b> Corey Bonnell; Christopher Kemmerer<br>
<b>Subject:</b> Re: [EXTERNAL]-Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys
</span><u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hi, I might be (very) wrong here, but, shouldn’t blocklists be based only on the RSA modulus for different key sizes so validation implementations match the module only irrespective of whatever the public exponent is? or does the affected
 prime generation random source seed from the public exponent too?<u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"> <u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<p class="MsoNormal">On 22 Oct 2021, at 08:58, Rob Stradling via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">> ...my opinion is that we should introduce a new requirement such that CAs must check for Debian weak keys for all RSA modulus lengths and exponents that they accept. CAs are uniquely positioned to prevent
 the usage of these weak keys in the web PKI, so there is a security benefit in mandating such universal checks.</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">Hi Corey.  Yeah, OK.  You've persuaded me.</span><u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">FWIW, my tools at </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_CVE-2D2008-2D0166%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DgZAtYdIgwjZ_F9FpjPlUFmh9SQve9WXOyzZCTDLhsH4%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=11SI7Pny1qyNvMx34GeEnrGJ5U8t6xo%2BdS6dcIyGREM%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://github.com/CVE-2008-0166</span></a><span style="font-size:12pt"> only
 support 65537 at the moment.  I guess I'll just have to wait and see if anyone asks for other public exponent values to be supported.  </span><span style="font-size:12pt;font-family:"Segoe UI Emoji",sans-serif">🙂</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
<div class="MsoNormal" align="center" style="text-align:center"><span style="font-size:12pt">
<hr size="1" width="972" style="width:729.1pt" align="center">
</span></div>
<div>
<p class="MsoNormal"><b><span style="font-size:12pt">From:</span></b><span style="font-size:12pt"> Corey Bonnell<br>
<b>Sent:</b> Tuesday, October 19, 2021 19:48<br>
<b>To:</b> Rob Stradling; Christopher Kemmerer; CA/B Forum Server Certificate WG Public Discussion List<br>
<b>Subject:</b> RE: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys </span>
<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hi Rob,<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Comments inline.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">> <span style="font-size:12pt">AFAICT, in the affected Debian OpenSSL versions:</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">  - "openssl req -newkey" had a hardcoded public exponent of 65537 (see </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_openssl_openssl_blob_OpenSSL-5F0-5F9-5F8f_apps_req.c-23L768%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DVu5UXlPv7euZNJXCO15ReMLK_k5MyC3YaUliVn6DQcU%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ZjC2zw7GWCs4fcgMZjfl6A7oa7Ws5FgVsgPt9TOIku0%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/apps/req.c#L768</span></a><span style="font-size:12pt">).</span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">  - "openssl genrsa" defaulted to 65537, but provided a "-3" command-line option to use a public exponent of 3 instead (see </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_openssl_openssl_blob_OpenSSL-5F0-5F9-5F8f_apps_genrsa.c%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DMXbwubefERoNQfWd4kC0f7rxRrBl5yB1YZ2Y3OmPQoo%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2BVkZ9MX9YerJS91NzUJl0kIMPEGBbiJ%2FHhHwTRw0Oa4%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/apps/genrsa.c</span></a><span style="font-size:12pt">).</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">As you point out, the command-line tooling bundled with OpenSSL 0,9.8 generally restricted the allowed exponent. However, the RSA key generation API allowed any exponent to be specified [1], so it is possible that a custom application passed
 exponent values besides 3 or 65537 to the RSA key generation function.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">> <span style="font-size:12pt">Are there any good reasons to continue to permit the public exponent 3 ?</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">Judging from Censys, it appears that there are some publicly trusted certificates containing RSA keys with an exponent of 3, so there will presumably be a (minor) ecosystem impact if an exponent value of 3 were banned. That being said,
 exponents smaller than 65537 are outside the SHOULD-level exponent range since BR v1.1.3 (now in section 6.1.6) so perhaps it’s time to consider strengthening the SHOULD to a MUST. Probably such a change would be outside the scope of this ballot, though.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">> <span style="font-size:12pt">The "openssl-vulnkey" tool that Debian used to ship only provided blocklists for keys with public exponents of 65537, so should we take that as a sign that CAs needn't perform a Debian weak key check when
 the public exponent is anything other than 65537 ?</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">While the precedent set by accepted remediations for incidents surrounding Debian weak keys has been for CAs to check the lists distributed in the openssl-blacklist Debian package, my opinion is that we should introduce a new requirement
 such that CAs must check for Debian weak keys for all RSA modulus lengths and exponents that they accept. CAs are uniquely positioned to prevent the usage of these weak keys in the web PKI, so there is a security benefit in mandating such universal checks.<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Corey<u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<p class="MsoNormal">[1] <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_openssl_openssl_blob_OpenSSL-5F0-5F9-5F8f_crypto_rsa_rsa-5Fgen.c-23L78%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DBZt9wGuErHLlj4PgA-Q_BWX-TmBE7NrL_QZcjyFCmLs%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642543179%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Oth7ho%2BL68o2w6vXRUdwVrgwbOM29wfmFDqGC7iSmXY%3D&reserved=0" target="_blank">https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/crypto/rsa/rsa_gen.c#L78</a><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<div>
<div>
<p class="MsoNormal"><b>From:</b> Rob Stradling <<a href="mailto:rob@sectigo.com" target="_blank">rob@sectigo.com</a>> <br>
<b>Sent:</b> Tuesday, October 19, 2021 11:31 AM<br>
<b>To:</b> Christopher Kemmerer <<a href="mailto:chris@ssl.com" target="_blank">chris@ssl.com</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>>; Corey Bonnell
 <<a href="mailto:Corey.Bonnell@digicert.com" target="_blank">Corey.Bonnell@digicert.com</a>><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys<u></u><u></u></p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">Hi Corey.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">AFAICT, in the affected Debian OpenSSL versions:</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">  - "openssl req -newkey" had a hardcoded public exponent of 65537 (see </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_openssl_openssl_blob_OpenSSL-5F0-5F9-5F8f_apps_req.c-23L768%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DVu5UXlPv7euZNJXCO15ReMLK_k5MyC3YaUliVn6DQcU%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=T%2FLmr%2FIypBm5ip5cewpVKYgyu3erniREIZEkchQTYjo%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/apps/req.c#L768</span></a><span style="font-size:12pt">).</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">  - "openssl genrsa" defaulted to 65537, but provided a "-3" command-line option to use a public exponent of 3 instead (see </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__github.com_openssl_openssl_blob_OpenSSL-5F0-5F9-5F8f_apps_genrsa.c%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DMXbwubefERoNQfWd4kC0f7rxRrBl5yB1YZ2Y3OmPQoo%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=UuS2bPXQQ5zH5eQtdoP7HMVEcpSVDP7Rjt%2FNItIdygs%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/apps/genrsa.c</span></a><span style="font-size:12pt">).</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">Are there any good reasons to continue to permit the public exponent 3 ?</span><u></u><u></u></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">The "openssl-vulnkey" tool that Debian used to ship only provided blocklists for keys with public exponents of 65537, so should we take that as a sign that CAs needn't perform a Debian weak key check when
 the public exponent is anything other than 65537 ?</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="1" width="98%" align="center">
</div>
<div id="gmail-m_4396735143588477670m_-5641879633787292213m_-1239830060004810024x_x_x_divRplyFwdMsg">
<div>
<div>
<p class="MsoNormal"><b>From:</b> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank">servercert-wg-bounces@cabforum.org</a>> on behalf of Corey Bonnell via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br>
<b>Sent:</b> 19 October 2021 15:31<br>
<b>To:</b> Christopher Kemmerer <<a href="mailto:chris@ssl.com" target="_blank">chris@ssl.com</a>>; CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<div style="border:1pt solid black;padding:2pt">
<div>
<div>
<p class="MsoNormal" style="line-height:12pt;background:rgb(250,250,3)"><span style="font-size:10pt;color:black">CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the
 content is safe.</span><u></u><u></u></p>
</div>
</div>
</div>
<p class="MsoNormal"> <u></u><u></u></p>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hi Chris,<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Apologies for the late reply. I noticed that the current proposed language has no guidance regarding RSA exponents. I think it would be useful to specify the expectations in this regard (whether the CA must check for weak keys for all key
 lengths and exponent combinations accepted/supported by the CA, or if checking weak key lists for only exponents 3 and 65537 is sufficient, etc.).<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal">Thanks,<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Corey<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div style="border-right:none;border-bottom:none;border-left:none;border-top:1pt solid rgb(225,225,225);padding:3pt 0in 0in">
<div>
<div>
<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> Friday, October 15, 2021 10:33 AM<br>
<b>To:</b> Rob Stradling <<a href="mailto:rob@sectigo.com" target="_blank">rob@sectigo.com</a>>; Dimitris Zacharopoulos (HARICA) <<a href="mailto:dzacharo@harica.gr" target="_blank">dzacharo@harica.gr</a>>; CA/B Forum Server Certificate WG Public Discussion
 List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>>; Jacob Hoffman-Andrews <<a href="mailto:jsha@letsencrypt.org" target="_blank">jsha@letsencrypt.org</a>><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys<u></u><u></u></p>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:9pt;font-family:Helvetica,sans-serif">Thank you, Rob, and shall watch for that update. Meanwhile we are doing a final-final pass through our draft language for clarity and will send
 it early next week.</span><u></u><u></u></p>
<p class="MsoNormal" style="margin-bottom:12pt"><span style="font-size:9pt;font-family:Helvetica,sans-serif">Chris K<br>
<br>
Meanwhile, we've cycled our draft language through  another review and have made IIRC only one or two minor edits for clarity (h/t BenW).</span><u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On 10/14/2021 9:49 AM, Rob Stradling wrote:<u></u><u></u></p>
</div>
</div>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">Today I rediscovered that I'd previously generated the RSA-8192 blocklists back in December 2009, and that they're still available at </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fsecure.sectigo.com-252Fdebian-5Fweak-5Fkeys-252F-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987811664-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DBknvgeWEnZ4pvV0PZHrsqaYgYgzgs4wad1Y3lmy1FWk-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DzzVoaIwOBGmJbK59JUU8ZW6-rpOfDM9LW4-DOaggMQQ%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=BGMgoeDsxZxjLThXAhw1r9WObqfYZZ8S%2FVVVSyZYUak%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://secure.sectigo.com/debian_weak_keys/</span></a><span style="font-size:12pt">. 
 When I compared the old and new RSA-8192 blocklists, I found that ~0.8% of the "rnd" keys are different.  It looks like, for reasons unknown, the "OpenSSL random file state" misbehaved occasionally over the 8 month run that ended recently.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">I'll report back once I've regenerated and verified the problematic keys.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="1" width="98%" align="center">
</div>
<div id="gmail-m_4396735143588477670m_-5641879633787292213m_-1239830060004810024x_x_x_x_divRplyFwdMsg">
<div>
<div>
<p class="MsoNormal"><b>From:</b> Rob Stradling <a href="mailto:rob@sectigo.com" target="_blank"><rob@sectigo.com></a><br>
<b>Sent:</b> 23 September 2021 19:17<br>
<b>To:</b> Christopher Kemmerer <a href="mailto:chris@ssl.com" target="_blank"><chris@ssl.com></a>; Dimitris Zacharopoulos (HARICA) <a href="mailto:dzacharo@harica.gr" target="_blank"><dzacharo@harica.gr></a>; CA/B Forum Server Certificate WG Public Discussion
 List <a href="mailto:servercert-wg@cabforum.org" target="_blank"><servercert-wg@cabforum.org></a>; Jacob Hoffman-Andrews <a href="mailto:jsha@letsencrypt.org" target="_blank"><jsha@letsencrypt.org></a>; Rob Stradling<a href="mailto:rob@sectigo.com" target="_blank"><rob@sectigo.com></a><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">> BTW, in case it helps, I'm about half way through generating a full set of RSA-8192 Debian weak keys, which (when complete) I'll add to the </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987811664-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DhEYtpXP81bOYFl0bdDSzbg8zxn7gozJ2bXAzE3ZPLwQ-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DCZuzMqYs2tJKnr9PUCkV8xEr-EQLZuEnpygT0nUUNYQ%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=f4ALHzn5E6dxITiOFVpfX4c%2BUAIfgvp669PPLb6BcLk%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://github.com/CVE-2008-0166</span></a><span style="font-size:12pt"> repositories.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">It took nearly 8 months (using just a single core of a fairly modest CPU), but it finally finished!  Repositories updated.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="1" width="98%" align="center">
</div>
<div id="gmail-m_4396735143588477670m_-5641879633787292213m_-1239830060004810024x_x_x_x_x_divRplyFwdMsg">
<div>
<div>
<p class="MsoNormal"><b>From:</b> Servercert-wg <a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank"><servercert-wg-bounces@cabforum.org></a> on behalf of Rob Stradling via Servercert-wg <a href="mailto:servercert-wg@cabforum.org" target="_blank"><servercert-wg@cabforum.org></a><br>
<b>Sent:</b> 13 May 2021 15:42<br>
<b>To:</b> Christopher Kemmerer <a href="mailto:chris@ssl.com" target="_blank"><chris@ssl.com></a>; Dimitris Zacharopoulos (HARICA) <a href="mailto:dzacharo@harica.gr" target="_blank"><dzacharo@harica.gr></a>; CA/B Forum Server Certificate WG Public Discussion
 List <a href="mailto:servercert-wg@cabforum.org" target="_blank"><servercert-wg@cabforum.org></a>; Jacob Hoffman-Andrews <a href="mailto:jsha@letsencrypt.org" target="_blank"><jsha@letsencrypt.org></a><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div style="border:1pt solid black;padding:2pt">
<div>
<div>
<p class="MsoNormal" style="line-height:12pt"><span style="font-size:10pt;color:black">CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">> iii) All RSA Public Key lengths supported by the CA up to and including 4096 bits;</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">> ...</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">> For Debian weak keys not covered above, the CA SHALL take actions to minimize the probability of certificate issuance.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">Hi Christopher.  What sort of "actions" are envisaged here?  If a CA is processing a certificate request that contains a (for example) RSA-4088 public key (i.e., a key size not covered by an available Debian
 weak list), either the CA is going to issue the cert or they're not.  What, concretely, does "minimize the probability of certificate issuance" actually mean?</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">Why not remove that "SHALL" sentence and change point iii to: "<span style="color:black;background:white">iii) All RSA Public Key lengths supported by the CA." ?</span></span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">BTW, in case it helps, I'm about half way through generating a full set of RSA-8192 Debian weak keys, which (when complete) I'll add to the </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987821618-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3D34YXT3egxh7Xtc5k5gqy8idcbz9cgokAIz7o8Xwbh94-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DtaqinDAOLRdSvETy9ob78hR_-KPxttqWcUNY_M86mTY%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=km7JdYBArwmQ%2FyoEXSjTlTIkrg9qQ17jeGPvmUWimEk%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://github.com/CVE-2008-0166</span></a><span style="font-size:12pt"> repositories.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="1" width="98%" align="center">
</div>
<div id="gmail-m_4396735143588477670m_-5641879633787292213m_-1239830060004810024x_x_x_x_x_x_divRplyFwdMsg">
<div>
<div>
<p class="MsoNormal"><b>From:</b> Christopher Kemmerer <a href="mailto:chris@ssl.com" target="_blank"><chris@ssl.com></a><br>
<b>Sent:</b> 13 May 2021 15:12<br>
<b>To:</b> Rob Stradling <a href="mailto:rob@sectigo.com" target="_blank"><rob@sectigo.com></a>; Dimitris Zacharopoulos (HARICA) <a href="mailto:dzacharo@harica.gr" target="_blank"><dzacharo@harica.gr></a>; CA/B Forum Server Certificate WG Public Discussion
 List <a href="mailto:servercert-wg@cabforum.org" target="_blank"><servercert-wg@cabforum.org></a>; Jacob Hoffman-Andrews <a href="mailto:jsha@letsencrypt.org" target="_blank"><jsha@letsencrypt.org></a><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div style="border:1pt solid black;padding:2pt">
<div>
<div>
<p class="MsoNormal" style="line-height:12pt"><span style="font-size:10pt;color:black">CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt;vertical-align:baseline">Hello,<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt;vertical-align:baseline">We deeply appreciate the useful discussion in this thread regarding this issue. We especially applaud the efforts of HARICA and Sectigo to independently generate more comprehensive lists
 of potentially affected Debian weak keys. As Rob Stradling observed through his crt.sh research (20210107, <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgist.github.com-252Frobstradling-252Fa5590b6a13218fe561dcb5d5c67932c5-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987821618-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DQXz4cOmARv-252Fg8-252FJF2NNEW2-252BSbjHJu1pv8X6vjLCx7io-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DEARvfcpJ6O_cJ0KioLW9U0gNj00u2-_njjGSKcTRtE8%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2Fw0jtGtNYpy%2Fk%2Ffbu0qq4W75umKZL%2FgihNlJhAaHdhw%3D&reserved=0" target="_blank">https://gist.github.com/robstradling/a5590b6a13218fe561dcb5d5c67932c5</a>)
 of the five most utilized algorithm/key size populations, two are ECC (so not impacted by the Debian weak key issue) and three are RSA (2048, 4096, and 3072 bit length, in that order).<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt;vertical-align:baseline">As of their most recent messages it appears that these two organizations have independently generated comprehensive lists identifying all RSA-2048 and -4096 bit length keys. (We understand
 RSA-3072 length keys are also available.) This offers the possibility that complete lists, if accepted as authoritative, could be accessed by the community to help prevent exploitation of this vulnerability.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt;vertical-align:baseline">It was also noted (by the representative from Let's Encrypt) that the ROCA vulnerability is presently identified through use of a tool supported externally. It was suggested that this
 resource be archived in a manner that ensures availability. (Our proposed language points to "<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fcrocs-2Dmuni-252F-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987831575-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DZQMlATqs-252BM7Vr3aIgjdrH06gaOrkgAPTbMkM4gcSROs-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DgoTnhfES-zV16ifNjJ90Y_GUk39wftGwqMJiZKuw5aY%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=dTFDusV%2FMHpFPIr1eWZ8mREATuC5MnZn%2FJ%2BauJtx21c%3D&reserved=0" target="_blank">https://github.com/crocs-muni/</a>roca
 or equivalent.")<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt;vertical-align:baseline">We think our present ballot language (reproduced at the end of this message) provides appropriately focused guidance to CAs. If available, we'd certainly like to also see the HARICA/Sectigo
 lists (which CAs could use for the majority of Debian weak key use cases) captured somewhere in this ballot language. We are agnostic as to 1) where exactly these resources might be maintained and 2) where this ballot places directions to these resources -
 an annex to the current requirements, a separate CA/BF guidance document or within Sections
<a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F4.9.1.1%2F6.1.1.3&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=iT2v17IxPRIKft8oE0gZppeY2GN4QR0sDhkA7ydZGNc%3D&reserved=0" target="_blank">
4.9.1.1/6.1.1.3</a>.<u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt;vertical-align:baseline">Our intent is to ensure that 1) clear, accurate guidance on CA expectations is provided and 2) any resources assisting CAs in meeting these expectations are fully described, publicly
 available (somewhere) and with reliable links provided. The language below, we feel, meets the first requirement. We'd appreciate input on how to best meet the second. (Note that <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__ssl.com_%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3Dj-4qIhXvNMe9dfS8B8CWq0sSP-IOQRNSRmpjiPXIFZw%26m%3DJnxStoHpP62BM2-15Vtby3qBQbCdQrSyCNPjVNH_IS8%26s%3DSGnteTNpPS1X4ickvt5qbC2WDrpValWXK42R9uvwO04%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Md402CkKLuMhPQ2vODsG3LBIbFXj2oMfpwswhqW5s7A%3D&reserved=0" target="_blank">SSL.com</a> would
 be happy to support the community by hosting any of these as publicly accessible resources, whether solo or alongside other organizations.)<u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">Chris K <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt;vertical-align:baseline"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttp-3A__ssl.com_%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3Dj-4qIhXvNMe9dfS8B8CWq0sSP-IOQRNSRmpjiPXIFZw%26m%3DJnxStoHpP62BM2-15Vtby3qBQbCdQrSyCNPjVNH_IS8%26s%3DSGnteTNpPS1X4ickvt5qbC2WDrpValWXK42R9uvwO04%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Md402CkKLuMhPQ2vODsG3LBIbFXj2oMfpwswhqW5s7A%3D&reserved=0" target="_blank">SSL.com</a><u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">===== <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">--- Motion Begins --- <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based on Version 1.7.4: <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">Proposed ballot language: <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"><b>4.9.1.1 Reasons for Revoking a Subscriber Certificate</b> <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">Replace: <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwiki.debian.org-252FSSLkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987831575-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DpXeTXYoS8oYMQteThIRSdhISQokGG4nL-252BHSymGxAwPg-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DZtytHt-KbbrRxo2oN_oCa2ihhQEPcupL52pOSa3xs9U%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642593164%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=ez10XaxDaL25e6wSHf48ERSqnbxnd2X4%2FozFwrWaDNA%3D&reserved=0" target="_blank">https://wiki.debian.org/SSLkeys</a>) <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">With: <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key (such as those identified in 6.1.1.3(4)). <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">--- <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"><b>6.1.1.3. Subscriber Key Pair Generation</b> <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">Replace: <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">The CA SHALL reject a certificate request if one or more of the following conditions are met: <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">1. The Key Pair does not meet the requirements set forth in Section 6.1.5 and/or Section 6.1.6; <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">2. There is clear evidence that the specific method used to generate the Private Key was flawed; <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">3. The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise; <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">4. 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; <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">5. 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://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwiki.debian.org-252FSSLkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987831575-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DpXeTXYoS8oYMQteThIRSdhISQokGG4nL-252BHSymGxAwPg-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DZtytHt-KbbrRxo2oN_oCa2ihhQEPcupL52pOSa3xs9U%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2ByMNXcOE%2FqkZuKvqzEjK18noUoVafR55WJRIDFTieEM%3D&reserved=0" target="_blank">https://wiki.debian.org/SSLkeys</a>). <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">With: <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">The CA SHALL reject a certificate request if one or more of the following occurs: <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">1) The requested Public Key does not meet the requirements set forth in Sections 6.1.5 and/or 6.1.6; <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">2) The CA is aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise; <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">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; <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">4) The Public Key corresponds to an industry demonstrated weak Private Key, in particular: <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">a) In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252Fcrocs-2Dmuni-252Froca-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987841531-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DpVWa4-252Fu9mO6gfEAN2FHOMx83i-252FGSUcG-252BfzyDoHm1xKs-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3D6j9rei_kmtaqpNr-93i7Jp1C7q5YNaJtJJ2z3Rn5FzE%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Kpr7zVhhPGCAnGS5lP8HBIQsjTCoIrNohPqdsU1PJlE%3D&reserved=0" target="_blank">https://github.com/crocs-muni/roca</a> or
 equivalent. <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">b) In the case of Debian weak keys (<a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwiki.debian.org-252FSSLkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987841531-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DfJSWwzvoeepBzwSexsg-252FFSKZKusdynxlt-252F1gItUiii0-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3D7VJmjfUviaQVQ3rIxm7xE-dFcYL1TLUk2yNWY4hFx0U%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2ZaTPeUPtigylDIuwYq0zUYAEC4JyGL4hrminV3rQ%2BI%3D&reserved=0" target="_blank">https://wiki.debian.org/SSLkeys</a>),
 the CA SHALL reject at least keys generated by the flawed OpenSSL version with the combination of the following parameters: <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">i) Big-endian 32-bit, little-endian 32-bit, and little-endian 64-bit architecture; <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">ii) Process ID of 0 to 32767, inclusive; <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">iii) All RSA Public Key lengths supported by the CA up to and including 4096 bits; <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">iv) rnd, nornd, and noreadrnd OpenSSL random file state. <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">For Debian weak keys not covered above, the CA SHALL take actions to minimize the probability of certificate issuance. <u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">--- Motion Ends ---<u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On 1/18/2021 3:34 PM, Rob Stradling wrote:<u></u><u></u></p>
</div>
</div>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">> I'm mid-way through generating the RSA-4096 keys.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">The RSA-4096 private keys and blocklists are now in </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-252Fprivate-5Fkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987851488-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3Dt2XnHbMAXRIJHGzz-252BLi4gptSfi957l-252Fkz5fcaUc4PxA-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DiSbz-XCr-uFk_7Y8gJ0DA2ii9QYdRcBI5WcrvGeE55Q%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qhpx0PdMEhqyXSAWlZ6L3TYZNeHK7Q8N2%2BbRCIo%2B14o%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://github.com/CVE-2008-0166/private_keys</span></a><span style="font-size:12pt"> and</span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-252Fopenssl-5Fblocklists-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987851488-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3D-252B-252Fmznq3F0GbWZjrE1G08DqSXBOxYTLtIF1l7pLatjoU-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG%25207RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3D-tHYY-qeEG6kULte0FSWXNcttvh6n3BUnjh8PTDXi-c%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=72z%2B4M4Kl%2BWZ%2B%2FuZXJFSC262CzC9BJf7NKHKd37n%2FUA%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://github.com/CVE-2008-0166/openssl_blocklists</span></a><span style="font-size:12pt">.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">The RSA-2048 and RSA-4096 private keys in </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FHARICA-2Dofficial-252Fdebian-2Dweak-2Dkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987861437-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DFb5kG1Ob413KX19BP-252B37xpIahSiKi2FIZ5NfuZ-252FkuPU-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3D_lfhBqavAtNpmBCedDWRhR5JY_praNbAngJx0m7i14E%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=%2FV%2FOPEwTmARBYx8286yAEtZ0kNXq%2Bqw8vo66EkVNqXo%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://github.com/HARICA-official/debian-weak-keys</span></a><span style="font-size:12pt"> (which
 only covers 2 of the 3 word size / endianness combinations) are identical to the equivalents in </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-252Fprivate-5Fkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987861437-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DoDDkulWGG70BklQLLMR0GsX-252FRIy20y-252FKtw9gGijGyhE-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DyAkqXLZo2IvXlCZvKvbFvweWp1zicZGNjpQ-S6gHQbY%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wzRI2fBqwnYt%2FItJ3qX1EnqMruvoyr1Fb1IflYPURsQ%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://github.com/CVE-2008-0166/private_keys</span></a><span style="font-size:12pt">.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="1" width="98%" align="center">
</div>
<div id="gmail-m_4396735143588477670m_-5641879633787292213m_-1239830060004810024x_x_x_x_x_x_x_divRplyFwdMsg">
<div>
<div>
<p class="MsoNormal"><b>From:</b> Dimitris Zacharopoulos (HARICA) <a href="mailto:dzacharo@harica.gr" target="_blank"><dzacharo@harica.gr></a><br>
<b>Sent:</b> 14 January 2021 18:39<br>
<b>To:</b> Rob Stradling <a href="mailto:rob@sectigo.com" target="_blank"><rob@sectigo.com></a>; CA/B Forum Server Certificate WG Public Discussion List <a href="mailto:servercert-wg@cabforum.org" target="_blank"><servercert-wg@cabforum.org></a>; Jacob Hoffman-Andrews <a href="mailto:jsha@letsencrypt.org" target="_blank"><jsha@letsencrypt.org></a>;
 Christopher Kemmerer <a href="mailto:chris@ssl.com" target="_blank"><chris@ssl.com></a><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div style="border:1pt solid black;padding:2pt">
<div>
<div>
<p class="MsoNormal" style="line-height:12pt"><span style="font-size:10pt;color:black">CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On 14/1/2021 12:30 π.μ., Rob Stradling wrote:<u></u><u></u></p>
</div>
</div>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">Thanks Dmitris.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">So far I've generated the RSA-2048 and RSA-3072 keys using </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-252Fkey-5Fgenerator-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987871399-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3D4kKGwenlWGRmGjkIWofWWWnykgyNAgmJj1knMJ9PFz4-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DNAsWm8iu6UPJcqogRr7ZHylAINg9o87jFWyCbM_GxlE%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=qjyWlVO1o%2FrROa3gXqui5d8a9kqQRk22tTx84ZY07%2FM%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://github.com/CVE-2008-0166/key_generator</span></a><span style="font-size:12pt"> and
 uploaded them to </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-252Fprivate-5Fkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987871399-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DDS2Fb707J-252BWD3UlBsOMtUWBl-252B5JkoU3S9twMJn8eSps-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DwLahGmkoShePVAd3354Vg-KIUIG_bUnevY1465It5Jk%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=e3lcjB%2F9ZttUW%2FYPEBXLkBWgFf6RLkePGpRIcTNitFk%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://github.com/CVE-2008-0166/private_keys</span></a><span style="font-size:12pt">,
 and I've generated the corresponding blocklists and uploaded them to </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FCVE-2D2008-2D0166-252Fopenssl-5Fblocklists-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987871399-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DJtYLdAD8pwpvivoIfMXAeEjofoK0FqoijWEb4Sc9OV4-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DNrxlbUT4xWxoifiZhepNwMg-9wFwdQwvVmKKxNVBuk8%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=NjtpOmBLveMOTMJiM%2B5tC7elvIFzqDIKW%2FPKl6Si7mY%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://github.com/CVE-2008-0166/openssl_blocklists</span></a><span style="font-size:12pt">. 
 My RSA-2048 blocklists exactly match the ones from the original Debian openssl-blacklist package.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">I'm mid-way through generating the RSA-4096 keys.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">Let's compare keys when we're both done.  </span><span style="font-size:12pt;font-family:"Segoe UI Emoji",sans-serif">🙂</span><u></u><u></u></p>
</div>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"><br>
Certainly :-) the RSA-2048 keys already match the fingerprints from the openssl-blacklist Debian package.<br>
<br>
We did this work several months ago but never found the time to make it publicly available. We managed to break down the big task and run jobs in parallel which made things a bit more interesting.<br>
<br>
It's nice we did this independently, I guess it increases the accuracy level of the resulted keys :)<br>
<br>
<br>
Cheers,<br>
Dimitris.<u></u><u></u></p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="1" width="98%" align="center">
</div>
<div id="gmail-m_4396735143588477670m_-5641879633787292213m_-1239830060004810024x_x_x_x_x_x_x_x_divRplyFwdMsg">
<div>
<div>
<p class="MsoNormal"><b>From:</b> Dimitris Zacharopoulos (HARICA) <a href="mailto:dzacharo@harica.gr" target="_blank"><dzacharo@harica.gr></a><br>
<b>Sent:</b> 13 January 2021 21:49<br>
<b>To:</b> Rob Stradling <a href="mailto:rob@sectigo.com" target="_blank"><rob@sectigo.com></a>; CA/B Forum Server Certificate WG Public Discussion List <a href="mailto:servercert-wg@cabforum.org" target="_blank"><servercert-wg@cabforum.org></a>; Jacob Hoffman-Andrews <a href="mailto:jsha@letsencrypt.org" target="_blank"><jsha@letsencrypt.org></a>;
 Christopher Kemmerer <a href="mailto:chris@ssl.com" target="_blank"><chris@ssl.com></a><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys<u></u><u></u></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
</div>
<div>
<div style="border:1pt solid black;padding:2pt">
<div>
<div>
<p class="MsoNormal" style="line-height:12pt"><span style="font-size:10pt;color:black">CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">Dear friends,<br>
<br>
HARICA has generated the weak keys (RSA 2048 and 4096 bit lengths) from the vulnerable openssl package. We will generate 3072 bit keys as well and add them soon. The methodology is described in the following GitHub repo along with the produced keys:<u></u><u></u></p>
</div>
</div>
<ol style="margin-top:0in" start="1" type="1">
<li class="MsoNormal"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgithub.com-252FHARICA-2Dofficial-252Fdebian-2Dweak-2Dkeys-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987881346-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3D61WsoKxsDa5-252FjBab75Y-252FZG4PbcoE3RVkCWg-252BsfY2Aww-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DdWL9G_dD07M3-kQ4faHXjdMzoGF9wF5hEGlN2IrPwiA%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642643154%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=wTp7hC4TVyAVCSTNxMHyLDqN%2BKvJkFQCmg%2B6ZTasB3w%3D&reserved=0" target="_blank">https://github.com/HARICA-official/debian-weak-keys</a><u></u><u></u></li></ol>
<p class="MsoNormal" style="margin-bottom:12pt">Please review and let us know if you spot any issues or problems with our approach and methodology.<br>
<br>
As always, please use other people's work at your own risk.<br>
<br>
<br>
Dimitris.<u></u><u></u></p>
<div>
<div>
<div>
<p class="MsoNormal">On 7/1/2021 2:25 μ.μ., Rob Stradling via Servercert-wg wrote:<u></u><u></u></p>
</div>
</div>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">I've used crt.sh to produce a survey of key algorithms/sizes in currently unexpired, publicly-trusted server certificates:</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fgist.github.com-252Frobstradling-252Fa5590b6a13218fe561dcb5d5c67932c5-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987881346-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3D4qveGxYahVQ6FbihVosw69bsGUs7hG1ytgI6YLxqYbY-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3D0JiuTeERFFPZRGiB5foBRJZ5kJjHk51DCLjQbBVwSxc%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642693143%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zqTIP%2FEEaaEkPpEkebTry5iotrCbskoX36sI2WAkrZY%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://gist.github.com/robstradling/a5590b6a13218fe561dcb5d5c67932c5</span></a><u></u><u></u></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">The four most popular choices are no surprise: RSA-2048, P-256, RSA-4096, and P-384.  openssl-blacklist covers RSA-2048 and RSA-4096, and ECC keys are implicitly not Debian weak keys.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">Fifth most popular is RSA-3072, with over 3 million unexpired, publicly-trusted server certs.  openssl-blacklist doesn't cover RSA-3072, but ISTM that this is a key size that CAs will want to permit.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">Some of the lesser used key sizes are mostly likely due to Subscriber typos (e.g., 2408 and 3048 were probably intended to be 2048, 4048 was probably intended to be either 2048 or 4096, etc), but some of the
 other ones look like they were deliberately chosen (e.g., 2432 is 2048+384).  Is it worth generating Debian weak keys/blocklists for any of these key sizes?</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fnvlpubs.nist.gov-252Fnistpubs-252FSpecialPublications-252FNIST.SP.800-2D57pt1r5.pdf-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987891313-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DrG1bgcAgL7P3RtCaCJ0cZTcYPkcUhTlsR4J6ulGFgso-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3DzehaaELHzHzxLDM3dCTeAYaSLMufH4svdbHT74RDcq0%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642693143%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=0o0Plw5xgK%2BX79E9qnhIhRzI4N1Nieg1wzC1ogUS6as%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf</span></a><span style="font-size:12pt"> (Table
 4, p59) permits RSA-2048 until the end of 2030, whereas </span><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__nam04.safelinks.protection.outlook.com_-3Furl-3Dhttps-253A-252F-252Fwww.sogis.eu-252Fdocuments-252Fcc-252Fcrypto-252FSOGIS-2DAgreed-2DCryptographic-2DMechanisms-2D1.2.pdf-26data-3D04-257C01-257Crob-2540sectigo.com-257Ca8c9d97cd4114ebf508708d9930d343d-257C0e9c48946caa465d96604b6968b49fb7-257C0-257C0-257C637702508987891313-257CUnknown-257CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0-253D-257C2000-26sdata-3DgCbutfTj362g-252BHqbrbYgcpm5etqbhCvUFpp8E2UYinE-253D-26reserved-3D0%26d%3DDwMGaQ%26c%3DeuGZstcaTDllvimEN8b7jXrwqOf-v5A_CdpgnVfiiMM%26r%3D-bX5hBm1IdRDykQ-dBR8tsFRCM4v1VXUyG7RZa2WqPY%26m%3DfMDCutmeJbXlHHWIZLMy2UAZB79bm_AVGAAADmUsNAE%26s%3D2FZ19CpL6_a-dWd0zh1d-4HiMpn4pWyZ0lsH3f1k140%26e%3D&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642693143%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=019WU3DYLHSYoFyljNzRrTE97m41TL%2B%2BP8e7ePlsxJA%3D&reserved=0" target="_blank"><span style="font-size:12pt">https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.2.pd
 f</span></a><span style="font-size:12pt"> permits RSA-2048 only until the end of 2025.  It is of course possible that quantum computing will render RSA obsolete before Subscribers need to think about which larger RSA keysize they want to migrate to; however,
 it seems prudent to also plan for the possibility that RSA will survive and that some other RSA keysize(s) might become popular.</span><u></u><u></u></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span><u></u><u></u></p>
</div>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="1" width="98%" align="center">
</div>
<div id="gmail-m_4396735143588477670m_-5641879633787292213m_-1239830060004810024x_x_x_x_x_x_x_x_x_divRplyFwdMsg">
<div>
<div>
<p class="MsoNormal"><b>From:</b> Servercert-wg <a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank"><servercert-wg-bounces@cabforum.org></a> on behalf of Rob Stradling via Servercert-wg <a href="mailto:servercert-wg@cabforum.org" target="_blank"><servercert-wg@cabforum.org></a><br>
<b>Sent:</b> 06 January 2021 16:08<br>
<b>To:</b> Jacob Hoffman-Andrews <a href="mailto:jsha@letsencrypt.org" target="_blank"><jsha@letsencrypt.org></a>; Christopher Kemmerer <a href="mailto:chris@ssl.com" target="_blank"><chris@ssl.com></a>; CA/B Forum Server Certificate WG Public Discussion List <a href="mailto:servercert-wg@cabforum.org" target="_blank"><servercert-wg@cabforum.org></a><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot proposal: Debian Weak keys<u></u><u></u></p>
</div>
</div>
<div>
<p class="MsoNormal"> <u></u><u></u></p>
</div>
</div>
<div>
<div style="border:1pt solid black;padding:2pt">
<div>
<div>
<p class="MsoNormal" style="line-height:12pt"><span style="font-size:10pt;color:black">CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.</span><u></u><u></u></p>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>
</div>
</div>
<p class="MsoNormal"><br>
<br>
<br>
<u></u><u></u></p>
<pre>_______________________________________________<u></u><u></u></pre>
<pre>Servercert-wg mailing list<u></u><u></u></pre>
<pre><a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><u></u><u></u></pre>
<pre><a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=05%7C01%7Ckarina.sirota%40microsoft.com%7C94d75ad129bc49ce855a08da1f2c38b0%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637856574642693143%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=D82FfVq0lK9ogBytNGrkTC6y6RsOYiQXJ09%2FZB92chU%3D&reserved=0" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><u></u><u></u></pre>
</blockquote>
</div>
</blockquote>
</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>