[Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Wayne Thayer]

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 <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> wrote:
>
> On Thu, Apr 11, 2024 at 9:12 AM Clint Wilson via Servercert-wg <
> 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/20240412/21450846/attachment.html>