<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Thanks, Karina and Ryan. If we understand correctly the questions
are:<br>
<br>
1) How does a CA gather useful information to observe 6.1.1.3?<br>
2) Can we clarify 6.1.1.3 item 3 regarding rejection of an request
using a compromised key?<br>
<br>
6.1.1.3, both currently and with the proposed changes, does the
following:<br>
<br>
1) offers <b>broad </b>guidance regarding a private key's
makeup, generation and liability to compromise (items 1 and 2 in
our proposed version of 6.1.1.3);<br>
2) instructs CAs on handling a <b>submitted, previously
compromised key</b> (item 3); and<br>
3) gives <b>specific </b>guidance for identified issues (item 4
as proposed for ROCA/Debian weak keys, and Martijn's suggested
addition for the Fermat attack).<br>
<br>
For the broader items, CAs are currently required to be aware of
and protect against issues related to improper key requirements
and demonstrated/proven methods of key compromise. This is
existing language which this proposal does not change, and, as
Ryan notes, CAs are expected to use community resources to track
developments and discussion.<br>
<br>
Our original intention with this ballot was to correct what we
believe was insufficient guidance specifically for Debian weak key
issues, and for these at least, the work of HARICA and Sectigo has
provided the community a useful tool - a consultable, finite data
set to check against. We do think it'd be useful to include one or
more locations for this resource in this ballot language, if these
can be agreed upon. (We've offered to host this data ourselves,
but welcome other options.)<br>
<br>
Beyond Debian weak keys, though, we're happy (for some values of
happy) to tackle other matters as well. We are open to language on
mitigation against the Fermat Attack issue, and will note again
that Let's Encrypt has updated Boulder to address this (<a class="moz-txt-link-freetext" href="https://github.com/letsencrypt/boulder/pull/5853">https://github.com/letsencrypt/boulder/pull/5853</a>).
Is Martijn's proposal sufficient?<br>
<br>
For Karina's point re: Subscriber Key Compromise, we agree that
the language could be clarified so that the particular
(compromised) key is the unit of rejection rather than the
Subscriber. Perhaps something like (addition in <b>bold</b>):<br>
<br>
"The CA has previously been made aware that the Subscriber's <b>submitted
</b>Private Key has suffered a Key Compromise, such as through the
provisions of Section 4.9.1.1;"<br>
<br>
<br>
<br>
</p>
<div class="moz-cite-prefix">On 5/2/2022 11:12 AM, Ryan Sleevi
wrote:<br>
</div>
<blockquote type="cite" cite="mid:CACvaWvb76vXDTnXxfO8DNG2Mop2LOAK43mLN0k8xO_4Bfkcn6w@mail.gmail.com">
<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" moz-do-not-send="true" class="moz-txt-link-freetext">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 style="overflow-wrap: break-word;" lang="EN-US">
<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 style="overflow-wrap: break-word;" lang="EN-US">
<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" moz-do-not-send="true">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 style="overflow-wrap: break-word;" lang="EN-US">
<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 style="overflow-wrap: break-word;" lang="EN-US">
<div class="gmail-m_4396735143588477670WordSection1">
<p class="MsoNormal"> </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.
</p>
<p class="MsoNormal"> </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.
</p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </span></p>
<div>
<table style="width:6.5in;border-collapse:collapse" width="624" cellspacing="0" cellpadding="0" border="0">
<tbody>
<tr>
<td colspan="2" style="width:351pt;padding:0in" width="468" valign="top">
<p class="MsoNormal" style="vertical-align:baseline"><span style="font-size:10pt;font-family:"Segoe
UI",sans-serif;color:rgb(80,80,80)">Best,
</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</span></p>
<p class="MsoNormal" style="vertical-align:baseline"><span style="font-size:10pt;font-family:"Segoe
UI",sans-serif;color:black"> </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)"></span></p>
</td>
</tr>
<tr style="height:50.25pt">
<td style="width:269.8pt;padding:0in;height:50.25pt" width="360" valign="top">
<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)"> </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)"> </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)"></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)"> </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)"> </span></p>
</div>
<p class="MsoNormal"><span style="color:rgb(31,73,125)"> </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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">martijn.katerbarg@sectigo.com</a>>;
CA/B Forum Server Certificate WG Public Discussion
List <<a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>><br>
<b>Subject:</b> Re: [Servercert-wg] [EXTERNAL]-Re:
SCXX Ballot proposal: Debian Weak keys</p>
</div>
</div>
<p class="MsoNormal"> </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" moz-do-not-send="true">
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" moz-do-not-send="true">
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" moz-do-not-send="true">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</p>
<div>
<p class="MsoNormal">On 4/5/2022 4:53 AM, Martijn
Katerbarg wrote:</p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal">Hi Chris,</p>
<p class="MsoNormal"> </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>
</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”</p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Martijn</p>
<p class="MsoNormal"> </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" moz-do-not-send="true">
<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" moz-do-not-send="true">
<servercert-wg@cabforum.org></a><br>
<b>Subject:</b> Re: [Servercert-wg]
[EXTERNAL]-Re: SCXX Ballot proposal: Debian Weak
keys</p>
</div>
</div>
<p class="MsoNormal"> </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></p>
</div>
<p class="MsoNormal"> </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.)</p>
<p>We've also updated the version in the proposal.</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" moz-do-not-send="true">
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" moz-do-not-send="true">
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" moz-do-not-send="true">
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" moz-do-not-send="true">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>
=====</p>
<div>
<p class="MsoNormal">On 10/28/2021 3:55 PM, Jaime
Hablutzel via Servercert-wg wrote:</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:</p>
</div>
<div>
<ol type="1" start="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.</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.</li>
</ol>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">On Thu, 28 Oct 2021
at 03:02 Rob Stradling <<a href="mailto:rob@sectigo.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">rob@sectigo.com</a>>
wrote:</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></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black">Thanks
Corey. That makes sense.</span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span></p>
<div class="MsoNormal" style="text-align:center" align="center"><span style="font-size:12pt;color:black">
<hr width="98%" size="1" 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></p>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span></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></p>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Yes,
that’s great to know; thanks
for pointing it out.</p>
</div>
<p class="MsoNormal"> </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></p>
</div>
<p class="MsoNormal"> </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.</p>
</div>
<p class="MsoNormal"> </p>
<div>
<p class="MsoNormal">Thanks,</p>
</div>
<div>
<p class="MsoNormal">Corey</p>
</div>
<p class="MsoNormal"> </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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">jhablutz@WISEKEY.COM</a>>; CA/B Forum
Server Certificate WG
Public Discussion List
<<a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>><br>
<b>Cc:</b> Corey Bonnell
<<a href="mailto:Corey.Bonnell@digicert.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">Corey.Bonnell@digicert.com</a>>;
Christopher Kemmerer
<<a href="mailto:chris@ssl.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">chris@ssl.com</a>><br>
<b>Subject:</b> Re:
[EXTERNAL]-Re:
[Servercert-wg] SCXX
Ballot proposal: Debian
Weak keys</p>
</div>
</div>
</div>
<p class="MsoNormal"> </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></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span></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></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span></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></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span></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></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span></p>
<div class="MsoNormal" style="text-align:center" align="center"><span style="font-size:12pt;color:black">
<hr width="98%" size="1" 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></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt;color:black"> </span></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?</p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt"> </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" moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>
wrote:</p>
</div>
</div>
<p class="MsoNormal"> </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></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">Hi Corey. Yeah, OK. You've persuaded me.</span></p>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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" moz-do-not-send="true"><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></p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
<div class="MsoNormal" style="text-align:center" align="center"><span style="font-size:12pt">
<hr style="width:729.1pt" width="972" size="1" 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>
</p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
</div>
</div>
<div>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hi
Rob,</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Comments
inline.</p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">> <span style="font-size:12pt">AFAICT, in the affected Debian OpenSSL versions:</span></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" moz-do-not-send="true"><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></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" moz-do-not-send="true"><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></p>
</div>
</div>
<p class="MsoNormal"> </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.</p>
</div>
</div>
<p class="MsoNormal"> </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></p>
</div>
</div>
<p class="MsoNormal"> </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.</p>
</div>
</div>
<p class="MsoNormal"> </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></p>
</div>
</div>
<p class="MsoNormal"> </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.</p>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<p class="MsoNormal">Thanks,</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Corey</p>
</div>
</div>
<p class="MsoNormal"> </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" moz-do-not-send="true">https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/crypto/rsa/rsa_gen.c#L78</a></p>
</div>
</div>
<p class="MsoNormal"> </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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">chris@ssl.com</a>>;
CA/B Forum
Server
Certificate WG
Public
Discussion
List <<a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>;
Corey Bonnell
<<a href="mailto:Corey.Bonnell@digicert.com" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">Corey.Bonnell@digicert.com</a>><br>
<b>Subject:</b> Re:
[Servercert-wg] SCXX Ballot proposal: Debian Weak keys</p>
</div>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">Hi Corey.</span></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">AFAICT, in the affected Debian OpenSSL versions:</span></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" moz-do-not-send="true"><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></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" moz-do-not-send="true"><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></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
</div>
<div class="MsoNormal" style="text-align:center" align="center">
<hr width="98%" size="1" 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" moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg-bounces@cabforum.org</a>>
on behalf of
Corey Bonnell
via
Servercert-wg
<<a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">chris@ssl.com</a>>;
CA/B Forum
Server
Certificate WG
Public
Discussion
List <<a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>><br>
<b>Subject:</b> Re:
[Servercert-wg] SCXX Ballot proposal: Debian Weak keys</p>
</div>
</div>
<div>
<p class="MsoNormal"> </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></p>
</div>
</div>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<div>
<p class="MsoNormal">Hi
Chris,</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.).</p>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal">Thanks,</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal">Corey</p>
</div>
</div>
<div>
<p class="MsoNormal"> </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" moz-do-not-send="true" class="moz-txt-link-freetext">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" moz-do-not-send="true" class="moz-txt-link-freetext">rob@sectigo.com</a>>;
Dimitris
Zacharopoulos
(HARICA) <<a href="mailto:dzacharo@harica.gr" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">dzacharo@harica.gr</a>>; CA/B Forum
Server
Certificate WG
Public
Discussion
List <<a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>;
Jacob
Hoffman-Andrews
<<a href="mailto:jsha@letsencrypt.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">jsha@letsencrypt.org</a>><br>
<b>Subject:</b> Re:
[Servercert-wg] SCXX Ballot proposal: Debian Weak keys</p>
</div>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> </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></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></p>
<div>
<div>
<div>
<p class="MsoNormal">On
10/14/2021
9:49 AM, Rob
Stradling
wrote:</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" moz-do-not-send="true"><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></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
</div>
</div>
<div class="MsoNormal" style="text-align:center" align="center">
<hr width="98%" size="1" 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" moz-do-not-send="true"><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" moz-do-not-send="true"><chris@ssl.com></a>;
Dimitris
Zacharopoulos
(HARICA) <a href="mailto:dzacharo@harica.gr" target="_blank" moz-do-not-send="true"><dzacharo@harica.gr></a>;
CA/B Forum
Server
Certificate WG
Public
Discussion
List <a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true"><servercert-wg@cabforum.org></a>;
Jacob
Hoffman-Andrews <a href="mailto:jsha@letsencrypt.org" target="_blank" moz-do-not-send="true"><jsha@letsencrypt.org></a>;
Rob Stradling<a href="mailto:rob@sectigo.com" target="_blank" moz-do-not-send="true"><rob@sectigo.com></a><br>
<b>Subject:</b> Re:
[Servercert-wg] SCXX Ballot proposal: Debian Weak keys</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </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" moz-do-not-send="true"><span style="font-size:12pt">https://github.com/CVE-2008-0166</span></a><span style="font-size:12pt"> repositories.</span></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
</div>
</div>
<div class="MsoNormal" style="text-align:center" align="center">
<hr width="98%" size="1" 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" moz-do-not-send="true"><servercert-wg-bounces@cabforum.org></a> on
behalf of Rob
Stradling via
Servercert-wg <a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true"><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" moz-do-not-send="true"><chris@ssl.com></a>;
Dimitris
Zacharopoulos
(HARICA) <a href="mailto:dzacharo@harica.gr" target="_blank" moz-do-not-send="true"><dzacharo@harica.gr></a>;
CA/B Forum
Server
Certificate WG
Public
Discussion
List <a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true"><servercert-wg@cabforum.org></a>;
Jacob
Hoffman-Andrews <a href="mailto:jsha@letsencrypt.org" target="_blank" moz-do-not-send="true"><jsha@letsencrypt.org></a><br>
<b>Subject:</b> Re:
[Servercert-wg] SCXX Ballot proposal: Debian Weak keys</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </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></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> </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></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt">> ...</span></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></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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" moz-do-not-send="true"><span style="font-size:12pt">https://github.com/CVE-2008-0166</span></a><span style="font-size:12pt"> repositories.</span></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
</div>
</div>
<div>
<div class="MsoNormal" style="text-align:center" align="center">
<hr width="98%" size="1" 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" moz-do-not-send="true"><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" moz-do-not-send="true"><rob@sectigo.com></a>;
Dimitris
Zacharopoulos
(HARICA) <a href="mailto:dzacharo@harica.gr" target="_blank" moz-do-not-send="true"><dzacharo@harica.gr></a>;
CA/B Forum
Server
Certificate WG
Public
Discussion
List <a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true"><servercert-wg@cabforum.org></a>;
Jacob
Hoffman-Andrews <a href="mailto:jsha@letsencrypt.org" target="_blank" moz-do-not-send="true"><jsha@letsencrypt.org></a><br>
<b>Subject:</b> Re:
[Servercert-wg] SCXX Ballot proposal: Debian Weak keys</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </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></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12pt;vertical-align:baseline">Hello,</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" moz-do-not-send="true">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).</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.</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" moz-do-not-send="true">https://github.com/crocs-muni/</a>roca
or
equivalent.")</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" moz-do-not-send="true">
4.9.1.1/6.1.1.3</a>.</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" moz-do-not-send="true">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.)</p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">Chris K </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" moz-do-not-send="true">SSL.com</a></p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">===== </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">--- Motion Begins --- </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </p>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </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: </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">Proposed ballot language: </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"><b>4.9.1.1 Reasons for Revoking a
Subscriber
Certificate</b> </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">Replace: </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </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" moz-do-not-send="true">https://wiki.debian.org/SSLkeys</a>) </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">With: </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </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)). </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">--- </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"><b>6.1.1.3. Subscriber Key Pair
Generation</b> </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">Replace: </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </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: </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </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; </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; </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; </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; </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" moz-do-not-send="true">https://wiki.debian.org/SSLkeys</a>). </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">With: </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </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: </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </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; </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; </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; </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: </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" moz-do-not-send="true">https://github.com/crocs-muni/roca</a> or
equivalent. </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" moz-do-not-send="true">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: </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </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; </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">ii) Process ID of 0 to 32767,
inclusive; </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; </p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">iv) rnd, nornd, and noreadrnd OpenSSL
random file
state. </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </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. </p>
</div>
</div>
</div>
<div>
<p class="MsoNormal" style="vertical-align:baseline"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal" style="vertical-align:baseline">--- Motion Ends ---</p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On
1/18/2021 3:34
PM, Rob
Stradling
wrote:</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></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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" moz-do-not-send="true"><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" moz-do-not-send="true"><span style="font-size:12pt">https://github.com/CVE-2008-0166/openssl_blocklists</span></a><span style="font-size:12pt">.</span></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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" moz-do-not-send="true"><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" moz-do-not-send="true"><span style="font-size:12pt">https://github.com/CVE-2008-0166/private_keys</span></a><span style="font-size:12pt">.</span></p>
</div>
</div>
</div>
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
</div>
</div>
<div class="MsoNormal" style="text-align:center" align="center">
<hr width="98%" size="1" 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" moz-do-not-send="true"><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" moz-do-not-send="true"><rob@sectigo.com></a>; CA/B
Forum Server
Certificate WG
Public
Discussion
List <a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true"><servercert-wg@cabforum.org></a>;
Jacob
Hoffman-Andrews <a href="mailto:jsha@letsencrypt.org" target="_blank" moz-do-not-send="true"><jsha@letsencrypt.org></a>;
Christopher
Kemmerer <a href="mailto:chris@ssl.com" target="_blank" moz-do-not-send="true"><chris@ssl.com></a><br>
<b>Subject:</b> Re:
[Servercert-wg] SCXX Ballot proposal: Debian Weak keys</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </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></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div>
<div>
<p class="MsoNormal">On
14/1/2021
12:30 π.μ.,
Rob Stradling
wrote:</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></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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" moz-do-not-send="true"><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" moz-do-not-send="true"><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" moz-do-not-send="true"><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></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></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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></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.</p>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
</div>
</div>
<div class="MsoNormal" style="text-align:center" align="center">
<hr width="98%" size="1" 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" moz-do-not-send="true"><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" moz-do-not-send="true"><rob@sectigo.com></a>; CA/B
Forum Server
Certificate WG
Public
Discussion
List <a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true"><servercert-wg@cabforum.org></a>;
Jacob
Hoffman-Andrews <a href="mailto:jsha@letsencrypt.org" target="_blank" moz-do-not-send="true"><jsha@letsencrypt.org></a>;
Christopher
Kemmerer <a href="mailto:chris@ssl.com" target="_blank" moz-do-not-send="true"><chris@ssl.com></a><br>
<b>Subject:</b> Re:
[Servercert-wg] SCXX Ballot proposal: Debian Weak keys</p>
</div>
</div>
<div>
<div>
<p class="MsoNormal"> </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></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> </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:</p>
</div>
</div>
<ol style="margin-top:0in" type="1" start="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" moz-do-not-send="true">https://github.com/HARICA-official/debian-weak-keys</a></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.</p>
<div>
<div>
<div>
<p class="MsoNormal">On
7/1/2021 2:25
μ.μ., Rob
Stradling via
Servercert-wg
wrote:</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></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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" moz-do-not-send="true"><span style="font-size:12pt">https://gist.github.com/robstradling/a5590b6a13218fe561dcb5d5c67932c5</span></a></p>
</div>
</div>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></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" moz-do-not-send="true"><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" moz-do-not-send="true"><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></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12pt"> </span></p>
</div>
<div class="MsoNormal" style="text-align:center" align="center">
<hr width="98%" size="1" 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" moz-do-not-send="true"><servercert-wg-bounces@cabforum.org></a> on
behalf of Rob
Stradling via
Servercert-wg <a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true"><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" moz-do-not-send="true"><jsha@letsencrypt.org></a>;
Christopher
Kemmerer <a href="mailto:chris@ssl.com" target="_blank" moz-do-not-send="true"><chris@ssl.com></a>; CA/B
Forum Server
Certificate WG
Public
Discussion
List <a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true"><servercert-wg@cabforum.org></a><br>
<b>Subject:</b> Re:
[Servercert-wg] SCXX Ballot proposal: Debian Weak keys</p>
</div>
</div>
<div>
<p class="MsoNormal"> </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></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>
</p>
<pre>_______________________________________________</pre>
<pre>Servercert-wg mailing list</pre>
<pre><a href="mailto:Servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">Servercert-wg@cabforum.org</a></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" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a></pre>
</blockquote>
</div>
</blockquote>
</div>
</div>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>