Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Wayne Thayer via Servercert-wg]

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  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  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  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  wrote:
>>
>> On Thu, Apr 11, 2024 at 9:12 AM Clint Wilson via Servercert-wg <
>> 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
>>
>>
>>
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Clint Wilson via Servercert-wg]

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

Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Wayne Thayer via Servercert-wg]

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  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  wrote:
>
> On Thu, Apr 11, 2024 at 9:12 AM Clint Wilson via Servercert-wg <
> 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
>
>
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg