[Servercert-wg] Compromised/Weak Keys Ballot Proposal

Tue Apr 16 00:15:44 UTC 2024

Thank you Tomas, this is helpful feedback. I have updated the proposed
language as follows:

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 keys meeting
> the requirements of [Section 6.1.5](#615-key-sizes), with the exception of
> RSA key sizes greater than 8192 bits, the CA SHALL reject Debian weak keys.

I believe this is less confusing in the context of section 6.1.5 but
otherwise does not change the proposed requirements.

Thanks,

Wayne

On Sat, Apr 13, 2024 at 1:23 AM Tomas Gustavsson <
Tomas.Gustavsson at keyfactor.com> wrote:

> Parts feel a bit redundant and confusing to me. As 6.1.5 specifies key
> types and sizes. An EC key pair with 184 bits should never make it to this
> check since only NIST P-256, NIST P-384 or NIST P-521 are allowed. No other
> key types than RSA and EC are allowed so what are "all other key types"?
> Is it that if ML-DSA is added as allowed in 6.1.5 in the future a CA is
> expected to find a way to generate ML-DSA keys on an old Debian system?
> That sounds a bit hard, and these keys should be added to the repo in that
> case, if desired, shouldn't it?
>
> Since adding ML-DSA seems like potentially the most likely future addition
> of keys, what changes are expected then?
>
> Regards,
> Tomas
>
>
> ------------------------------
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of
> Wayne Thayer via Servercert-wg <servercert-wg at cabforum.org>
> *Sent:* Friday, April 12, 2024 11:35:42 PM
> *To:* Clint Wilson <clintw at apple.com>; ServerCert CA/BF <
> servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
> 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/
> 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
> <https://urldefense.com/v3/__https://wiki.debian.org/SSLkeys__;!!BjbSd3t9V7AnTp3tuV-82YaK!yX4W6PVddaeXFMyavnUXrc_MlL3jDlGVklxumGHAbVoCU_3aE3OKUa69ss71NlchtXX0myESs2HNlSlDLGZM5UyI8geLuHbWd_I$>)),
> 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)]
> <https://urldefense.com/v3/__https://wiki.debian.org/SSLkeys)*5D__;JQ!!BjbSd3t9V7AnTp3tuV-82YaK!yX4W6PVddaeXFMyavnUXrc_MlL3jDlGVklxumGHAbVoCU_3aE3OKUa69ss71NlchtXX0myESs2HNlSlDLGZM5UyI8geLef72tUc$>),
> 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/20240415/1386bd07/attachment.html>