<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<div dir="auto">Parts feel a bit redundant and confusing to me. As 6.1.5 specifies key types and sizes. An EC key pair with 184 bits should never make it to this check since only NIST P-256, NIST P-384 or NIST P-521 are allowed. No other key types than RSA
and EC are all<span>owed so what are "all other key types"? Is it that if ML-DSA is added as allowed in 6.1.5 in the future a CA is expected to find a way to generate ML-DSA keys on an old Debian system? That sounds a bit hard, and these keys should be added
to the repo in that case, if desired, shouldn't it?</span><span></span></div>
<div dir="auto"><span><br>
</span></div>
<div dir="auto">Since adding ML-DSA seems like potentially the most likely future addition of keys, what changes are expected then?<span></span></div>
<div dir="auto"><br>
</div>
<div dir="auto"><span>Regards,</span></div>
<div dir="auto"><span>Tomas</span></div>
<div dir="auto"><span><br>
</span></div>
<div dir="auto"><span><br>
</span></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><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> Friday, April 12, 2024 11:35:42 PM<br>
<b>To:</b> Clint Wilson <clintw@apple.com>; ServerCert CA/BF <servercert-wg@cabforum.org><br>
<b>Subject:</b> Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal</font>
<div> </div>
</div>
<style>
<!--
#x_pfptBannerk1hhc2n
{display:block!important;
visibility:visible!important;
opacity:1!important;
background-color:#D0D8DC!important;
max-width:none!important;
max-height:none!important}
-->
</style>
<div>
<div style="display:none!important; display:none; visibility:hidden; font-size:1px; color:#ffffff; line-height:1px; height:0px; max-height:0px; opacity:0; overflow:hidden">
I've updated https: //github. com/wthayer/servercert/pull/1/files as follows to exclude large key sizes: In the case of Debian weak keys vulnerability (https: //wiki. debian. org/SSLkeys)), the CA SHALL reject all keys found at https: //github. com/cabforum/debian-weak-keys/
</div>
<div style="display:none!important; display:none; visibility:hidden; font-size:1px; color:#ffffff; line-height:1px; height:0px; max-height:0px; opacity:0; overflow:hidden">
</div>
<div dir="ltr">
<div>I've updated <a href="https://github.com/wthayer/servercert/pull/1/files" originalsrc="https://github.com/wthayer/servercert/pull/1/files" shash="coF5DU0uE4FrC4g/H9RzfLm07COMzYeq/59a/xWcw4Z+FkXgGLag+sKl0AoHjGy9dqDM6nYYpDpBmto5uKAXt1RA2aD+1WRVOlmMLZhQfITTw65JU9U3zCxASWoaUQhu8FCQSFzjun+lkvGDzIEW98e8L5sb6qJxjeIBEgukRUw=">
https://github.com/wthayer/servercert/pull/1/files</a> as follows to exclude large key sizes:</div>
<div><br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
In the case of Debian weak keys vulnerability (<a href="https://urldefense.com/v3/__https://wiki.debian.org/SSLkeys__;!!BjbSd3t9V7AnTp3tuV-82YaK!yX4W6PVddaeXFMyavnUXrc_MlL3jDlGVklxumGHAbVoCU_3aE3OKUa69ss71NlchtXX0myESs2HNlSlDLGZM5UyI8geLuHbWd_I$" rel="nofollow">https://wiki.debian.org/SSLkeys</a>)),
the CA SHALL reject all keys found at <a href="https://github.com/cabforum/debian-weak-keys/" originalsrc="https://github.com/cabforum/debian-weak-keys/" shash="PpY3CgVHK30BR2cSninpPvf6XMZSuw6Pkkfxn7SvFegTX+QWCq7nQxYr60dDkwIrkIiqBWXuFAYGkpLO1vLzp2APV799pnwPhNxtcWvdHI52viX7I8I2MCnwtHfZUk0x/LswEy/Kmhdo0y9qZXMMLxbQtnyTSGop2PK5CXSZCwg=">
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, with the exception of RSA key sizes greater than 8192 bits and ECC key sizes greater than 521 bits, the
CA SHALL reject Debian weak keys.</blockquote>
<div><br>
</div>
<div>- Wayne<br>
</div>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Fri, Apr 12, 2024 at 12:44 PM Clint Wilson <<a href="mailto:clintw@apple.com">clintw@apple.com</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div>Hi Wayne,
<div><br>
</div>
<div>That was indeed my intent, but I’m happy with the proposal either way.</div>
<div><br>
</div>
<div>Thank you,</div>
<div>-Clint<br id="x_m_5191263597241014951lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On Apr 12, 2024, at 12:33 PM, Wayne Thayer <<a href="mailto:wthayer@gmail.com" target="_blank">wthayer@gmail.com</a>> wrote:</div>
<br>
<div>
<div dir="ltr">
<div>Thank you Clint and Aaron, this is helpful. Here is what I propose:</div>
<div><br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
In the case of Debian weak keys vulnerability ([<a href="https://urldefense.com/v3/__https://wiki.debian.org/SSLkeys)*5D__;JQ!!BjbSd3t9V7AnTp3tuV-82YaK!yX4W6PVddaeXFMyavnUXrc_MlL3jDlGVklxumGHAbVoCU_3aE3OKUa69ss71NlchtXX0myESs2HNlSlDLGZM5UyI8geLef72tUc$" target="_blank">https://wiki.debian.org/SSLkeys)]</a>),
the CA SHALL reject all keys found at [<a href="https://github.com/cabforum/debian-weak-keys/" originalsrc="https://github.com/cabforum/debian-weak-keys/" shash="lKLZXg9E1wLu6xDM8Jtb3mJ5zspBX79wA+qHh2KedJDUwIOA+4zDC2jE6uPbaUfUx7qCXBbbwFr7d2QmsbuPdWE8qch0X4fLIR4zDr1MaXnF3x4eXFPYG42+MNPBJzvJJbqIby9Q5GlHSxKV1JZldrUupXcR45YBVpEZKRlgbxM=" target="_blank">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.</blockquote>
<div><br>
</div>
<div>This change can be viewed in context <a href="https://github.com/wthayer/servercert/pull/1/files" originalsrc="https://github.com/wthayer/servercert/pull/1/files" shash="HEm0JlT5xguVlAAxFdX2dcivsLO+tmPsLXBpIe7DGVRPXl2bgwdFudGWk1mUdY7P/6ttj6efW7WUJfmKE6HL++7ulQc4CmafP894um7xVyOa0G0DkoqF+N+lFI6tVK0HZmIDa3jZORAYNcYwHmy4aPBRrUisaMQfvGDrXT2HjhQ=" target="_blank">
https://github.com/wthayer/servercert/pull/1/files</a></div>
<div><br>
</div>
<div>This language allows us to add key sizes in the future without updating the TLS BRs.<br>
</div>
<div><br>
</div>
<div>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?<br>
</div>
<div><br>
</div>
<div>Rob Stradling: I would like to import your repo to <a href="http://github.com/cabforum/Debian-weak-keys" originalsrc="http://github.com/cabforum/Debian-weak-keys" shash="t0zyYw8dMVIvO1ATvBw0Jf8KHSiQrDjbqAZjY9Yp0vsVoc/duF+ETVj2coUJbUWnWtYYUU/E251EHijx0eA2S/3M7Cp4wmu5rpIR7iMuCsHzIJ2VBWGYkX8roy/c9annzjhsc8SHtdXA89Z4muVeIN1ajgDwK5SUF4oIwW9/viU=" target="_blank">
github.com/cabforum/Debian-weak-keys</a>. May I have your permission to do so?</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Wayne<br>
</div>
</div>
<br>
<div class="x_gmail_quote">
<div dir="ltr" class="x_gmail_attr">On Thu, Apr 11, 2024 at 10:11 AM Clint Wilson <<a href="mailto:clintw@apple.com" target="_blank">clintw@apple.com</a>> wrote:<br>
</div>
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div>Hi Aaron,
<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<br id="x_m_5191263597241014951m_3440439619087541120lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On Apr 11, 2024, at 9:47 AM, Aaron Gable <<a href="mailto:aaron@letsencrypt.org" target="_blank">aaron@letsencrypt.org</a>> wrote:</div>
<br>
<div>
<div dir="ltr">
<div dir="ltr">On Thu, Apr 11, 2024 at 9:12 AM Clint Wilson via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:</div>
<div class="x_gmail_quote">
<blockquote class="x_gmail_quote" style="margin:0px 0px 0px 0.8ex; border-left:1px solid rgb(204,204,204); padding-left:1ex">
<div>
<div>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>
</div>
</blockquote>
<div><br>
</div>
<div>I completely concur. </div>
<div><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>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><br>
</div>
<div>Aaron</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</blockquote>
</div>
</div>
</body>
</html>