> When creating a new repository, the GitHub UI provides the option to "import > your project to GitHub". I'm happy to fork if that is the preferred approach.
Of those two options I'd prefer forking, so that the origin is clear and so that it's easier to pull in any future upstream changes. > I would prefer to reference the raw keys in the BRs and allow CAs the > flexibility to determine the format they want to use in their checks. Makes sense. I suppose we could always provide links in the github.com/cabforum/Debian-weak-keys README to other repositories that (claim to) hold alternative, more compact checking formats for the same key material. ________________________________ From: Wayne Thayer <wtha...@gmail.com> Sent: 17 April 2024 00:46 To: Rob Stradling <r...@sectigo.com> Cc: Clint Wilson <cli...@apple.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@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. On Tue, Apr 16, 2024 at 3:23 PM Rob Stradling <r...@sectigo.com<mailto:r...@sectigo.com>> wrote: > 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? 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. Thank you Rob. 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 ? The intent of the ballot is to reference a set of weak keys, so my intention is to host the contents of your private_keys repository in the cabforum GitHub organization. When creating a new repository, the GitHub UI provides the option to "import your project to GitHub". I'm happy to fork if that is the preferred approach. 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? I would prefer to reference the raw keys in the BRs and allow CAs the flexibility to determine the format they want to use in their checks. 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. I'm not opposed, but I am concerned that this might further delay the ballot. If others prefer this approach, please speak up. - Wayne
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
