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 > <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 <cli...@apple.com > <mailto: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 >>> <mailto:aa...@letsencrypt.org>> wrote: >>> >>> On Thu, Apr 11, 2024 at 9:12 AM Clint Wilson via Servercert-wg >>> <servercert-wg@cabforum.org <mailto: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 >>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Servercert-wg mailing list Servercert-wg@cabforum.org https://lists.cabforum.org/mailman/listinfo/servercert-wg
