[Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Rob Stradling]

> Rob Stradling: I would like to import your repo to github.com/cabforum/Debian-weak-keys. May I have your permission to do so?

Hi Wayne.  I put together the repositories at https://github.com/CVE-2008-0166 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.

There are currently 3 repositories under the https://github.com/CVE-2008-0166 GitHub organization: key_generator, private_keys, and openssl_blocklists.  Which of these are you looking to "import" (fork?) into https://github.com/cabforum ?

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.

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 README<https://github.com/CVE-2008-0166/key_generator?tab=readme-ov-file#pregenerated-keys-and-blocklists>).

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).

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?

Finally, I'm open to transferring control of the whole https://github.com/CVE-2008-0166 GitHub organization to CABForum, if that might be considered a suitable alternative to "import"ing one or more of the repositories into https://github.com/cabforum.

________________________________
From: Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of Wayne Thayer via Servercert-wg <servercert-wg at cabforum.org>
Sent: 12 April 2024 20:41
To: Clint Wilson <clintw at apple.com>
Cc: ServerCert CA/BF <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

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.

Thank you Clint and Aaron, this is helpful. Here is what I propose:

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/] 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.

This change can be viewed in context https://github.com/wthayer/servercert/pull/1/files

This language allows us to add key sizes in the future without updating the TLS BRs.

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?

Rob Stradling: I would like to import your repo to github.com/cabforum/Debian-weak-keys<http://github.com/cabforum/Debian-weak-keys>. May I have your permission to do so?

Thanks,

Wayne

On Thu, Apr 11, 2024 at 10:11 AM Clint Wilson <clintw at apple.com<mailto:clintw at apple.com>> wrote:
Hi Aaron,

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.

Cheers,
-Clint

On Apr 11, 2024, at 9:47 AM, Aaron Gable <aaron at letsencrypt.org<mailto:aaron at letsencrypt.org>> wrote:

On Thu, Apr 11, 2024 at 9:12 AM Clint Wilson via Servercert-wg <servercert-wg at cabforum.org<mailto:servercert-wg at cabforum.org>> wrote:
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.

I completely concur.

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.

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."

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.

Aaron

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240416/15af85a8/attachment-0001.html>