[Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Wayne Thayer]

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 <clintw at 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 <wthayer at 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 <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/6d72d0ec/attachment.html>