[Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Aaron Gable]

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/20240411/13ad4b77/attachment.html>