<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
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:<br>
<ul>
<li><a class="moz-txt-link-freetext" href="https://github.com/HARICA-official/debian-weak-keys">https://github.com/HARICA-official/debian-weak-keys</a></li>
</ul>
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.<br>
<br>
<div class="moz-cite-prefix">On 7/1/2021 2:25 μ.μ., Rob Stradling
via Servercert-wg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:01000176dccee116-e709ef0f-19a7-415d-a34f-a709e245ef6c-000000@email.amazonses.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
I've used crt.sh to produce a survey of key algorithms/sizes in
currently unexpired, publicly-trusted server certificates:</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0);">
<a
href="https://gist.github.com/robstradling/a5590b6a13218fe561dcb5d5c67932c5"
moz-do-not-send="true">https://gist.github.com/robstradling/a5590b6a13218fe561dcb5d5c67932c5</a><br>
</div>
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
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.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial,
Helvetica, sans-serif; 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><br>
</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial,
Helvetica, sans-serif; font-size: 12pt;"><br>
</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
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?</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial,
Helvetica, sans-serif; font-size: 12pt;"><br>
</span></div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<span style="color: rgb(0, 0, 0); font-family: Calibri, Arial,
Helvetica, sans-serif; font-size: 12pt;"><a
href="https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf"
moz-do-not-send="true">https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r5.pdf</a> (Table
4, p59) permits RSA-2048 until the end of 2030, whereas </span><a
href="https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.2.pdf"
style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt;" moz-do-not-send="true">https://www.sogis.eu/documents/cc/crypto/SOGIS-Agreed-Cryptographic-Mechanisms-1.2.pdf</a> 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.</div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b>
Servercert-wg <a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg-bounces@cabforum.org"><servercert-wg-bounces@cabforum.org></a> on
behalf of Rob Stradling via Servercert-wg
<a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a><br>
<b>Sent:</b> 06 January 2021 16:08<br>
<b>To:</b> Jacob Hoffman-Andrews
<a class="moz-txt-link-rfc2396E" href="mailto:jsha@letsencrypt.org"><jsha@letsencrypt.org></a>; Christopher Kemmerer
<a class="moz-txt-link-rfc2396E" href="mailto:chris@ssl.com"><chris@ssl.com></a>; CA/B Forum Server Certificate WG
Public Discussion List <a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot proposal:
Debian Weak keys</font>
<div> </div>
</div>
<div dir="ltr">
<div style="background-color:#FAFA03; width:100%;
border-style:solid; border-color:#000000; border-width:1pt;
padding:2pt; font-size:10pt; line-height:12pt;
font-family:'Calibri'; color:Black; text-align:left">
<span style="color:000000">CAUTION:</span> 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.</div>
<br>
<div>
<div style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<div style="margin:0px; font-size:12pt">Jacob wrote:</div>
<div style="margin:0px; font-size:12pt">> Lastly, I
think we should archive openssl-blacklist, and include
in the BRs: "A CA may reject the full set of Debian weak
keys by rejecting this superset of the Debian weak keys:</div>
<div style="margin:0px; font-size:12pt">><br>
<div>> - All RSA public keys with modulus lengths
other than 2048 or 4096, and</div>
<div>> - All RSA public keys with exponents other
than 65537, and</div>
<div><br>
</div>
<div>Hi Jacob. 65537 (aka 0x10001) is hard-coded
here...</div>
<div><span style="background-color:rgb(255,255,255);
display:inline!important"><br>
</span></div>
<div><span style="background-color:rgb(255,255,255);
display:inline!important"><a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fopenssl%2Fopenssl%2Fblob%2FOpenSSL_0_9_8f%2Fapps%2Freq.c%23L768&data=04%7C01%7Crob%40sectigo.com%7Ce7e29d7140f44c1dcefe08d8b25d3ee2%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637455460852660060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=kpH2T4RuI15kO1GW3yEE8zNioCc5Vk11ohsQOzvDOVs%3D&reserved=0"
originalsrc="https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/apps/req.c#L768"
shash="aKlZ95XwlKBhP3Suuy8MhC6JDFfYL8rMAvRQQzIekuwuL+7d44b+KxYuUKZV70fFNv95+JifffS82YEPBz06fdgPKkb+yr17qIGhvxjeCs+kygczdoRdFEnRsUw/CmoF3KtO7155MlKQN54wpChxAAWYnSL9A1QlAsHxa/1PSOA="
moz-do-not-send="true">https://github.com/openssl/openssl/blob/OpenSSL_0_9_8f/apps/req.c#L768</a><br>
</span></div>
<div><br>
</div>
<div>Would it therefore be fair to say that keys with
public exponents other than 65537 are implicitly
<u>not</u> Debian weak keys?</div>
<div><br>
</div>
> - All RSA public keys that are detected as
vulnerable by the openssl-vulnkey program in the
openssl-blacklist package version 0.5-3 (see addendum),
or an equivalent program."</div>
</div>
<div>
<div
style="font-family:Calibri,Arial,Helvetica,sans-serif;
font-size:12pt; color:rgb(0,0,0)">
<br>
</div>
<hr tabindex="-1" style="display:inline-block; width:98%">
<div id="x_divRplyFwdMsg" dir="ltr"><font
style="font-size:11pt" face="Calibri, sans-serif"
color="#000000"><b>From:</b> Servercert-wg
<a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg-bounces@cabforum.org"><servercert-wg-bounces@cabforum.org></a> on behalf
of Jacob Hoffman-Andrews via Servercert-wg
<a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a><br>
<b>Sent:</b> 12 December 2020 02:21<br>
<b>To:</b> Christopher Kemmerer <a class="moz-txt-link-rfc2396E" href="mailto:chris@ssl.com"><chris@ssl.com></a>;
CA/B Forum Server Certificate WG Public Discussion
List <a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot
proposal: Debian Weak keys</font>
<div> </div>
</div>
<div>
<div style="background-color:#FAFA03; width:100%;
border-style:solid; border-color:#000000;
border-width:1pt; padding:2pt; font-size:10pt;
line-height:12pt; font-family:'Calibri'; color:Black;
text-align:left">
<span style="color:000000">CAUTION:</span> 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.</div>
<br>
<div>
<div dir="ltr">Thanks for your continued efforts to
improve this part of the BRs! Let's Encrypt is in
theory interested in endorsing, but I think it still
needs a bit of work. Thanks for incorporating my
most recent comments on endianness and word size vs
11 platforms.<br>
<br>
Goals: We want CAs to consistently not issue
certificates for weak keys in general, and also in
the specific case of Debian and ROCA keys. We want
the definition of Debian and ROCA keys to be clear
and actionable for as long as possible - say, at
least twenty years.<br>
<br>
We have three ways to specify Debian and ROCA keys:
With a list, with a tool, or with an algorithm*. The
original revision of this ballot proposed to use a
list (<a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fservercert-wg%2F2020-April%2F001821.html&data=04%7C01%7Crob%40sectigo.com%7Ce7e29d7140f44c1dcefe08d8b25d3ee2%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637455460852670010%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=v3WWmrZ%2BczWqn4LUyiJO1O4RhrXG6xi7Hd6xDFkqsXY%3D&reserved=0"
originalsrc="https://lists.cabforum.org/pipermail/servercert-wg/2020-April/001821.html"
shash="VnI0cbEaYh2/YTznWakRZfp0F9AdyxQlA3DSkuTUmgFttvuYj6n885VhD5PvoA0GNw1+iW5qJ3PW2N5pDD7sJYy0fPWf8eHqH6rcHrLKpKOC7RxKRm2GAfIl5NcGJ7mrrKIJb3GqoM0cB/xa2v8weDQOFuPLLx6d2g33n+g2pjM="
moz-do-not-send="true">https://lists.cabforum.org/pipermail/servercert-wg/2020-April/001821.html</a>).
There were two objections:<br>
<br>
- The list (openssl-blacklist) is subject to change
or removal.<br>
- The list only covers 2048 and 4096 bit keys.<br>
<br>
The current draft proposes specifying a tool for
ROCA (<a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcrocs-muni%2Froca&data=04%7C01%7Crob%40sectigo.com%7Ce7e29d7140f44c1dcefe08d8b25d3ee2%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637455460852670010%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=H7Ef2bXKl4zRilJF%2BMHLfCl0w9un6%2BuqXFgAm6jwPdg%3D&reserved=0"
originalsrc="https://github.com/crocs-muni/roca"
shash="PpS5KbI5Ykvi/kgyxHjvgOh1DI2m6ZklGNmbj13o23oSTlW+0RaF5RKB1yBmNEpj4nA16GaS9jAIXg/0vbfyytDWEKFYRadmzbzUXDu2NmJPRQluozfhBbufeGARyOlRSGXnURMu8RJmTtoN44onYVhMNedpxHnI/XLwYgkv388="
moz-do-not-send="true">https://github.com/crocs-muni/roca</a>)
and an algorithm for Debian keys.<br>
<br>
The ROCA tool is subject to change or removal, just
like the openssl-blacklist package. I propose we
instead specify ROCA detection in terms of the paper
(<a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcrocs.fi.muni.cz%2Fpublic%2Fpapers%2Frsa_ccs17&data=04%7C01%7Crob%40sectigo.com%7Ce7e29d7140f44c1dcefe08d8b25d3ee2%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637455460852679970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=GTtJjEMD2zioGSMLfWIOd2Qi7ihr5Xh%2FoewI01ZlrYE%3D&reserved=0"
originalsrc="https://crocs.fi.muni.cz/public/papers/rsa_ccs17"
shash="OsyybFrkTL7Idggk0rdN14L+nST0KmOwxdMJi4ekOgftEpTVVmQv2529/76EmT6nhvcJcJdFvXqJVFVRh0qTaqFwgE1OCe0WOZ5CZEliGZBilDdSGEA+18VHOizIVOZzm6ke+JSwJOoz9MJSOwha6hrVowqbFkQdohEg//eLDiE="
moz-do-not-send="true">https://crocs.fi.muni.cz/public/papers/rsa_ccs17</a>)
and ask for permission from the authors to archive
an unchanging copy as an addendum to the BRs.<br>
<br>
For Debian keys, what looks like an algorithm
specification is actually a tool + algorithm
specification. The tool is "OpenSSL 0.9.8c-1 up to
versions before 0.9.8g-9 on Debian-based operating
systems" (per CVE-2008-01666 -
<a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcve.mitre.org%2Fcgi-bin%2Fcvename.cgi%3Fname%3D2008-0166&data=04%7C01%7Crob%40sectigo.com%7Ce7e29d7140f44c1dcefe08d8b25d3ee2%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637455460852679970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=7wMp181xHXI3CaLyZNozfYFKBjuxoKVU5KMiUCSltDc%3D&reserved=0"
originalsrc="https://cve.mitre.org/cgi-bin/cvename.cgi?name=2008-0166"
shash="EhwgRW1d4pRP5b6Y5bOIKf23Kf6cyqAxMJtPwTFJCLkKu0/ZC28Hutpfx40YN1qcgs52zfuIYvvPTmIUDwDfxwpgCYTjcZ9bIqNVKkibXrxhE0UmD+iUcWm/S6kkgIriP9MPc7UIkkhJSOMoGzFZZcCZA5PMAcRtkYJvAhRRedA="
moz-do-not-send="true">
https://cve.mitre.org/cgi-bin/cvename.cgi?name=2008-0166</a>). To ensure
an unchanging copy of that, we should archive 3
copies of Debian, for the 3 word size + endianness
combinations.<br>
<br>
The algorithm also needs an additional line: "v)
using the command 'openssl req -nodes -subj /
-newkey rsa:<Public Key length>'" (adapted
from
<a
href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsources.debian.org%2Fdata%2Fmain%2Fo%2Fopenssl-blacklist%2F0.5-3%2Fexamples%2Fgen_certs.sh&data=04%7C01%7Crob%40sectigo.com%7Ce7e29d7140f44c1dcefe08d8b25d3ee2%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637455460852689928%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000&sdata=vM1lPojpzPxNGt%2FsYru8ldt%2Bcd2GKPcD6jsNNsmq%2BGo%3D&reserved=0"
originalsrc="https://sources.debian.org/data/main/o/openssl-blacklist/0.5-3/examples/gen_certs.sh"
shash="A7t7Yyb7PsRBmtlpEJb1lESPFAo4k8egX4AnCAlnkLGIubh6L0JH7hhsqCjap3d9l6n51TqsKIYUY1n7/jww4qLgyXV8LUjTuhqf5rmO4qGmr6yGgq0alwpiZvKViJdd2077y+ac0cYZ4XLYPZ8oZSNVvi5ggVNQGBXi2I4/1Pg="
moz-do-not-send="true">
https://sources.debian.org/data/main/o/openssl-blacklist/0.5-3/examples/gen_certs.sh</a>).
Other tools that linked OpenSSL, like openvpn and
openssh, generated different sets of keys. We can
include or exclude openvpn and openssh keys, but
should thoroughly specify.<br>
<br>
Lastly, I think we should archive openssl-blacklist,
and include in the BRs: "A CA may reject the full
set of Debian weak keys by rejecting this superset
of the Debian weak keys:<br>
<br>
- All RSA public keys with modulus lengths other
than 2048 or 4096, and<br>
- All RSA public keys with exponents other than
65537, and<br>
- All RSA public keys that are detected as
vulnerable by the openssl-vulnkey program in the
openssl-blacklist package version 0.5-3 (see
addendum), or an equivalent program."<br>
<br>
My reasoning: Given the difficulty of correctly
setting up old Debian versions and generating weak
keys for sizes that are not part of
openssl-blacklist, I expect most CAs will choose
this path. Given that, we should just say what we
mean: the pregenerated list is fine if you restrict
key sizes, but you don't *have* to restrict key
sizes, so long as you have an alternate method to
ensure you're not issuing for Debian weak keys at
other sizes.<br>
<br>
*I'm considering specifying an algorithm to be
functionally equivalent to specifying an "outcome,"
though I recognize this may be too hand-wavy.<br>
</div>
</div>
</div>
</div>
</div>
</div>
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Servercert-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Servercert-wg@cabforum.org">Servercert-wg@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/servercert-wg">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a>
</pre>
</blockquote>
<br>
</body>
</html>