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/ 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)]), 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
