<html>
<head>
<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>
</head>
<body dir="ltr">
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
> Rob Stradling: I would like to import your repo to github.com/cabforum/Debian-weak-keys. May I have your permission to do so?</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Hi Wayne. I put together the repositories at <a href="https://github.com/CVE-2008-0166" id="OWA6e28d323-bc9e-248e-04c0-4e9aa84b1c72" class="OWAAutoLink" data-loopstyle="linkonly">
https://github.com/CVE-2008-0166</a> a few years ago with the sole aim of providing a resource that would help CAs comply with the original version of this draft ballot, so I have no hesitation in giving my permission for CABForum to use these repositories
in whatever way(s) are felt to make sense.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
There are currently 3 repositories under the <a href="https://github.com/CVE-2008-0166" id="OWA02e9737b-98e4-f48b-a40d-295d6940d22f" class="OWAAutoLink" data-loopstyle="linkonly">
https://github.com/CVE-2008-0166</a> GitHub organization: key_generator, private_keys, and openssl_blocklists. Which of these are you looking to "import" (fork?) into
<a href="https://github.com/cabforum" id="OWA7cc18e3b-233e-95d2-3255-23d9c135523d" class="OWAAutoLink" data-loopstyle="linkonly">
https://github.com/cabforum</a> ?</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
key_generator is useful if anyone wants to check my work, or if Debian weak keys of any other sizes need to be generated in the future.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
private_keys holds the generated keys. Cloning this repository requires 12GB of disk space (just over 3GB for each of the 3 architectures, plus another 3GB for the ".git" directory)! Although each of the generated RSA keys has the public exponent 65537, it's
important to note that every public exponent is equally vulnerable when used with a vulnerable modulus (as described in the key_generator
<a href="https://github.com/CVE-2008-0166/key_generator?tab=readme-ov-file#pregenerated-keys-and-blocklists" title="https://github.com/CVE-2008-0166/key_generator?tab=readme-ov-file#pregenerated-keys-and-blocklists">
README</a>).</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
openssl_blocklists holds blocklists of the generated keys that are compatible with the openssl_vulnkey tool that was made available by Debian back in 2008. Only the weak RSA keys are supported, because openssl_vulnkey's file format is basically a list of
SHA-1 hashes of RSA moduli. Cloning this repository requires a mere 84MB of disk space though (18MB for each of the 3 architectures, plus 32MB for the ".git" directory).</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
To avoid having to deal with either an unwieldly 12GB repository or RSA-only blocklists, I'm considering creating another repository that would hold blocklists in a more focused format. Perhaps SHA-256(Modulus) for RSA keys, and SHA-256(X_Coordinate) for EC
keys?</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
Finally, I'm open to transferring control of the whole <a href="https://github.com/CVE-2008-0166">
https://github.com/CVE-2008-0166</a> GitHub organization to CABForum, if that might be considered a suitable alternative to "import"ing one or more of the repositories into
<a href="https://github.com/cabforum">https://github.com/cabforum</a>.</div>
<div class="elementToProof" style="font-family: Aptos, Aptos_EmbeddedFont, Aptos_MSFontService, Calibri, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);">
<br>
</div>
<hr style="display: inline-block; width: 98%;">
<div style="direction: ltr; font-family: Calibri, sans-serif; font-size: 11pt; color: rgb(0, 0, 0);">
<b>From:</b> Servercert-wg <servercert-wg-bounces@cabforum.org> on behalf of Wayne Thayer via Servercert-wg <servercert-wg@cabforum.org><br>
<b>Sent:</b> 12 April 2024 20:41<br>
<b>To:</b> Clint Wilson <clintw@apple.com><br>
<b>Cc:</b> ServerCert CA/BF <servercert-wg@cabforum.org><br>
<b>Subject:</b> Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal</div>
<div style="direction: ltr;"> </div>
<div style="text-align: left; line-height: 12pt; background-color: rgb(250, 250, 3); padding: 2pt; border-width: 1pt; border-style: solid; border-color: rgb(0, 0, 0); font-family: Calibri; font-size: 10pt;">
<span style="color: rgb(0, 0, 0);">CAUTION:</span><span style="color: black;"> 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></div>
<br>
<div style="direction: ltr;">Thank you Clint and Aaron, this is helpful. Here is what I propose:</div>
<div style="direction: ltr;"><br>
</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);">
<div style="direction: ltr;">In the case of Debian weak keys vulnerability ([<a href="https://wiki.debian.org/SSLkeys)]" id="OWAa4b52700-18e8-3de3-b46f-41468bd941cf" class="OWAAutoLink" shash="cItjkbNwRFH5j2gEXwz+PizgLKPS3YM6G2pmNQsj9jhLHFDzbegt/hPZVHvP52KcH1ynRvVG9LM64Xr8ILJjg2bm0ANrpRvlxp1QBswt7p9C7GBDk/3tjC/Wx4YSt2wweyb8Y975mYRyB94ScoZFqxCvqtZDluzU/B802HtltcY=" originalsrc="https://wiki.debian.org/SSLkeys)]" data-auth="Verified" data-loopstyle="linkonly">https://wiki.debian.org/SSLkeys)]</a>),
the CA SHALL reject all keys found at [<a href="https://github.com/cabforum/debian-weak-keys/" id="OWA414ab2e9-e925-42fa-9679-bdac79474db0" class="OWAAutoLink" shash="L62GQhYwDH305sqKxVfyCKBxFJhyd4ejtYIyMuRssILVnRjzCBokK7PJVpJyJJrfbaP0IKu02j293za3mx0nqNpd++gumGqR5vTmCoeptju0+kmLCIbkC3MqoEtwsuqiRwWOL7OIiCxc0eKijjYOgd03xdFMUyQv5f++80eeqig=" originalsrc="https://github.com/cabforum/debian-weak-keys/" data-auth="Verified" data-loopstyle="linkonly">https://github.com/cabforum/debian-weak-keys/</a>]
for each key type (e.g. RSA, ECDSA) and size listed in the repository. For all other key types and sizes, the CA SHALL reject Debian weak keys.</div>
</blockquote>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">This change can be viewed in context <a href="https://github.com/wthayer/servercert/pull/1/files" id="OWAa49a4af9-299d-87bf-a9af-c7ae41448cf0" class="OWAAutoLink" shash="E7Q69lFNmRMyt4jgqWJuGZysBHtQX/vLP4lQC4YDDbtWhoJXCCqLywKdm0Eni3hFcT9MwJLrCoOrGByNEEN5PXmgQHvKXS0FKFgvilwDOpsJ7uzXIDhVfS0k84G3Gcl0/w31pXuQxLMyMa03YMdbJoVaflSPfH92XuyFJxNhIrQ=" originalsrc="https://github.com/wthayer/servercert/pull/1/files" data-auth="Verified" data-loopstyle="linkonly">
https://github.com/wthayer/servercert/pull/1/files</a></div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">This language allows us to add key sizes in the future without updating the TLS BRs.</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">Clint Wilson: I did not exclude key sizes larger than 8192 RSA/521 ECDSA bits from the requirements but would be happy to do so if you will confirm that this was your intent?</div>
<div style="direction: ltr;"><br>
</div>
<div class="elementToProof" style="direction: ltr;">Rob Stradling: I would like to import your repo to
<a href="http://github.com/cabforum/Debian-weak-keys" id="OWAa14d7c10-2776-5b25-4a1e-266ebda9164a" class="OWAAutoLink" shash="R5zuUbNk+HT0dCQBBnVT48WHjNJ4gAeX/TCgTiipKVfmIsa6VmpnpXJx5eFTpISE/3Dyvxz958nAZ2MPcMc8JsshN/dCo0krjZDAiA2oVekXTUyh7jNHNjJ3lJNChmPqSXnjhSR38F52npmlRlflQeihzpoTq7ML0tQ7VyNFh0Y=" originalsrc="http://github.com/cabforum/Debian-weak-keys" data-auth="Verified" data-loopstyle="linkonly">
github.com/cabforum/Debian-weak-keys</a>. May I have your permission to do so?</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">Thanks,</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">Wayne</div>
<br>
<div style="direction: ltr;">On Thu, Apr 11, 2024 at 10:11 AM Clint Wilson <<a href="mailto:clintw@apple.com" id="OWA850113e1-96a5-bfc6-ad18-c231c7a332a6" class="OWAAutoLink" data-loopstyle="linkonly">clintw@apple.com</a>> wrote:</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);">
<div>Hi Aaron,</div>
<div><br>
</div>
<div>Your proposed phrasing sounds good to me and matches what I had in mind as the end result of the changes represented in Set 1, just structured slightly differently.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>-Clint</div>
<div><br>
</div>
<blockquote>
<div>On Apr 11, 2024, at 9:47 AM, Aaron Gable <<a href="mailto:aaron@letsencrypt.org" id="OWA59e111b1-e5e4-4ab4-71cd-e1561ad5b5ab" class="OWAAutoLink" data-loopstyle="linkonly">aaron@letsencrypt.org</a>> wrote:</div>
<br>
<div style="direction: ltr;">On Thu, Apr 11, 2024 at 9:12 AM Clint Wilson via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" id="OWA96643e1e-020a-546f-9c10-617b0aa80d53" class="OWAAutoLink" data-loopstyle="linkonly">servercert-wg@cabforum.org</a>>
wrote:</div>
<blockquote style="margin: 0px 0px 0px 0.8ex; padding-left: 1ex; border-left: 1px solid rgb(204, 204, 204);">
<div style="direction: ltr;">In other words, I believe it satisfactory to establish a constrained set of Debian weak keys which CAs must block (rather than leaving the requirement fully open-ended), but I don’t believe that should obviate the need for a CA
to check uncommon key sizes — which are otherwise in the key size ranges of that constrained set’s key sizes — should a CA allow those uncommon key sizes. </div>
</blockquote>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">I completely concur. </div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">I don't think that either of your Set 1 / Set 2 proposals quite hits the mark for me, for one reason: they both contain the phrase "CAs must not issue certificates containing Debian weak keys". As long as that statement exists,
the requirement is "evaluate everything yourself, and if new sets of weak keys come to light, you're already behind" -- the existence of the github repo is just a nicety.</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">Instead, I would phrase the requirement as "In the case of [list of common RSA and ECDSA key sizes] Debian Weak Keys, the CA SHALL reject keys identified by [link to CABF repository]. For other key sizes, the CA SHALL reject Debian
Weak Keys."</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">In other words -- for these common key sizes, the repository is the source of truth. Every key in it is considered compromised and must be blocked, but you don't need to waste time replicating the work of generating all of these
keys to prove to yourself that it has been done correctly. If you want to issue for other key sizes, then the onus is on you to do the relevant due diligence.</div>
<div style="direction: ltr;"><br>
</div>
<div style="direction: ltr;">Aaron</div>
</blockquote>
<br>
</blockquote>
</body>
</html>