Thank you Tomas, this is helpful feedback. I have updated the proposed language as follows:
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 keys meeting > the requirements of [Section 6.1.5](#615-key-sizes), with the exception of > RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys. I believe this is less confusing in the context of section 6.1.5 but otherwise does not change the proposed requirements. Thanks, Wayne On Sat, Apr 13, 2024 at 1:23 AM Tomas Gustavsson < tomas.gustavs...@keyfactor.com> wrote: > 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 allowed 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? > > Since adding ML-DSA seems like potentially the most likely future addition > of keys, what changes are expected then? > > Regards, > Tomas > > > ------------------------------ > *From:* Servercert-wg <servercert-wg-boun...@cabforum.org> on behalf of > Wayne Thayer via Servercert-wg <servercert-wg@cabforum.org> > *Sent:* Friday, April 12, 2024 11:35:42 PM > *To:* Clint Wilson <cli...@apple.com>; ServerCert CA/BF < > servercert-wg@cabforum.org> > *Subject:* Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal > > 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/ > 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 > <https://urldefense.com/v3/__https://wiki.debian.org/SSLkeys__;!!BjbSd3t9V7AnTp3tuV-82YaK!yX4W6PVddaeXFMyavnUXrc_MlL3jDlGVklxumGHAbVoCU_3aE3OKUa69ss71NlchtXX0myESs2HNlSlDLGZM5UyI8geLuHbWd_I$>)), > 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, 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. > > > - Wayne > > On Fri, Apr 12, 2024 at 12:44 PM Clint Wilson <cli...@apple.com> wrote: > > Hi Wayne, > > That was indeed my intent, but I’m happy with the proposal either way. > > Thank you, > -Clint > > On Apr 12, 2024, at 12:33 PM, Wayne Thayer <wtha...@gmail.com> wrote: > > 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)] > <https://urldefense.com/v3/__https://wiki.debian.org/SSLkeys)*5D__;JQ!!BjbSd3t9V7AnTp3tuV-82YaK!yX4W6PVddaeXFMyavnUXrc_MlL3jDlGVklxumGHAbVoCU_3aE3OKUa69ss71NlchtXX0myESs2HNlSlDLGZM5UyI8geLef72tUc$>), > 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. May I have your permission to do so? > > Thanks, > > Wayne > > On Thu, Apr 11, 2024 at 10:11 AM Clint Wilson <cli...@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 <aa...@letsencrypt.org> wrote: > > On Thu, Apr 11, 2024 at 9:12 AM Clint Wilson via Servercert-wg < > servercert-wg@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 > > > >
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
