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

[Rob Stradling via Servercert-wg]

> When creating a new repository, the GitHub UI provides the option to "import 
> your project to GitHub". I'm happy to fork if that is the preferred approach.

Of those two options I'd prefer forking, so that the origin is clear and so 
that it's easier to pull in any future upstream changes.

> I would prefer to reference the raw keys in the BRs and allow CAs the 
> flexibility to determine the format they want to use in their checks.

Makes sense.

I suppose we could always provide links in the 
github.com/cabforum/Debian-weak-keys README to other repositories that (claim 
to) hold alternative, more compact checking formats for the same key material.


From: Wayne Thayer 
Sent: 17 April 2024 00:46
To: Rob Stradling 
Cc: Clint Wilson ; CA/B Forum Server Certificate WG Public 
Discussion List 
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

On Tue, Apr 16, 2024 at 3:23 PM Rob Stradling 
mailto:r...@sectigo.com>> wrote:
> Rob Stradling: I would like to import your repo to 
> github.com/cabforum/Debian-weak-keys<http://github.com/cabforum/Debian-weak-keys>.
>  May I have your permission to do so?

Hi Wayne.  I put together the repositories at https://github.com/CVE-2008-0166 
a few years ago with the sole aim of providing a resource that would help CAs 
comply with the original version of this draft ballot, so I have no hesitation 
in giving my permission for CABForum to use these repositories in whatever 
way(s) are felt to make sense.

Thank you Rob.

There are currently 3 repositories under the https://github.com/CVE-2008-0166 
GitHub organization: key_generator, private_keys, and openssl_blocklists.  
Which of these are you looking to "import" (fork?) into 
https://github.com/cabforum ?

The intent of the ballot is to reference a set of weak keys, so my intention is 
to host the contents of your private_keys repository in the cabforum GitHub 
organization.

When creating a new repository, the GitHub UI provides the option to "import 
your project to GitHub". I'm happy to fork if that is the preferred approach.

key_generator is useful if anyone wants to check my work, or if Debian weak 
keys of any other sizes need to be generated in the future.

private_keys holds the generated keys.  Cloning this repository requires 12GB 
of disk space (just over 3GB for each of the 3 architectures, plus another 3GB 
for the ".git" directory)!  Although each of the generated RSA keys has the 
public exponent 65537, it's important to note that every public exponent is 
equally vulnerable when used with a vulnerable modulus (as described in the 
key_generator 
README<https://github.com/CVE-2008-0166/key_generator?tab=readme-ov-file#pregenerated-keys-and-blocklists>).

openssl_blocklists holds blocklists of the generated keys that are compatible 
with the openssl_vulnkey tool that was made available by Debian back in 2008.   
Only the weak RSA keys are supported, because openssl_vulnkey's file format is 
basically a list of SHA-1 hashes of RSA moduli.  Cloning this repository 
requires a mere 84MB of disk space though (18MB for each of the 3 
architectures, plus 32MB for the ".git" directory).

To avoid having to deal with either an unwieldly 12GB repository or RSA-only 
blocklists, I'm considering creating another repository that would hold 
blocklists in a more focused format.  Perhaps SHA-256(Modulus) for RSA keys, 
and SHA-256(X_Coordinate) for EC keys?

I would prefer to reference the raw keys in the BRs and allow CAs the 
flexibility to determine the format they want to use in their checks.

Finally, I'm open to transferring control of the whole 
https://github.com/CVE-2008-0166 GitHub organization to CABForum, if that might 
be considered a suitable alternative to "import"ing one or more of the 
repositories into https://github.com/cabforum.

I'm not opposed, but I am concerned that this might further delay the ballot. 
If others prefer this approach, please speak up.

- Wayne
___
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]

On Tue, Apr 16, 2024 at 3:23 PM Rob Stradling  wrote:

> > Rob Stradling: I would like to import your repo to
> github.com/cabforum/Debian-weak-keys. May I have your permission to do so?
>
> Hi Wayne.  I put together the repositories at
> https://github.com/CVE-2008-0166 a few years ago with the sole aim of
> providing a resource that would help CAs comply with the original version
> of this draft ballot, so I have no hesitation in giving my permission for
> CABForum to use these repositories in whatever way(s) are felt to make
> sense.
>

Thank you Rob.


> There are currently 3 repositories under the
> https://github.com/CVE-2008-0166 GitHub organization: key_generator,
> private_keys, and openssl_blocklists.  Which of these are you looking to
> "import" (fork?) into https://github.com/cabforum ?
>

The intent of the ballot is to reference a set of weak keys, so my
intention is to host the contents of your private_keys repository in the
cabforum GitHub organization.

When creating a new repository, the GitHub UI provides the option to
"import your project to GitHub". I'm happy to fork if that is the preferred
approach.


> key_generator is useful if anyone wants to check my work, or if Debian
> weak keys of any other sizes need to be generated in the future.
>
> private_keys holds the generated keys.  Cloning this repository requires
> 12GB of disk space (just over 3GB for each of the 3 architectures, plus
> another 3GB for the ".git" directory)!  Although each of the generated RSA
> keys has the public exponent 65537, it's important to note that every
> public exponent is equally vulnerable when used with a vulnerable modulus
> (as described in the key_generator README
> 
> ).
>
> openssl_blocklists holds blocklists of the generated keys that are
> compatible with the openssl_vulnkey tool that was made available by Debian
> back in 2008.   Only the weak RSA keys are supported, because
> openssl_vulnkey's file format is basically a list of SHA-1 hashes of RSA
> moduli.  Cloning this repository requires a mere 84MB of disk space though
> (18MB for each of the 3 architectures, plus 32MB for the ".git" directory).
>
> To avoid having to deal with either an unwieldly 12GB repository or
> RSA-only blocklists, I'm considering creating another repository that would
> hold blocklists in a more focused format.  Perhaps SHA-256(Modulus) for RSA
> keys, and SHA-256(X_Coordinate) for EC keys?
>

I would prefer to reference the raw keys in the BRs and allow CAs the
flexibility to determine the format they want to use in their checks.


> Finally, I'm open to transferring control of the whole
> https://github.com/CVE-2008-0166 GitHub organization to CABForum, if that
> might be considered a suitable alternative to "import"ing one or more of
> the repositories into https://github.com/cabforum.
>

I'm not opposed, but I am concerned that this might further delay the
ballot. If others prefer this approach, please speak up.

- Wayne
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Rob Stradling via Servercert-wg]

> Rob Stradling: I would like to import your repo to 
> github.com/cabforum/Debian-weak-keys. May I have your permission to do so?

Hi Wayne.  I put together the repositories at https://github.com/CVE-2008-0166 
a few years ago with the sole aim of providing a resource that would help CAs 
comply with the original version of this draft ballot, so I have no hesitation 
in giving my permission for CABForum to use these repositories in whatever 
way(s) are felt to make sense.

There are currently 3 repositories under the https://github.com/CVE-2008-0166 
GitHub organization: key_generator, private_keys, and openssl_blocklists.  
Which of these are you looking to "import" (fork?) into 
https://github.com/cabforum ?

key_generator is useful if anyone wants to check my work, or if Debian weak 
keys of any other sizes need to be generated in the future.

private_keys holds the generated keys.  Cloning this repository requires 12GB 
of disk space (just over 3GB for each of the 3 architectures, plus another 3GB 
for the ".git" directory)!  Although each of the generated RSA keys has the 
public exponent 65537, it's important to note that every public exponent is 
equally vulnerable when used with a vulnerable modulus (as described in the 
key_generator 
README<https://github.com/CVE-2008-0166/key_generator?tab=readme-ov-file#pregenerated-keys-and-blocklists>).

openssl_blocklists holds blocklists of the generated keys that are compatible 
with the openssl_vulnkey tool that was made available by Debian back in 2008.   
Only the weak RSA keys are supported, because openssl_vulnkey's file format is 
basically a list of SHA-1 hashes of RSA moduli.  Cloning this repository 
requires a mere 84MB of disk space though (18MB for each of the 3 
architectures, plus 32MB for the ".git" directory).

To avoid having to deal with either an unwieldly 12GB repository or RSA-only 
blocklists, I'm considering creating another repository that would hold 
blocklists in a more focused format.  Perhaps SHA-256(Modulus) for RSA keys, 
and SHA-256(X_Coordinate) for EC keys?

Finally, I'm open to transferring control of the whole 
https://github.com/CVE-2008-0166 GitHub organization to CABForum, if that might 
be considered a suitable alternative to "import"ing one or more of the 
repositories into https://github.com/cabforum.


From: Servercert-wg  on behalf of Wayne 
Thayer via Servercert-wg 
Sent: 12 April 2024 20:41
To: Clint Wilson 
Cc: ServerCert CA/BF 
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

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<http://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 
mailto:cli...@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 
mailto:aa...@letsencrypt.org>> 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"

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

[Tomas Gustavsson via Servercert-wg]

Thank you. I like the updated text, very clear for me.

Regards,
Tomas

From: Wayne Thayer 
Sent: Tuesday, April 16, 2024 2:15:44 AM
To: Tomas Gustavsson 
Cc: CA/B Forum Server Certificate WG Public Discussion List 
; Clint Wilson 
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

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/

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)<https://urldefense.com/v3/__https://wiki.debian.org/SSLkeys)__;!!BjbSd3t9V7AnTp3tuV-82YaK!za0Jj82olCuYGKWLYrMuc9J8Tu3s4yw0bKTcuygTP4YhYAK6-OU3yRDEB4JzuJw2AYBBF21FRL1grcFAdDZdt4GX$>),
 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 
mailto:tomas.gustavs...@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 
mailto:servercert-wg-boun...@cabforum.org>> 
on behalf of Wayne Thayer via Servercert-wg 
mailto:servercert-wg@cabforum.org>>
Sent: Friday, April 12, 2024 11:35:42 PM
To: Clint Wilson mailto:cli...@apple.com>>; ServerCert CA/BF 
mailto:servercert-wg@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 
mailto:cli...@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 
mailto:wtha...@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<http://github.com/

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

[Wayne Thayer via Servercert-wg]

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.gustavs...@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  on behalf of
> Wayne Thayer via Servercert-wg 
> *Sent:* Friday, April 12, 2024 11:35:42 PM
> *To:* Clint Wilson ; ServerCert CA/BF <
> servercert-wg@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  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)]
> <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  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
> o

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

[Roman Fischer via Servercert-wg]

Thanks Wayne for your efforts! I like the current wording very much.

Kind regards
Roman

From: Servercert-wg  On Behalf Of Wayne 
Thayer via Servercert-wg
Sent: Freitag, 12. April 2024 23:36
To: Clint Wilson ; ServerCert CA/BF 

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/ 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 
mailto:cli...@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 
mailto:wtha...@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://wiki.debian.org/SSLkeys)%5D>), 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<http://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 
mailto:cli...@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 
mailto:aa...@letsencrypt.org>> 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


___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Tomas Gustavsson via Servercert-wg]

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  on behalf of Wayne 
Thayer via Servercert-wg 
Sent: Friday, April 12, 2024 11:35:42 PM
To: Clint Wilson ; ServerCert CA/BF 

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 
mailto:cli...@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 
mailto:wtha...@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<http://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 
mailto:cli...@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 
mailto:aa...@letsencrypt.org>> 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, th

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

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

[Clint Wilson via Servercert-wg]

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

[Aaron Gable via Servercert-wg]

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]

n. From what I can gather, they’re 
>> nearly identical in practical impact, but one provides a much more defined 
>> boundary for relying parties. 
>> 
>> Option 1:
>> The CA/BF creates or mirrors a repository of pre-computed Debian Weak keys 
>> for the following key sizes (representing those most commonly issued 
>> against): RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521. The TBRs stipulate 
>> that CAs must not issue certificates containing keys in this repository.
>> 
>> Option 2:
>> The CA/BF creates or mirrors a repository of pre-computed Debian Weak keys 
>> for the following key sizes (representing those most commonly issued 
>> against): RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521. The TBRs stipulate 
>> that CAs must not issue certificates containing weak keys, with a pointer to 
>> the repository of the most common key sizes of Debian Weak keys among other 
>> similar/relevant pointers for other vulnerabilities.
>> 
>> The reason these 2 proposals are so nearly identical in practice is that 
>> there are only a very tiny number of certificates issued against key sizes 
>> that are not RSA 2048, 3072, 4096, or 8192; or ECC 256, 384, or 521. By my 
>> count, somewhere around 80 certificates out of roughly 750 million (though I 
>> really only took a quick glance, so perhaps this is off to an extent… but 
>> probably not by huge quantities).
>> 
>> Under Option 2, if a CA wants to allow for Certificate requests containing a 
>> key size other than these 7, they’re fully free to do so; they must merely 
>> ensure the key is not a Debian Weak key. For every other CA, they can limit 
>> the accepted key sizes to those in the repository and the result is 
>> functionally the same as Option 1, but without the possibility of 
>> “certificates can be issued that are weak and CAs are under no obligation to 
>> prevent that if it’s not one of 7 key sizes”.
>> 
>> Concretely, is there a reason Option 2 is intractable for CAs? If so, I 
>> would greatly appreciate help understanding how that approach meaningfully 
>> differs from Option 1.
>> 
>> Thanks,
>> -Clint
>> 
>>> On Apr 9, 2024, at 11:43 AM, Rob Stradling via Servercert-wg 
>>> mailto:servercert-wg@cabforum.org>> wrote:
>>> 
>>> > * Aaron Gable commented in the PR with a suggestion that we require CAs 
>>> > to reject any key found in Hanno Bock's repository at 
>>> > https://github.com/badkeys/debianopenssl. This includes RSA 
>>> > 1024/2048/3072/4096 and EC P256/P384 keys.
>>> 
>>> Some of the EC key files in Hanno's repository have ASN.1 encoding issues 
>>> (see 
>>> https://www.mail-archive.com/dev-security-policy@mozilla.org/msg00911.html);
>>>  whereas the equivalent files 
>>> inhttps://github.com/CVE-2008-0166/private_keys are correctly encoded.
>>> 
>>> > * Roman Fischer suggested that we limit the requirement to check Debian 
>>> > weak keys only with sizes up to RSA 4096 under the logic that no one 
>>> > would “accidentally” create an 8192 bit RSA key on a system vulnerable to 
>>> > Debian Weak keys
>>> 
>>> FWIW, https://github.com/CVE-2008-0166/private_keys already has all of the 
>>> possible 8192-bit RSA Debian weak keys.
>>> 
>>> From: Servercert-wg >> <mailto:servercert-wg-boun...@cabforum.org>> on behalf of Wayne Thayer via 
>>> Servercert-wg >> <mailto:servercert-wg@cabforum.org>>
>>> Sent: 05 April 2024 23:47
>>> To: CA/B Forum Server Certificate WG Public Discussion List 
>>> mailto:servercert-wg@cabforum.org>>
>>> Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>>>  
>>> CAUTION: This email originated from outside of the organization. Do not 
>>> click links or open attachments unless you recognize the sender and know 
>>> the content is safe.
>>> 
>>> Two new alternatives have been proposed in addition to the one I proposed 
>>> below:
>>> 
>>> * Aaron Gable commented in the PR with a suggestion that we require CAs to 
>>> reject any key found in Hanno Bock's repository 
>>> athttps://github.com/badkeys/debianopenssl. This includes RSA 
>>> 1024/2048/3072/4096 and EC P256/P384 keys. We might prefer to reference a 
>>> clone in the CAB Forum GitHub org (or some other source of the actual 
>>> generated weak keys) but that's a detail we can work out if others like 
>>> this approach.
>>> * Roman Fischer suggested th

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

[Wayne Thayer via Servercert-wg]

Hi Clint,

I think my latest proposal [1] is essentially what you are proposing in
option #2, the only difference being that we would add repositories
containing weak keys to https://cabforum.org/resources/tools/ (and we can
do that without a ballot). If you are instead proposing that we require CAs
to check for a specified weak keys contained in one or more repositories,
then that is similar to Aaron's proposal except that I understand you want
to require CAs to also check for weak keys even if they sign non-standard
key sizes that are not included in the repository of weak keys.

The more I think about the two approaches, the more I prefer my current
proposal [1] that does not require CAs to check for specific keys found in
one or more repositories. The reason is that I believe CAs already have
Debian weak key checks in place and would likely prefer not to have to
change their systems to use different logic/data to meet the same
requirement as before.

Thanks,

Wayne

[1] https://github.com/wthayer/servercert/pull/1/files



On Tue, Apr 9, 2024 at 2:26 PM Clint Wilson  wrote:

> Hi Wayne,
>
> I think this does seem like it could be a tractable solution, however I’d
> like to understand why one of the proposals I’ve brought up a couple times
> on the calls isn’t also a suitable option. From what I can gather, they’re
> nearly identical in practical impact, but one provides a much more defined
> boundary for relying parties.
>
> Option 1:
> The CA/BF creates or mirrors a repository of pre-computed Debian Weak keys
> for the following key sizes (representing those most commonly issued
> against): RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521. The TBRs
> stipulate that CAs must not issue certificates containing keys in this
> repository.
>
> Option 2:
> The CA/BF creates or mirrors a repository of pre-computed Debian Weak keys
> for the following key sizes (representing those most commonly issued
> against): RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521. The TBRs
> stipulate that CAs must not issue certificates containing weak keys, with a
> pointer to the repository of the most common key sizes of Debian Weak keys
> among other similar/relevant pointers for other vulnerabilities.
>
> The reason these 2 proposals are so nearly identical in practice is that
> there are only a very tiny number of certificates issued against key sizes
> that are not RSA 2048, 3072, 4096, or 8192; or ECC 256, 384, or 521. By
> my count, somewhere around 80 certificates out of roughly 750 million
> (though I really only took a quick glance, so perhaps this is off to an
> extent… but probably not by huge quantities).
>
> Under Option 2, if a CA wants to allow for Certificate requests containing
> a key size other than these 7, they’re fully free to do so; they must
> merely ensure the key is not a Debian Weak key. For every other CA, they
> can limit the accepted key sizes to those in the repository and the result
> is functionally the same as Option 1, but without the possibility of
> “certificates can be issued that are weak and CAs are under no obligation
> to prevent that if it’s not one of 7 key sizes”.
>
> Concretely, is there a reason Option 2 is intractable for CAs? If so, I
> would greatly appreciate help understanding how that approach meaningfully
> differs from Option 1.
>
> Thanks,
> -Clint
>
> On Apr 9, 2024, at 11:43 AM, Rob Stradling via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
> > * Aaron Gable commented in the PR with a suggestion that we require CAs
> to reject any key found in Hanno Bock's repository at
> https://github.com/badkeys/debianopenssl. This includes RSA
> 1024/2048/3072/4096 and EC P256/P384 keys.
>
> Some of the EC key files in Hanno's repository have ASN.1 encoding issues
> (see
> https://www.mail-archive.com/dev-security-policy@mozilla.org/msg00911.html);
> whereas the equivalent files in
> https://github.com/CVE-2008-0166/private_keys are correctly encoded.
>
> > * Roman Fischer suggested that we limit the requirement to check Debian
> weak keys only with sizes up to RSA 4096 under the logic that no one would
> “accidentally” create an 8192 bit RSA key on a system vulnerable to Debian
> Weak keys
>
> FWIW, https://github.com/CVE-2008-0166/private_keys already has all of
> the possible 8192-bit RSA Debian weak keys.
>
> --
> *From:* Servercert-wg  on behalf of
> Wayne Thayer via Servercert-wg 
> *Sent:* 05 April 2024 23:47
> *To:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject:* Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you r

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

[Clint Wilson via Servercert-wg]

Hi Wayne,

I think this does seem like it could be a tractable solution, however I’d like 
to understand why one of the proposals I’ve brought up a couple times on the 
calls isn’t also a suitable option. From what I can gather, they’re nearly 
identical in practical impact, but one provides a much more defined boundary 
for relying parties. 

Option 1:
The CA/BF creates or mirrors a repository of pre-computed Debian Weak keys for 
the following key sizes (representing those most commonly issued against): RSA 
2048, 3072, 4096, 8192; ECC 256, 384, 521. The TBRs stipulate that CAs must not 
issue certificates containing keys in this repository.

Option 2:
The CA/BF creates or mirrors a repository of pre-computed Debian Weak keys for 
the following key sizes (representing those most commonly issued against): RSA 
2048, 3072, 4096, 8192; ECC 256, 384, 521. The TBRs stipulate that CAs must not 
issue certificates containing weak keys, with a pointer to the repository of 
the most common key sizes of Debian Weak keys among other similar/relevant 
pointers for other vulnerabilities.

The reason these 2 proposals are so nearly identical in practice is that there 
are only a very tiny number of certificates issued against key sizes that are 
not RSA 2048, 3072, 4096, or 8192; or ECC 256, 384, or 521. By my count, 
somewhere around 80 certificates out of roughly 750 million (though I really 
only took a quick glance, so perhaps this is off to an extent… but probably not 
by huge quantities).

Under Option 2, if a CA wants to allow for Certificate requests containing a 
key size other than these 7, they’re fully free to do so; they must merely 
ensure the key is not a Debian Weak key. For every other CA, they can limit the 
accepted key sizes to those in the repository and the result is functionally 
the same as Option 1, but without the possibility of “certificates can be 
issued that are weak and CAs are under no obligation to prevent that if it’s 
not one of 7 key sizes”.

Concretely, is there a reason Option 2 is intractable for CAs? If so, I would 
greatly appreciate help understanding how that approach meaningfully differs 
from Option 1.

Thanks,
-Clint

> On Apr 9, 2024, at 11:43 AM, Rob Stradling via Servercert-wg 
>  wrote:
> 
> > * Aaron Gable commented in the PR with a suggestion that we require CAs to 
> > reject any key found in Hanno Bock's repository at 
> > https://github.com/badkeys/debianopenssl. This includes RSA 
> > 1024/2048/3072/4096 and EC P256/P384 keys.
> 
> Some of the EC key files in Hanno's repository have ASN.1 encoding issues 
> (see 
> https://www.mail-archive.com/dev-security-policy@mozilla.org/msg00911.html); 
> whereas the equivalent files inhttps://github.com/CVE-2008-0166/private_keys 
> are correctly encoded.
> 
> > * Roman Fischer suggested that we limit the requirement to check Debian 
> > weak keys only with sizes up to RSA 4096 under the logic that no one would 
> > “accidentally” create an 8192 bit RSA key on a system vulnerable to Debian 
> > Weak keys
> 
> FWIW, https://github.com/CVE-2008-0166/private_keys already has all of the 
> possible 8192-bit RSA Debian weak keys.
> 
> From: Servercert-wg  <mailto:servercert-wg-boun...@cabforum.org>> on behalf of Wayne Thayer via 
> Servercert-wg mailto:servercert-wg@cabforum.org>>
> Sent: 05 April 2024 23:47
> To: CA/B Forum Server Certificate WG Public Discussion List 
> mailto:servercert-wg@cabforum.org>>
> Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>  
> CAUTION: This email originated from outside of the organization. Do not click 
> links or open attachments unless you recognize the sender and know the 
> content is safe.
> 
> Two new alternatives have been proposed in addition to the one I proposed 
> below:
> 
> * Aaron Gable commented in the PR with a suggestion that we require CAs to 
> reject any key found in Hanno Bock's repository 
> athttps://github.com/badkeys/debianopenssl. This includes RSA 
> 1024/2048/3072/4096 and EC P256/P384 keys. We might prefer to reference a 
> clone in the CAB Forum GitHub org (or some other source of the actual 
> generated weak keys) but that's a detail we can work out if others like this 
> approach.
> * Roman Fischer suggested that we limit the requirement to check Debian weak 
> keys only with sizes up to RSA 4096 under the logic that no one would 
> “accidentally” create an 8192 bit RSA key on a system vulnerable to Debian 
> Weak keys
> 
> Each of these methods has the benefit of adding clarity to the Debian 
> requirement rather than just maintaining the existing language, but they also 
> [arguably] allow CAs to issue certs containing abnormally sized Debian weak 
> keys.
> 
> I would like to hear from other members (especially Apple) if you pre

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

[Rob Stradling via Servercert-wg]

> * Aaron Gable commented in the PR with a suggestion that we require CAs to 
> reject any key found in Hanno Bock's repository at 
> https://github.com/badkeys/debianopenssl. This includes RSA 
> 1024/2048/3072/4096 and EC P256/P384 keys.

Some of the EC key files in Hanno's repository have ASN.1 encoding issues (see 
https://www.mail-archive.com/dev-security-policy@mozilla.org/msg00911.html); 
whereas the equivalent files in https://github.com/CVE-2008-0166/private_keys 
are correctly encoded.

> * Roman Fischer suggested that we limit the requirement to check Debian weak 
> keys only with sizes up to RSA 4096 under the logic that no one would 
> “accidentally” create an 8192 bit RSA key on a system vulnerable to Debian 
> Weak keys

FWIW, https://github.com/CVE-2008-0166/private_keys already has all of the 
possible 8192-bit RSA Debian weak keys.


From: Servercert-wg  on behalf of Wayne 
Thayer via Servercert-wg 
Sent: 05 April 2024 23:47
To: CA/B Forum Server Certificate WG Public Discussion List 

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

Two new alternatives have been proposed in addition to the one I proposed below:

* Aaron Gable commented in the PR with a suggestion that we require CAs to 
reject any key found in Hanno Bock's repository at 
https://github.com/badkeys/debianopenssl. This includes RSA 1024/2048/3072/4096 
and EC P256/P384 keys. We might prefer to reference a clone in the CAB Forum 
GitHub org (or some other source of the actual generated weak keys) but that's 
a detail we can work out if others like this approach.
* Roman Fischer suggested that we limit the requirement to check Debian weak 
keys only with sizes up to RSA 4096 under the logic that no one would 
“accidentally” create an 8192 bit RSA key on a system vulnerable to Debian Weak 
keys

Each of these methods has the benefit of adding clarity to the Debian 
requirement rather than just maintaining the existing language, but they also 
[arguably] allow CAs to issue certs containing abnormally sized Debian weak 
keys.

I would like to hear from other members (especially Apple) if you prefer or 
object to either of these alternatives?

Thanks,

Wayne

On Thu, Mar 28, 2024 at 4:13 PM Wayne Thayer via Servercert-wg 
mailto:servercert-wg@cabforum.org>> wrote:
There was further discussion of this ballot proposal on today's teleconference. 
It was suggested that rather than omitting any reference to Debian weak keys, 
the ballot should retain the current language. Unfortunately, the ballot 
restructures the language in such a way that this is challenging. My new 
proposal is that TLS BR Section 6.1.1.3(5) be updated to read as follows 
(https://github.com/wthayer/servercert/pull/1/files):
=
5. The Public Key corresponds to an industry-demonstrated weak Private Key. For 
requests submitted on or after November 15, 2024, at least the following 
precautions SHALL be implemented:
1. The CA SHALL reject Debian weak keys (https://wiki.debian.org/SSLkeys).
2. In the case of ROCA vulnerability, the CA SHALL reject keys identified 
by the tools available at https://github.com/crocs-muni/roca or equivalent.
3. In the case of Close Primes vulnerability 
(https://fermatattack.secvuln.info/), the CA SHALL reject weak keys which can 
be factored within 100 rounds using Fermat’s factorization method.

Suggested tools for checking for weak keys can be found here: 
https://cabforum.org/resources/tools/
=
I would greatly appreciate feedback from any member that finds this language 
unacceptable, or that has suggestions to improve it.

Thanks,

Wayne


On Fri, Mar 15, 2024 at 11:19 AM Wayne Thayer via Servercert-wg 
mailto:servercert-wg@cabforum.org>> wrote:
On yesterday's SCWG teleconference, Mads suggested that a way forward would be 
to leave the existing requirements in place for Debian weak keys. I've 
interpreted that to mean that we would just remove references to Debian, 
resulting in this: https://github.com/wthayer/servercert/pull/1/files

I'm not satisfied by this approach because it doesn't achieve the clarity 
intended to result from the original weak keys ballot and will seemingly result 
in CAs continuing to have varying interpretations of the specific requirements 
for rejecting Debian weak keys, but perhaps this is the best we can all agree 
to.

What  do others think? Should we proceed with this approach?

Thanks,

Wayne

On Sat, Mar 9, 2024 at 9:15 AM Dimitris Zacharopoulos (HARICA) via 
Servercert-wg mailto:servercert-wg@cabforum.org>> 
wrote:
FWIW, I think in the recent years, it was mostly security researchers that 
attempted to request certificates with Debian weak keys to test if a CA was 
properly blocking them.

If an Applicant us

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

[Wayne Thayer via Servercert-wg]

Two new alternatives have been proposed in addition to the one I proposed
below:

* Aaron Gable commented in the PR with a suggestion that we require CAs to
reject any key found in Hanno Bock's repository at
https://github.com/badkeys/debianopenssl. This includes RSA
1024/2048/3072/4096 and EC P256/P384 keys. We might prefer to reference a
clone in the CAB Forum GitHub org (or some other source of the actual
generated weak keys) but that's a detail we can work out if others like
this approach.
* Roman Fischer suggested that we limit the requirement to check Debian
weak keys only with sizes up to RSA 4096 under the logic that no one
would “accidentally”
create an 8192 bit RSA key on a system vulnerable to Debian Weak keys

Each of these methods has the benefit of adding clarity to the Debian
requirement rather than just maintaining the existing language, but they
also [arguably] allow CAs to issue certs containing abnormally sized Debian
weak keys.

I would like to hear from other members (especially Apple) if you prefer or
object to either of these alternatives?

Thanks,

Wayne

On Thu, Mar 28, 2024 at 4:13 PM Wayne Thayer via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> There was further discussion of this ballot proposal on today's
> teleconference. It was suggested that rather than omitting any reference to
> Debian weak keys, the ballot should retain the current language.
> Unfortunately, the ballot restructures the language in such a way that this
> is challenging. My new proposal is that TLS BR Section 6.1.1.3(5) be
> updated to read as follows (
> https://github.com/wthayer/servercert/pull/1/files):
> =
> 5. The Public Key corresponds to an industry-demonstrated weak Private
> Key. For requests submitted on or after November 15, 2024, at least the
> following precautions SHALL be implemented:
> 1. The CA SHALL reject Debian weak keys (
> https://wiki.debian.org/SSLkeys).
> 2. In the case of ROCA vulnerability, the CA SHALL reject keys
> identified by the tools available at https://github.com/crocs-muni/roca
> or equivalent.
> 3. In the case of Close Primes vulnerability (
> https://fermatattack.secvuln.info/), the CA SHALL reject weak keys which
> can be factored within 100 rounds using Fermat’s factorization method.
>
> Suggested tools for checking for weak keys can be found here:
> https://cabforum.org/resources/tools/
> =
> I would greatly appreciate feedback from any member that finds this
> language unacceptable, or that has suggestions to improve it.
>
> Thanks,
>
> Wayne
>
>
> On Fri, Mar 15, 2024 at 11:19 AM Wayne Thayer via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
>> On yesterday's SCWG teleconference, Mads suggested that a way forward
>> would be to leave the existing requirements in place for Debian weak keys.
>> I've interpreted that to mean that we would just remove references to
>> Debian, resulting in this:
>> https://github.com/wthayer/servercert/pull/1/files
>>
>> I'm not satisfied by this approach because it doesn't achieve the clarity
>> intended to result from the original weak keys ballot and will seemingly
>> result in CAs continuing to have varying interpretations of the specific
>> requirements for rejecting Debian weak keys, but perhaps this is the best
>> we can all agree to.
>>
>> What  do others think? Should we proceed with this approach?
>>
>> Thanks,
>>
>> Wayne
>>
>> On Sat, Mar 9, 2024 at 9:15 AM Dimitris Zacharopoulos (HARICA) via
>> Servercert-wg  wrote:
>>
>>> FWIW, I think in the recent years, it was mostly security researchers
>>> that attempted to request certificates with Debian weak keys to test if a
>>> CA was properly blocking them.
>>>
>>> If an Applicant uses an outdated OS that generates weak keys, imagine
>>> the actual web server or other software that runs on that server, putting
>>> Relying Parties at risk. CAs don't have control over that but they could
>>> have control over a common set of weak keys using common
>>> parameters/algorithms which could be enforced by all CAs.
>>>
>>> Dimitris.
>>>
>>> On 9/3/2024 12:05 π.μ., Wayne Thayer via Servercert-wg wrote:
>>>
>>> Hi Clint,
>>>
>>> Thank you for your response. Unfortunately, it leads me to the
>>> conclusion that there is not a path forward and we're stuck with the status
>>> quo. Having said that, I'll reply to a few of your points below and
>>> encourage others to do the same if there is a desire to move forward with
>>> an update to our weak keys requirements.
>>>
>>> On Thu, Mar 7, 2024 at 12:59 AM Clint Wilson  wrote:
>>>
 Hi Wayne,

 Thank you for carrying this work item forward. I have a few concerns
 regarding the proposed removal of Debian weak key checking, outlined below.

 I don’t believe there has been sufficient explanation or data presented
 to justify the removal of the requirement to check for Debian weak keys. It
 seems to me there are feasible methods for CAs to continue performing this
 check. 

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

[Roman Fischer via Servercert-wg]

Could we limit the Debian Weak keys to key sizes up to RSA 4096 bit? I don’t 
think that anybody “accidentally” creates an 8192 bit RSA key on a system 
vulnerable to Debian Weak keys.

Kind regards
Roman

PS: Can somebody explain, why we only test close primes with 100 rounds and not 
e.g. 1000? 


From: Servercert-wg  On Behalf Of Wayne 
Thayer via Servercert-wg
Sent: Freitag, 29. März 2024 00:14
To: CA/B Forum Server Certificate WG Public Discussion List 

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

There was further discussion of this ballot proposal on today's teleconference. 
It was suggested that rather than omitting any reference to Debian weak keys, 
the ballot should retain the current language. Unfortunately, the ballot 
restructures the language in such a way that this is challenging. My new 
proposal is that TLS BR Section 6.1.1.3(5) be updated to read as follows 
(https://github.com/wthayer/servercert/pull/1/files):
=
5. The Public Key corresponds to an industry-demonstrated weak Private Key. For 
requests submitted on or after November 15, 2024, at least the following 
precautions SHALL be implemented:
1. The CA SHALL reject Debian weak keys (https://wiki.debian.org/SSLkeys).
2. In the case of ROCA vulnerability, the CA SHALL reject keys identified 
by the tools available at https://github.com/crocs-muni/roca or equivalent.
3. In the case of Close Primes vulnerability 
(https://fermatattack.secvuln.info/), the CA SHALL reject weak keys which can 
be factored within 100 rounds using Fermat’s factorization method.

Suggested tools for checking for weak keys can be found here: 
https://cabforum.org/resources/tools/
=
I would greatly appreciate feedback from any member that finds this language 
unacceptable, or that has suggestions to improve it.

Thanks,

Wayne


On Fri, Mar 15, 2024 at 11:19 AM Wayne Thayer via Servercert-wg 
mailto:servercert-wg@cabforum.org>> wrote:
On yesterday's SCWG teleconference, Mads suggested that a way forward would be 
to leave the existing requirements in place for Debian weak keys. I've 
interpreted that to mean that we would just remove references to Debian, 
resulting in this: https://github.com/wthayer/servercert/pull/1/files

I'm not satisfied by this approach because it doesn't achieve the clarity 
intended to result from the original weak keys ballot and will seemingly result 
in CAs continuing to have varying interpretations of the specific requirements 
for rejecting Debian weak keys, but perhaps this is the best we can all agree 
to.

What  do others think? Should we proceed with this approach?

Thanks,

Wayne

On Sat, Mar 9, 2024 at 9:15 AM Dimitris Zacharopoulos (HARICA) via 
Servercert-wg mailto:servercert-wg@cabforum.org>> 
wrote:
FWIW, I think in the recent years, it was mostly security researchers that 
attempted to request certificates with Debian weak keys to test if a CA was 
properly blocking them.

If an Applicant uses an outdated OS that generates weak keys, imagine the 
actual web server or other software that runs on that server, putting Relying 
Parties at risk. CAs don't have control over that but they could have control 
over a common set of weak keys using common parameters/algorithms which could 
be enforced by all CAs.

Dimitris.
On 9/3/2024 12:05 π.μ., Wayne Thayer via Servercert-wg wrote:
Hi Clint,

Thank you for your response. Unfortunately, it leads me to the conclusion that 
there is not a path forward and we're stuck with the status quo. Having said 
that, I'll reply to a few of your points below and encourage others to do the 
same if there is a desire to move forward with an update to our weak keys 
requirements.

On Thu, Mar 7, 2024 at 12:59 AM Clint Wilson 
mailto:cli...@apple.com>> wrote:
Hi Wayne,

Thank you for carrying this work item forward. I have a few concerns regarding 
the proposed removal of Debian weak key checking, outlined below.

I don’t believe there has been sufficient explanation or data presented to 
justify the removal of the requirement to check for Debian weak keys. It seems 
to me there are feasible methods for CAs to continue performing this check. 
Similar to what Martijn has pointed out, the reasoning provided is lacking 
(hasty generalization, fallacy of composition, etc.).

The argument that I find compelling is that any system capable of generating a 
Debian weak key in 2024 is also riddled with a decade of vulnerabilities, so 
preventing the use of said weak key in a certificate is security theater. In 
what scenario do you envision the rejection of a Debian weak key having a 
meaningful impact on the security of a service that relies on it? It's just not 
obvious to me that these checks continue to provide any practical value at this 
point in time.

I don’t believe a compromise where Debian weak keys only need be checked for 
specific key sizes addresses the core issue, unless tied together with a 
restriction from accepti

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

[Wayne Thayer via Servercert-wg]

There was further discussion of this ballot proposal on today's
teleconference. It was suggested that rather than omitting any reference to
Debian weak keys, the ballot should retain the current language.
Unfortunately, the ballot restructures the language in such a way that this
is challenging. My new proposal is that TLS BR Section 6.1.1.3(5) be
updated to read as follows (
https://github.com/wthayer/servercert/pull/1/files):
=
5. The Public Key corresponds to an industry-demonstrated weak Private Key.
For requests submitted on or after November 15, 2024, at least the
following precautions SHALL be implemented:
1. The CA SHALL reject Debian weak keys (https://wiki.debian.org/SSLkeys
).
2. In the case of ROCA vulnerability, the CA SHALL reject keys
identified by the tools available at https://github.com/crocs-muni/roca or
equivalent.
3. In the case of Close Primes vulnerability (
https://fermatattack.secvuln.info/), the CA SHALL reject weak keys which
can be factored within 100 rounds using Fermat’s factorization method.

Suggested tools for checking for weak keys can be found here:
https://cabforum.org/resources/tools/
=
I would greatly appreciate feedback from any member that finds this
language unacceptable, or that has suggestions to improve it.

Thanks,

Wayne


On Fri, Mar 15, 2024 at 11:19 AM Wayne Thayer via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> On yesterday's SCWG teleconference, Mads suggested that a way forward
> would be to leave the existing requirements in place for Debian weak keys.
> I've interpreted that to mean that we would just remove references to
> Debian, resulting in this:
> https://github.com/wthayer/servercert/pull/1/files
>
> I'm not satisfied by this approach because it doesn't achieve the clarity
> intended to result from the original weak keys ballot and will seemingly
> result in CAs continuing to have varying interpretations of the specific
> requirements for rejecting Debian weak keys, but perhaps this is the best
> we can all agree to.
>
> What  do others think? Should we proceed with this approach?
>
> Thanks,
>
> Wayne
>
> On Sat, Mar 9, 2024 at 9:15 AM Dimitris Zacharopoulos (HARICA) via
> Servercert-wg  wrote:
>
>> FWIW, I think in the recent years, it was mostly security researchers
>> that attempted to request certificates with Debian weak keys to test if a
>> CA was properly blocking them.
>>
>> If an Applicant uses an outdated OS that generates weak keys, imagine the
>> actual web server or other software that runs on that server, putting
>> Relying Parties at risk. CAs don't have control over that but they could
>> have control over a common set of weak keys using common
>> parameters/algorithms which could be enforced by all CAs.
>>
>> Dimitris.
>>
>> On 9/3/2024 12:05 π.μ., Wayne Thayer via Servercert-wg wrote:
>>
>> Hi Clint,
>>
>> Thank you for your response. Unfortunately, it leads me to the conclusion
>> that there is not a path forward and we're stuck with the status quo.
>> Having said that, I'll reply to a few of your points below and encourage
>> others to do the same if there is a desire to move forward with an update
>> to our weak keys requirements.
>>
>> On Thu, Mar 7, 2024 at 12:59 AM Clint Wilson  wrote:
>>
>>> Hi Wayne,
>>>
>>> Thank you for carrying this work item forward. I have a few concerns
>>> regarding the proposed removal of Debian weak key checking, outlined below.
>>>
>>> I don’t believe there has been sufficient explanation or data presented
>>> to justify the removal of the requirement to check for Debian weak keys. It
>>> seems to me there are feasible methods for CAs to continue performing this
>>> check. Similar to what Martijn has pointed out, the reasoning provided is
>>> lacking (hasty generalization, fallacy of composition, etc.).
>>>
>>
>> The argument that I find compelling is that any system capable of
>> generating a Debian weak key in 2024 is also riddled with a decade of
>> vulnerabilities, so preventing the use of said weak key in a certificate is
>> security theater. In what scenario do you envision the rejection of a
>> Debian weak key having a meaningful impact on the security of a service
>> that relies on it? It's just not obvious to me that these checks continue
>> to provide any practical value at this point in time.
>>
>>
>>> I don’t believe a compromise where Debian weak keys only need be checked
>>> for specific key sizes addresses the core issue, unless tied together with
>>> a restriction from accepting key sizes which are not included in such a
>>> list (which I do see as reasonable and something I’m under the impression
>>> is already being done by some CAs).
>>>
>>
>> My understanding is that the objections some CAs had to the original
>> ballot was the requirement to maintain a sizable database of Debian weak
>> keys for every key size they support. Limiting the requirement to the most
>> popular key sizes would resolve that issue and be more inline with my
>> 

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

[Mads Egil Henriksveen via Servercert-wg]

Hi

My main concern has been that CAs are required to include additional controls, 
including generating possible weak Debian keys for supported key sizes or limit 
the supported key sizes due to a (more or less) theoretical threat of Debian 
keys from an OS that presumably should not be in use since many years ago.

I understand that Debian weak keys are still an issue, that’s why I suggested 
to keep the existing wording regarding Debian weak keys in BR (section 6.1.1.3) 
as is, e.g. ‘…the CA SHALL reject Debian weak keys (see 
https://wiki.debian.org/SSLkeys)...’ or similar. This has been the wording 
since the first version of BR in 2011, and I hope this still suffice. If this 
is not the case, it would be great to get some more information about what 
problem we try to solve by adding more specific controls for Debian keys now 
(more than 15 years after the vulnerability was identified).

Regards
Mads

From: Servercert-wg  On Behalf Of Roman 
Fischer via Servercert-wg
Sent: Monday, March 25, 2024 9:06 AM
To: CA/B Forum Server Certificate WG Public Discussion List 

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

I would propose a pragmatic approach: Limit the Debian weak keys to be 
considered/rejected by CAs to an upper bound (e.g. 4096 or 8192 bits) assuming 
that any weak key above that has been intentionally manufactured by a security 
researcher.

-Roman

From: Servercert-wg 
mailto:servercert-wg-boun...@cabforum.org>> 
On Behalf Of Wayne Thayer via Servercert-wg
Sent: Freitag, 15. März 2024 19:20
To: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org>>
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

On yesterday's SCWG teleconference, Mads suggested that a way forward would be 
to leave the existing requirements in place for Debian weak keys. I've 
interpreted that to mean that we would just remove references to Debian, 
resulting in this: https://github.com/wthayer/servercert/pull/1/files

I'm not satisfied by this approach because it doesn't achieve the clarity 
intended to result from the original weak keys ballot and will seemingly result 
in CAs continuing to have varying interpretations of the specific requirements 
for rejecting Debian weak keys, but perhaps this is the best we can all agree 
to.

What  do others think? Should we proceed with this approach?

Thanks,

Wayne

On Sat, Mar 9, 2024 at 9:15 AM Dimitris Zacharopoulos (HARICA) via 
Servercert-wg mailto:servercert-wg@cabforum.org>> 
wrote:
FWIW, I think in the recent years, it was mostly security researchers that 
attempted to request certificates with Debian weak keys to test if a CA was 
properly blocking them.

If an Applicant uses an outdated OS that generates weak keys, imagine the 
actual web server or other software that runs on that server, putting Relying 
Parties at risk. CAs don't have control over that but they could have control 
over a common set of weak keys using common parameters/algorithms which could 
be enforced by all CAs.

Dimitris.
On 9/3/2024 12:05 π.μ., Wayne Thayer via Servercert-wg wrote:
Hi Clint,

Thank you for your response. Unfortunately, it leads me to the conclusion that 
there is not a path forward and we're stuck with the status quo. Having said 
that, I'll reply to a few of your points below and encourage others to do the 
same if there is a desire to move forward with an update to our weak keys 
requirements.

On Thu, Mar 7, 2024 at 12:59 AM Clint Wilson 
mailto:cli...@apple.com>> wrote:
Hi Wayne,

Thank you for carrying this work item forward. I have a few concerns regarding 
the proposed removal of Debian weak key checking, outlined below.

I don’t believe there has been sufficient explanation or data presented to 
justify the removal of the requirement to check for Debian weak keys. It seems 
to me there are feasible methods for CAs to continue performing this check. 
Similar to what Martijn has pointed out, the reasoning provided is lacking 
(hasty generalization, fallacy of composition, etc.).

The argument that I find compelling is that any system capable of generating a 
Debian weak key in 2024 is also riddled with a decade of vulnerabilities, so 
preventing the use of said weak key in a certificate is security theater. In 
what scenario do you envision the rejection of a Debian weak key having a 
meaningful impact on the security of a service that relies on it? It's just not 
obvious to me that these checks continue to provide any practical value at this 
point in time.

I don’t believe a compromise where Debian weak keys only need be checked for 
specific key sizes addresses the core issue, unless tied together with a 
restriction from accepting key sizes which are not included in such a list 
(which I do see as reasonable and something I’m under the impression is already 
being done by some CAs).

My understanding is that the objections some CAs had to the original ballot was 
the

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

[Roman Fischer via Servercert-wg]

I would propose a pragmatic approach: Limit the Debian weak keys to be 
considered/rejected by CAs to an upper bound (e.g. 4096 or 8192 bits) assuming 
that any weak key above that has been intentionally manufactured by a security 
researcher.

-Roman

From: Servercert-wg  On Behalf Of Wayne 
Thayer via Servercert-wg
Sent: Freitag, 15. März 2024 19:20
To: CA/B Forum Server Certificate WG Public Discussion List 

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

On yesterday's SCWG teleconference, Mads suggested that a way forward would be 
to leave the existing requirements in place for Debian weak keys. I've 
interpreted that to mean that we would just remove references to Debian, 
resulting in this: https://github.com/wthayer/servercert/pull/1/files

I'm not satisfied by this approach because it doesn't achieve the clarity 
intended to result from the original weak keys ballot and will seemingly result 
in CAs continuing to have varying interpretations of the specific requirements 
for rejecting Debian weak keys, but perhaps this is the best we can all agree 
to.

What  do others think? Should we proceed with this approach?

Thanks,

Wayne

On Sat, Mar 9, 2024 at 9:15 AM Dimitris Zacharopoulos (HARICA) via 
Servercert-wg mailto:servercert-wg@cabforum.org>> 
wrote:
FWIW, I think in the recent years, it was mostly security researchers that 
attempted to request certificates with Debian weak keys to test if a CA was 
properly blocking them.

If an Applicant uses an outdated OS that generates weak keys, imagine the 
actual web server or other software that runs on that server, putting Relying 
Parties at risk. CAs don't have control over that but they could have control 
over a common set of weak keys using common parameters/algorithms which could 
be enforced by all CAs.

Dimitris.
On 9/3/2024 12:05 π.μ., Wayne Thayer via Servercert-wg wrote:
Hi Clint,

Thank you for your response. Unfortunately, it leads me to the conclusion that 
there is not a path forward and we're stuck with the status quo. Having said 
that, I'll reply to a few of your points below and encourage others to do the 
same if there is a desire to move forward with an update to our weak keys 
requirements.

On Thu, Mar 7, 2024 at 12:59 AM Clint Wilson 
mailto:cli...@apple.com>> wrote:
Hi Wayne,

Thank you for carrying this work item forward. I have a few concerns regarding 
the proposed removal of Debian weak key checking, outlined below.

I don’t believe there has been sufficient explanation or data presented to 
justify the removal of the requirement to check for Debian weak keys. It seems 
to me there are feasible methods for CAs to continue performing this check. 
Similar to what Martijn has pointed out, the reasoning provided is lacking 
(hasty generalization, fallacy of composition, etc.).

The argument that I find compelling is that any system capable of generating a 
Debian weak key in 2024 is also riddled with a decade of vulnerabilities, so 
preventing the use of said weak key in a certificate is security theater. In 
what scenario do you envision the rejection of a Debian weak key having a 
meaningful impact on the security of a service that relies on it? It's just not 
obvious to me that these checks continue to provide any practical value at this 
point in time.

I don’t believe a compromise where Debian weak keys only need be checked for 
specific key sizes addresses the core issue, unless tied together with a 
restriction from accepting key sizes which are not included in such a list 
(which I do see as reasonable and something I’m under the impression is already 
being done by some CAs).

My understanding is that the objections some CAs had to the original ballot was 
the requirement to maintain a sizable database of Debian weak keys for every 
key size they support. Limiting the requirement to the most popular key sizes 
would resolve that issue and be more inline with my understanding of some 
current practices. This approach would also greatly reduce the threat of the 
accidental use of a Debian weak key.

The removal of this check seems to shift a burden currently placed on CAs to a 
risk (long assumed resolved) for Relying Parties and Subscribers. From my 
reading of the ballot, the requirement that a CA revoke Certificates with 
Debian weak keys remains in effect, serving only to remove the pre-issuance 
“blocking” requirement, but retaining an expectation that certificates are 
checked post-issuance based on the CA’s awareness of this method of 
compromising a Private Key; this generally seems a significantly worse 
experience for Subscribers. Have I missed something regarding the intent of the 
changes in this regard?

This is a great point. It makes no sense to allow a CA to issue a cert that is 
then immediately subject to a revocation requirement. I am open to either 
exempting Debian weak keys from BR 4.9.1.1(4) or for CAs to be required to 
revoke a certificate containing a Deb

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

[Wayne Thayer via Servercert-wg]

On yesterday's SCWG teleconference, Mads suggested that a way forward would
be to leave the existing requirements in place for Debian weak keys. I've
interpreted that to mean that we would just remove references to Debian,
resulting in this: https://github.com/wthayer/servercert/pull/1/files

I'm not satisfied by this approach because it doesn't achieve the clarity
intended to result from the original weak keys ballot and will seemingly
result in CAs continuing to have varying interpretations of the specific
requirements for rejecting Debian weak keys, but perhaps this is the best
we can all agree to.

What  do others think? Should we proceed with this approach?

Thanks,

Wayne

On Sat, Mar 9, 2024 at 9:15 AM Dimitris Zacharopoulos (HARICA) via
Servercert-wg  wrote:

> FWIW, I think in the recent years, it was mostly security researchers that
> attempted to request certificates with Debian weak keys to test if a CA was
> properly blocking them.
>
> If an Applicant uses an outdated OS that generates weak keys, imagine the
> actual web server or other software that runs on that server, putting
> Relying Parties at risk. CAs don't have control over that but they could
> have control over a common set of weak keys using common
> parameters/algorithms which could be enforced by all CAs.
>
> Dimitris.
>
> On 9/3/2024 12:05 π.μ., Wayne Thayer via Servercert-wg wrote:
>
> Hi Clint,
>
> Thank you for your response. Unfortunately, it leads me to the conclusion
> that there is not a path forward and we're stuck with the status quo.
> Having said that, I'll reply to a few of your points below and encourage
> others to do the same if there is a desire to move forward with an update
> to our weak keys requirements.
>
> On Thu, Mar 7, 2024 at 12:59 AM Clint Wilson  wrote:
>
>> Hi Wayne,
>>
>> Thank you for carrying this work item forward. I have a few concerns
>> regarding the proposed removal of Debian weak key checking, outlined below.
>>
>> I don’t believe there has been sufficient explanation or data presented
>> to justify the removal of the requirement to check for Debian weak keys. It
>> seems to me there are feasible methods for CAs to continue performing this
>> check. Similar to what Martijn has pointed out, the reasoning provided is
>> lacking (hasty generalization, fallacy of composition, etc.).
>>
>
> The argument that I find compelling is that any system capable of
> generating a Debian weak key in 2024 is also riddled with a decade of
> vulnerabilities, so preventing the use of said weak key in a certificate is
> security theater. In what scenario do you envision the rejection of a
> Debian weak key having a meaningful impact on the security of a service
> that relies on it? It's just not obvious to me that these checks continue
> to provide any practical value at this point in time.
>
>
>> I don’t believe a compromise where Debian weak keys only need be checked
>> for specific key sizes addresses the core issue, unless tied together with
>> a restriction from accepting key sizes which are not included in such a
>> list (which I do see as reasonable and something I’m under the impression
>> is already being done by some CAs).
>>
>
> My understanding is that the objections some CAs had to the original
> ballot was the requirement to maintain a sizable database of Debian weak
> keys for every key size they support. Limiting the requirement to the most
> popular key sizes would resolve that issue and be more inline with my
> understanding of some current practices. This approach would also greatly
> reduce the threat of the accidental use of a Debian weak key.
>
>
>> The removal of this check seems to shift a burden currently placed on CAs
>> to a risk (long assumed resolved) for Relying Parties and Subscribers. From
>> my reading of the ballot, the requirement that a CA revoke Certificates
>> with Debian weak keys remains in effect, serving only to remove the
>> pre-issuance “blocking” requirement, but retaining an expectation that
>> certificates are checked post-issuance based on the CA’s awareness of this
>> method of compromising a Private Key; this generally seems a significantly
>> worse experience for Subscribers. Have I missed something regarding the
>> intent of the changes in this regard?
>>
>
> This is a great point. It makes no sense to allow a CA to issue a cert
> that is then immediately subject to a revocation requirement. I am open to
> either exempting Debian weak keys from BR 4.9.1.1(4) or for CAs to be
> required to revoke a certificate containing a Debian weak key only if they
> are "made aware" using the mechanism specified in 4.9.3.
>
> Thanks,
>
> Wayne
>
>
>> There have been incidents involving certificates issued to Debian weak
>> keys in recent years; some CAs have indicated that they don’t receive
>> Debian weak keys in requests, but evidence exists to the contrary for the
>> ecosystem as a whole.
>>
>> Thank you!
>> -Clint
>>
>>
> ___
> 

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

[Dimitris Zacharopoulos (HARICA) via Servercert-wg]

FWIW, I think in the recent years, it was mostly security researchers 
that attempted to request certificates with Debian weak keys to test if 
a CA was properly blocking them.


If an Applicant uses an outdated OS that generates weak keys, imagine 
the actual web server or other software that runs on that server, 
putting Relying Parties at risk. CAs don't have control over that but 
they could have control over a common set of weak keys using common 
parameters/algorithms which could be enforced by all CAs.


Dimitris.

On 9/3/2024 12:05 π.μ., Wayne Thayer via Servercert-wg wrote:

Hi Clint,

Thank you for your response. Unfortunately, it leads me to the 
conclusion that there is not a path forward and we're stuck with the 
status quo. Having said that, I'll reply to a few of your points below 
and encourage others to do the same if there is a desire to move 
forward with an update to our weak keys requirements.


On Thu, Mar 7, 2024 at 12:59 AM Clint Wilson  wrote:

Hi Wayne,

Thank you for carrying this work item forward. I have a few
concerns regarding the proposed removal of Debian weak key
checking, outlined below.

I don’t believe there has been sufficient explanation or data
presented to justify the removal of the requirement to check for
Debian weak keys. It seems to me there are feasible methods for
CAs to continue performing this check. Similar to what Martijn has
pointed out, the reasoning provided is lacking (hasty
generalization, fallacy of composition, etc.).


The argument that I find compelling is that any system capable of 
generating a Debian weak key in 2024 is also riddled with a decade of 
vulnerabilities, so preventing the use of said weak key in a 
certificate is security theater. In what scenario do you envision the 
rejection of a Debian weak key having a meaningful impact on the 
security of a service that relies on it? It's just not obvious to me 
that these checks continue to provide any practical value at this 
point in time.


I don’t believe a compromise where Debian weak keys only need be
checked for specific key sizes addresses the core issue, unless
tied together with a restriction from accepting key sizes which
are not included in such a list (which I do see as reasonable and
something I’m under the impression is already being done by some CAs).


My understanding is that the objections some CAs had to the original 
ballot was the requirement to maintain a sizable database of Debian 
weak keys for every key size they support. Limiting the requirement to 
the most popular key sizes would resolve that issue and be more inline 
with my understanding of some current practices. This approach would 
also greatly reduce the threat of the accidental use of a Debian weak key.


The removal of this check seems to shift a burden currently placed
on CAs to a risk (long assumed resolved) for Relying Parties and
Subscribers. From my reading of the ballot, the requirement that a
CA revoke Certificates with Debian weak keys remains in effect,
serving only to remove the pre-issuance “blocking” requirement,
but retaining an expectation that certificates are checked
post-issuance based on the CA’s awareness of this method of
compromising a Private Key; this generally seems a significantly
worse experience for Subscribers. Have I missed something
regarding the intent of the changes in this regard?


This is a great point. It makes no sense to allow a CA to issue a cert 
that is then immediately subject to a revocation requirement. I am 
open to either exempting Debian weak keys from BR 4.9.1.1(4) or for 
CAs to be required to revoke a certificate containing a Debian weak 
key only if they are "made aware" using the mechanism specified in 4.9.3.


Thanks,

Wayne


There have been incidents involving certificates issued to Debian
weak keys in recent years; some CAs have indicated that they don’t
receive Debian weak keys in requests, but evidence exists to the
contrary for the ecosystem as a whole.

Thank you!
-Clint


___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg
___
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]

Hi Clint,

Thank you for your response. Unfortunately, it leads me to the conclusion
that there is not a path forward and we're stuck with the status quo.
Having said that, I'll reply to a few of your points below and encourage
others to do the same if there is a desire to move forward with an update
to our weak keys requirements.

On Thu, Mar 7, 2024 at 12:59 AM Clint Wilson  wrote:

> Hi Wayne,
>
> Thank you for carrying this work item forward. I have a few concerns
> regarding the proposed removal of Debian weak key checking, outlined below.
>
> I don’t believe there has been sufficient explanation or data presented to
> justify the removal of the requirement to check for Debian weak keys. It
> seems to me there are feasible methods for CAs to continue performing this
> check. Similar to what Martijn has pointed out, the reasoning provided is
> lacking (hasty generalization, fallacy of composition, etc.).
>

The argument that I find compelling is that any system capable of
generating a Debian weak key in 2024 is also riddled with a decade of
vulnerabilities, so preventing the use of said weak key in a certificate is
security theater. In what scenario do you envision the rejection of a
Debian weak key having a meaningful impact on the security of a service
that relies on it? It's just not obvious to me that these checks continue
to provide any practical value at this point in time.


> I don’t believe a compromise where Debian weak keys only need be checked
> for specific key sizes addresses the core issue, unless tied together with
> a restriction from accepting key sizes which are not included in such a
> list (which I do see as reasonable and something I’m under the impression
> is already being done by some CAs).
>

My understanding is that the objections some CAs had to the original ballot
was the requirement to maintain a sizable database of Debian weak keys for
every key size they support. Limiting the requirement to the most popular
key sizes would resolve that issue and be more inline with my understanding
of some current practices. This approach would also greatly reduce the
threat of the accidental use of a Debian weak key.


> The removal of this check seems to shift a burden currently placed on CAs
> to a risk (long assumed resolved) for Relying Parties and Subscribers. From
> my reading of the ballot, the requirement that a CA revoke Certificates
> with Debian weak keys remains in effect, serving only to remove the
> pre-issuance “blocking” requirement, but retaining an expectation that
> certificates are checked post-issuance based on the CA’s awareness of this
> method of compromising a Private Key; this generally seems a significantly
> worse experience for Subscribers. Have I missed something regarding the
> intent of the changes in this regard?
>

This is a great point. It makes no sense to allow a CA to issue a cert that
is then immediately subject to a revocation requirement. I am open to
either exempting Debian weak keys from BR 4.9.1.1(4) or for CAs to be
required to revoke a certificate containing a Debian weak key only if they
are "made aware" using the mechanism specified in 4.9.3.

Thanks,

Wayne


> There have been incidents involving certificates issued to Debian weak
> keys in recent years; some CAs have indicated that they don’t receive
> Debian weak keys in requests, but evidence exists to the contrary for the
> ecosystem as a whole.
>
> Thank you!
> -Clint
>
>
___
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,

Thank you for carrying this work item forward. I have a few concerns regarding 
the proposed removal of Debian weak key checking, outlined below.

I don’t believe there has been sufficient explanation or data presented to 
justify the removal of the requirement to check for Debian weak keys. It seems 
to me there are feasible methods for CAs to continue performing this check. 
Similar to what Martijn has pointed out, the reasoning provided is lacking 
(hasty generalization, fallacy of composition, etc.). 

I don’t believe a compromise where Debian weak keys only need be checked for 
specific key sizes addresses the core issue, unless tied together with a 
restriction from accepting key sizes which are not included in such a list 
(which I do see as reasonable and something I’m under the impression is already 
being done by some CAs).

The removal of this check seems to shift a burden currently placed on CAs to a 
risk (long assumed resolved) for Relying Parties and Subscribers. From my 
reading of the ballot, the requirement that a CA revoke Certificates with 
Debian weak keys remains in effect, serving only to remove the pre-issuance 
“blocking” requirement, but retaining an expectation that certificates are 
checked post-issuance based on the CA’s awareness of this method of 
compromising a Private Key; this generally seems a significantly worse 
experience for Subscribers. Have I missed something regarding the intent of the 
changes in this regard?

There have been incidents involving certificates issued to Debian weak keys in 
recent years; some CAs have indicated that they don’t receive Debian weak keys 
in requests, but evidence exists to the contrary for the ecosystem as a whole.

Thank you!
-Clint

> On Mar 5, 2024, at 12:01 PM, Wayne Thayer via Servercert-wg 
>  wrote:
> 
> Now that everyone should be back from the F2F meeting, I'd like to get back 
> to this ballot. It currently removes all requirements for Debian weak key 
> checks. I'll plan to begin the formal discussion period in a few days unless 
> there are more responses to this thread.
> 
> Thanks,
> 
> Wayne
> 
> On Mon, Feb 26, 2024 at 1:24 PM Wayne Thayer via Servercert-wg 
> mailto:servercert-wg@cabforum.org>> wrote:
>> Martijn,
>> 
>> The purpose of the first weak keys ballot was to make the requirements more 
>> explicit. If I correctly understand your proposal, by removing the exception 
>> for Debian keys from this ballot, it does the opposite. The only compromise 
>> I can see is to require checking for Debian weak keys but only for specific 
>> key sizes, e.g. 2048, 3072, and 4096. That would somewhat reduce the burden 
>> of these checks, and I'd be happy to go that route if there is consensus for 
>> doing so (with approval of the endorsers, of course). I would appreciate 
>> input from other members on the preferred approach to Debian weak key 
>> checking requirements.
>> 
>> Thanks,
>> 
>> Wayne
>> 
>> On Sun, Feb 25, 2024 at 12:15 AM Martijn Katerbarg 
>> mailto:martijn.katerb...@sectigo.com>> wrote:
>>> Thanks Wayne,
>>> 
>>>  
>>> 
>>> >- The Debian vulnerability is more than 15 years old. If an Applicant 
>>> >submits a Debian weak key at this point, they almost certainly have bigger 
>>> >security issues.
>>> 
>>>  
>>> 
>>> This is the bit I have problems with. Just because the applicant (probably) 
>>> has bigger security issues, doesn’t mean we should be putting relying 
>>> parties at even further risk.  If that’s our measure stick, we might as wel 
>>> allow MD5 again because only insecure systems would generate it.
>>> 
>>> Just this year I’ve seen at least one applicant trying to submit a debian 
>>> weak key for order (which obviously got blocked).
>>> 
>>>  
>>> 
>>> I really like what was done with this ballot, except for this bit. I’d even 
>>> be alright with removing the debian weak key check requirement itself. But 
>>> calling it out explicitly as an excempt, I feel is a step too much.
>>> 
>>>  
>>> 
>>> Regards,
>>> 
>>> Martijn
>>> 
>>>  
>>> 
>>> From: Wayne Thayer mailto:wtha...@gmail.com>>
>>> Date: Friday, 23 February 2024 at 17:21
>>> To: Martijn Katerbarg >> <mailto:martijn.katerb...@sectigo.com>>
>>> Cc: CA/B Forum Server Certificate WG Public Discussion List 
>>> mailto:servercert-wg@cabforum.org>>
>>> Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>>> 
>>> CAUTION: This email originated from outside of the organi

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

[Wayne Thayer via Servercert-wg]

Now that everyone should be back from the F2F meeting, I'd like to get back
to this ballot. It currently removes all requirements for Debian weak key
checks. I'll plan to begin the formal discussion period in a few days
unless there are more responses to this thread.

Thanks,

Wayne

On Mon, Feb 26, 2024 at 1:24 PM Wayne Thayer via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Martijn,
>
> The purpose of the first weak keys ballot was to make the requirements
> more explicit. If I correctly understand your proposal, by removing the
> exception for Debian keys from this ballot, it does the opposite. The only
> compromise I can see is to require checking for Debian weak keys but only
> for specific key sizes, e.g. 2048, 3072, and 4096. That would somewhat
> reduce the burden of these checks, and I'd be happy to go that route if
> there is consensus for doing so (with approval of the endorsers, of
> course). I would appreciate input from other members on the preferred
> approach to Debian weak key checking requirements.
>
> Thanks,
>
> Wayne
>
> On Sun, Feb 25, 2024 at 12:15 AM Martijn Katerbarg <
> martijn.katerb...@sectigo.com> wrote:
>
>> Thanks Wayne,
>>
>>
>>
>> >- The Debian vulnerability is more than 15 years old. If an Applicant
>> submits a Debian weak key at this point, they almost certainly have bigger
>> security issues.
>>
>>
>>
>> This is the bit I have problems with. Just because the applicant
>> (probably) has bigger security issues, doesn’t mean we should be putting
>> relying parties at even further risk.  If that’s our measure stick, we
>> might as wel allow MD5 again because only insecure systems would generate
>> it.
>>
>> Just this year I’ve seen at least one applicant trying to submit a debian
>> weak key for order (which obviously got blocked).
>>
>>
>>
>> I really like what was done with this ballot, except for this bit. I’d
>> even be alright with removing the debian weak key check requirement itself.
>> But calling it out explicitly as an excempt, I feel is a step too much.
>>
>>
>>
>> Regards,
>>
>> Martijn
>>
>>
>>
>> *From: *Wayne Thayer 
>> *Date: *Friday, 23 February 2024 at 17:21
>> *To: *Martijn Katerbarg 
>> *Cc: *CA/B Forum Server Certificate WG Public Discussion List <
>> servercert-wg@cabforum.org>
>> *Subject: *Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>>
>> CAUTION: This email originated from outside of the organization. Do not
>> click links or open attachments unless you recognize the sender and know
>> the content is safe.
>>
>>
>>
>> Martijn,
>>
>>
>>
>> I would summarize the reasoning for removing the Debian requirements as
>> follows:
>>
>> - CAs would prefer the greater clarity that would be provided by the weak
>> keys ballot that failed last year.
>>
>> - However, some CAs were of the opinion that the prior ballot imposed
>> more explicit requirements for Debian weak key checking rather than just
>> clarifying existing requirements. The "new" requirements were viewed as
>> burdensome.
>>
>> - The Debian vulnerability is more than 15 years old. If an Applicant
>> submits a Debian weak key at this point, they almost certainly have bigger
>> security issues.
>>
>> - So the cost of these requirements outweighs the benefits at this point
>> in time.
>>
>>
>>
>> I included a few links to the discussion during the prior balot's voting
>> period, and there was also discussion at the last SCWG teleconference that
>> should be captured in the minutes.
>>
>>
>>
>> Thanks,
>>
>>
>>
>> Wayne
>>
>>
>>
>> On Fri, Feb 23, 2024 at 2:19 AM Martijn Katerbarg <
>> martijn.katerb...@sectigo.com> wrote:
>>
>> Wayne,
>>
>> Apologies if I’ve missed something in discussions, but why exactly are we
>> removing the Debian Weak Keys language, and even explicitly mentioned that
>> CAs do not need to check for them (anymore)?
>>
>>
>> Regards,
>>
>> Martijn
>>
>>
>>
>> *From: *Servercert-wg  on behalf of
>> Wayne Thayer via Servercert-wg 
>> *Date: *Thursday, 22 February 2024 at 20:01
>> *To: *CA/B Forum Server Certificate WG Public Discussion List <
>> servercert-wg@cabforum.org>
>> *Subject: *Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>>
>> CAUTION: This email originated from outside of the organization. Do not
>

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

[Wayne Thayer via Servercert-wg]

Martijn,

The purpose of the first weak keys ballot was to make the requirements more
explicit. If I correctly understand your proposal, by removing the
exception for Debian keys from this ballot, it does the opposite. The only
compromise I can see is to require checking for Debian weak keys but only
for specific key sizes, e.g. 2048, 3072, and 4096. That would somewhat
reduce the burden of these checks, and I'd be happy to go that route if
there is consensus for doing so (with approval of the endorsers, of
course). I would appreciate input from other members on the preferred
approach to Debian weak key checking requirements.

Thanks,

Wayne

On Sun, Feb 25, 2024 at 12:15 AM Martijn Katerbarg <
martijn.katerb...@sectigo.com> wrote:

> Thanks Wayne,
>
>
>
> >- The Debian vulnerability is more than 15 years old. If an Applicant
> submits a Debian weak key at this point, they almost certainly have bigger
> security issues.
>
>
>
> This is the bit I have problems with. Just because the applicant
> (probably) has bigger security issues, doesn’t mean we should be putting
> relying parties at even further risk.  If that’s our measure stick, we
> might as wel allow MD5 again because only insecure systems would generate
> it.
>
> Just this year I’ve seen at least one applicant trying to submit a debian
> weak key for order (which obviously got blocked).
>
>
>
> I really like what was done with this ballot, except for this bit. I’d
> even be alright with removing the debian weak key check requirement itself.
> But calling it out explicitly as an excempt, I feel is a step too much.
>
>
>
> Regards,
>
> Martijn
>
>
>
> *From: *Wayne Thayer 
> *Date: *Friday, 23 February 2024 at 17:21
> *To: *Martijn Katerbarg 
> *Cc: *CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject: *Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> Martijn,
>
>
>
> I would summarize the reasoning for removing the Debian requirements as
> follows:
>
> - CAs would prefer the greater clarity that would be provided by the weak
> keys ballot that failed last year.
>
> - However, some CAs were of the opinion that the prior ballot imposed more
> explicit requirements for Debian weak key checking rather than just
> clarifying existing requirements. The "new" requirements were viewed as
> burdensome.
>
> - The Debian vulnerability is more than 15 years old. If an Applicant
> submits a Debian weak key at this point, they almost certainly have bigger
> security issues.
>
> - So the cost of these requirements outweighs the benefits at this point
> in time.
>
>
>
> I included a few links to the discussion during the prior balot's voting
> period, and there was also discussion at the last SCWG teleconference that
> should be captured in the minutes.
>
>
>
> Thanks,
>
>
>
> Wayne
>
>
>
> On Fri, Feb 23, 2024 at 2:19 AM Martijn Katerbarg <
> martijn.katerb...@sectigo.com> wrote:
>
> Wayne,
>
> Apologies if I’ve missed something in discussions, but why exactly are we
> removing the Debian Weak Keys language, and even explicitly mentioned that
> CAs do not need to check for them (anymore)?
>
>
> Regards,
>
> Martijn
>
>
>
> *From: *Servercert-wg  on behalf of
> Wayne Thayer via Servercert-wg 
> *Date: *Thursday, 22 February 2024 at 20:01
> *To: *CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject: *Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> I am seeking a second endorser for this proposal. Below is a draft of the
> ballot language.
>
>
>
> Thanks,
>
>
>
> Wayne
>
> 
>
> **Ballot SC-XX: Compromised / Weak Keys**
>
> This ballot updates BR section 6.1.1.3 to address two issues:
>
> First, the requirements placed on CAs to reject a certificate request if
> they have been “made aware” that the key pair is compromised is vague and
> open-ended in regard to how CAs may be “made aware”. This ballot specifies
> that CAs be “made aware” via their problem reporting mechanism.
>
> Second, this ballot reintroduces the language from [failed] ballot SC-59:
> Weak Key Guidance. However, based on feedback received during the
> disc

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

[Martijn Katerbarg via Servercert-wg]

Thanks Wayne, 

>- The Debian vulnerability is more than 15 years old. If an Applicant submits 
>a Debian weak key at this point, they almost certainly have bigger security 
>issues. 

This is the bit I have problems with. Just because the applicant (probably) has 
bigger security issues, doesn’t mean we should be putting relying parties at 
even further risk. If that’s our measure stick, we might as wel allow MD5 again 
because only insecure systems would generate it.

Just this year I’ve seen at least one applicant trying to submit a debian weak 
key for order (which obviously got blocked). 

I really like what was done with this ballot, except for this bit. I’d even be 
alright with removing the debian weak key check requirement itself. But calling 
it out explicitly as an excempt, I feel is a step too much. 

Regards,

Martijn 

From: Wayne Thayer 
Date: Friday, 23 February 2024 at 17:21
To: Martijn Katerbarg 
Cc: CA/B Forum Server Certificate WG Public Discussion List 

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. 


Martijn, 



I would summarize the reasoning for removing the Debian requirements as 
follows: 

- CAs would prefer the greater clarity that would be provided by the weak keys 
ballot that failed last year. 

- However, some CAs were of the opinion that the prior ballot imposed more 
explicit requirements for Debian weak key checking rather than just clarifying 
existing requirements. The "new" requirements were viewed as burdensome. 

- The Debian vulnerability is more than 15 years old. If an Applicant submits a 
Debian weak key at this point, they almost certainly have bigger security 
issues. 

- So the cost of these requirements outweighs the benefits at this point in 
time. 



I included a few links to the discussion during the prior balot's voting 
period, and there was also discussion at the last SCWG teleconference that 
should be captured in the minutes. 



Thanks, 



Wayne 



On Fri, Feb 23, 2024 at 2:19 AM Martijn Katerbarg 
mailto:martijn.katerb...@sectigo.com>> wrote: 

Wayne, 

Apologies if I’ve missed something in discussions, but why exactly are we 
removing the Debian Weak Keys language, and even explicitly mentioned that CAs 
do not need to check for them (anymore)? 

Regards,

Martijn 

From: Servercert-wg > on behalf of 
Wayne Thayer via Servercert-wg >
Date: Thursday, 22 February 2024 at 20:01
To: CA/B Forum Server Certificate WG Public Discussion List 
>
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal 

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. 


I am seeking a second endorser for this proposal. Below is a draft of the 
ballot language. 



Thanks, 



Wayne 

 

**Ballot SC-XX: Compromised / Weak Keys**

This ballot updates BR section 6.1.1.3 to address two issues:

First, the requirements placed on CAs to reject a certificate request if they 
have been “made aware” that the key pair is compromised is vague and open-ended 
in regard to how CAs may be “made aware”. This ballot specifies that CAs be 
“made aware” via their problem reporting mechanism.

Second, this ballot reintroduces the language from [failed] ballot SC-59: Weak 
Key Guidance. However, based on feedback received during the discussion and 
voting period for that ballot, Debian weak key checks are now explicitly out of 
scope.

This ballot is proposed by Wayne Thayer (Fastly) and endorsed by Brittany 
Randall (GoDaddy) and . You can view and comment on the github 
pull request representing this ballot here: 
https://github.com/wthayer/servercert/pull/1/files <_blank> 

The preceding discussions can be seen here:

* This ballot: 
https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004195.html 
<_blank> 
* The prior weak keys ballot: 
https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html 
<_blank> and 
https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html 
<_blank>
* The “made aware” language in 6.1.1.3 <_blank>: 
https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html 
<_blank>


--- Motion Begins ---

This ballot modifies the "Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates" ("Baseline Requirements") based on Version 
2.X.X

MODIFY the Baseline Requirements as specified in the following redline: 


--- Motion Ends ---

Discussion (at least 7 days):

- Start: TBD UTC
- End: TBD UTC

Vote for approval (7 days):

- Start: TBD UTC
- End: TBD UTC 


On Mon, Feb 12, 2024 at 6:12 PM Wayne Thayer via Servercert-wg 
> wrote: 

Thank you fo th

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

[Wayne Thayer via Servercert-wg]

>
> I think it's safest to err on the side of caution and use the explicit
> wording that you proposed.


I've made that clarification in the PR at
https://github.com/wthayer/servercert/pull/1/files

I'm still seeking a second endorser.

Thanks,

Wayne

On Fri, Feb 23, 2024 at 2:25 PM Tom Zermeno  wrote:

> Wayne,
>
>
>
> I think it's safest to err on the side of caution and use the explicit
> wording that you proposed.
>
>
>
> Thanks,
>
>
>
> Tom
>
>
>
> *From:* Wayne Thayer 
> *Sent:* Friday, February 23, 2024 2:45 PM
> *To:* Tom Zermeno 
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>; Martijn Katerbarg <
> martijn.katerb...@sectigo.com>
> *Subject:* Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
>
>
> You don't often get email from wtha...@gmail.com. Learn why this is
> important <https://aka.ms/LearnAboutSenderIdentification>
>
> Tom,
>
>
>
> I had originally placed the Debian exception in the sublist of 6.1.1.3(5),
> but Aaron Gable correctly pointed out that it doesn't make sense there
> because that sublist is prefaced with the statement "the following
> precautions SHALL be implemented:" I think it would be logically difficult
> to interpret the exception as belonging with 6.1.1.3(5)(ii) Close Primes,
> but I do agree that it could be clearer. To that end, I've change the
> indentation of the exception sentence in
> https://github.com/wthayer/servercert/pull/1/files Does that help? I
> could also change the wording to "Debian weak keys (
> https://wiki.debian.org/SSLkeys) are exempt from the requirements of
> Section 6.1.1.3(5).
>
>
>
> Thanks,
>
>
>
> Wayne
>
>
>
> On Fri, Feb 23, 2024 at 10:33 AM Tom Zermeno  wrote:
>
> Wayne,
>
> Regarding the change of the Debian weak keys statement at proposed line
> 1701: is the statement intended to be a sub-clause of the second item in
> the sublist, which would then make Debian weak keys exempt from the Fermat
> factorization method check?  Or, more likely based on the recent
> discussion, was the statement meant to be a third item in the list, which
> would then exempt Debian weak keys from the 5th condition of the list
> requiring CAs to reject certificate requests?
>
>
>
> My question stems from the abnormal line spacing and indention of the
> statement, which stands out from the surrounding text.
>
>
>
> Thanks,
>
>
>
> Tom
>
>
>
> *From:* Servercert-wg  *On Behalf Of 
> *Wayne
> Thayer via Servercert-wg
> *Sent:* Friday, February 23, 2024 11:18 AM
> *To:* Martijn Katerbarg 
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject:* Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
>
>
> Martijn,
>
>
>
> I would summarize the reasoning for removing the Debian requirements as
> follows:
>
> - CAs would prefer the greater clarity that would be provided by the weak
> keys ballot that failed last year.
>
> - However, some CAs were of the opinion that the prior ballot imposed more
> explicit requirements for Debian weak key checking rather than just
> clarifying existing requirements. The "new" requirements were viewed as
> burdensome.
>
> - The Debian vulnerability is more than 15 years old. If an Applicant
> submits a Debian weak key at this point, they almost certainly have bigger
> security issues.
>
> - So the cost of these requirements outweighs the benefits at this point
> in time.
>
>
>
> I included a few links to the discussion during the prior balot's voting
> period, and there was also discussion at the last SCWG teleconference that
> should be captured in the minutes.
>
>
>
> Thanks,
>
>
>
> Wayne
>
>
>
> On Fri, Feb 23, 2024 at 2:19 AM Martijn Katerbarg <
> martijn.katerb...@sectigo.com> wrote:
>
> Wayne,
>
> Apologies if I’ve missed something in discussions, but why exactly are we
> removing the Debian Weak Keys language, and even explicitly mentioned that
> CAs do not need to check for them (anymore)?
>
>
> Regards,
>
> Martijn
>
>
>
> *From: *Servercert-wg  on behalf of
> Wayne Thayer via Servercert-wg 
> *Date: *Thursday, 22 February 2024 at 20:01
> *To: *CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject: *Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is sa

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

[Tom Zermeno via Servercert-wg]

Wayne,

 

I think it's safest to err on the side of caution and use the explicit wording 
that you proposed.

 

Thanks,

 

Tom

 

From: Wayne Thayer  
Sent: Friday, February 23, 2024 2:45 PM
To: Tom Zermeno 
Cc: CA/B Forum Server Certificate WG Public Discussion List 
; Martijn Katerbarg 
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

 


You don't often get email from wtha...@gmail.com <mailto:wtha...@gmail.com> . 
Learn why this is important <https://aka.ms/LearnAboutSenderIdentification> 



Tom,

 

I had originally placed the Debian exception in the sublist of 6.1.1.3(5), but 
Aaron Gable correctly pointed out that it doesn't make sense there because that 
sublist is prefaced with the statement "the following precautions SHALL be 
implemented:" I think it would be logically difficult to interpret the 
exception as belonging with 6.1.1.3(5)(ii) Close Primes, but I do agree that it 
could be clearer. To that end, I've change the indentation of the exception 
sentence in https://github.com/wthayer/servercert/pull/1/files Does that help? 
I could also change the wording to "Debian weak keys 
(https://wiki.debian.org/SSLkeys) are exempt from the requirements of Section 
6.1.1.3(5).

 

Thanks,

 

Wayne

 

On Fri, Feb 23, 2024 at 10:33 AM Tom Zermeno mailto:t...@ssl.com> > wrote:

Wayne,

Regarding the change of the Debian weak keys statement at proposed line 1701: 
is the statement intended to be a sub-clause of the second item in the sublist, 
which would then make Debian weak keys exempt from the Fermat factorization 
method check?  Or, more likely based on the recent discussion, was the 
statement meant to be a third item in the list, which would then exempt Debian 
weak keys from the 5th condition of the list requiring CAs to reject 
certificate requests?

 

My question stems from the abnormal line spacing and indention of the 
statement, which stands out from the surrounding text.

 

Thanks, 

 

Tom

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > On Behalf Of Wayne Thayer via 
Servercert-wg
Sent: Friday, February 23, 2024 11:18 AM
To: Martijn Katerbarg mailto:martijn.katerb...@sectigo.com> >
Cc: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org> >
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

 

Martijn,

 

I would summarize the reasoning for removing the Debian requirements as follows:

- CAs would prefer the greater clarity that would be provided by the weak keys 
ballot that failed last year.

- However, some CAs were of the opinion that the prior ballot imposed more 
explicit requirements for Debian weak key checking rather than just clarifying 
existing requirements. The "new" requirements were viewed as burdensome.

- The Debian vulnerability is more than 15 years old. If an Applicant submits a 
Debian weak key at this point, they almost certainly have bigger security 
issues.

- So the cost of these requirements outweighs the benefits at this point in 
time.

 

I included a few links to the discussion during the prior balot's voting 
period, and there was also discussion at the last SCWG teleconference that 
should be captured in the minutes.

 

Thanks,

 

Wayne

 

On Fri, Feb 23, 2024 at 2:19 AM Martijn Katerbarg 
mailto:martijn.katerb...@sectigo.com> > wrote:

Wayne, 

Apologies if I’ve missed something in discussions, but why exactly are we 
removing the Debian Weak Keys language, and even explicitly mentioned that CAs 
do not need to check for them (anymore)?


Regards,

Martijn

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > on behalf of Wayne Thayer via 
Servercert-wg mailto:servercert-wg@cabforum.org> >
Date: Thursday, 22 February 2024 at 20:01
To: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org> >
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

 

I am seeking a second endorser for this proposal. Below is a draft of the 
ballot language.

 

Thanks,

 

Wayne



**Ballot SC-XX: Compromised / Weak Keys**

This ballot updates BR section 6.1.1.3 to address two issues:

First, the requirements placed on CAs to reject a certificate request if they 
have been “made aware” that the key pair is compromised is vague and open-ended 
in regard to how CAs may be “made aware”. This ballot specifies that CAs be 
“made aware” via their problem reporting mechanism.

Second, this ballot reintroduces the language from [failed] ballot SC-59: Weak 
Key Guidance. However, based on feedback received during the discussion and 
voting period for that ballot, Debian weak key checks are now explicitly out of 
scope

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

[Wayne Thayer via Servercert-wg]

Tom,

I had originally placed the Debian exception in the sublist of 6.1.1.3(5),
but Aaron Gable correctly pointed out that it doesn't make sense there
because that sublist is prefaced with the statement "the following
precautions SHALL be implemented:" I think it would be logically difficult
to interpret the exception as belonging with 6.1.1.3(5)(ii) Close Primes,
but I do agree that it could be clearer. To that end, I've change the
indentation of the exception sentence in
https://github.com/wthayer/servercert/pull/1/files Does that help? I could
also change the wording to "Debian weak keys (
https://wiki.debian.org/SSLkeys) are exempt from the requirements of
Section 6.1.1.3(5).

Thanks,

Wayne

On Fri, Feb 23, 2024 at 10:33 AM Tom Zermeno  wrote:

> Wayne,
>
> Regarding the change of the Debian weak keys statement at proposed line
> 1701: is the statement intended to be a sub-clause of the second item in
> the sublist, which would then make Debian weak keys exempt from the Fermat
> factorization method check?  Or, more likely based on the recent
> discussion, was the statement meant to be a third item in the list, which
> would then exempt Debian weak keys from the 5th condition of the list
> requiring CAs to reject certificate requests?
>
>
>
> My question stems from the abnormal line spacing and indention of the
> statement, which stands out from the surrounding text.
>
>
>
> Thanks,
>
>
>
> Tom
>
>
>
> *From:* Servercert-wg  *On Behalf Of 
> *Wayne
> Thayer via Servercert-wg
> *Sent:* Friday, February 23, 2024 11:18 AM
> *To:* Martijn Katerbarg 
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject:* Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
>
>
> Martijn,
>
>
>
> I would summarize the reasoning for removing the Debian requirements as
> follows:
>
> - CAs would prefer the greater clarity that would be provided by the weak
> keys ballot that failed last year.
>
> - However, some CAs were of the opinion that the prior ballot imposed more
> explicit requirements for Debian weak key checking rather than just
> clarifying existing requirements. The "new" requirements were viewed as
> burdensome.
>
> - The Debian vulnerability is more than 15 years old. If an Applicant
> submits a Debian weak key at this point, they almost certainly have bigger
> security issues.
>
> - So the cost of these requirements outweighs the benefits at this point
> in time.
>
>
>
> I included a few links to the discussion during the prior balot's voting
> period, and there was also discussion at the last SCWG teleconference that
> should be captured in the minutes.
>
>
>
> Thanks,
>
>
>
> Wayne
>
>
>
> On Fri, Feb 23, 2024 at 2:19 AM Martijn Katerbarg <
> martijn.katerb...@sectigo.com> wrote:
>
> Wayne,
>
> Apologies if I’ve missed something in discussions, but why exactly are we
> removing the Debian Weak Keys language, and even explicitly mentioned that
> CAs do not need to check for them (anymore)?
>
>
> Regards,
>
> Martijn
>
>
>
> *From: *Servercert-wg  on behalf of
> Wayne Thayer via Servercert-wg 
> *Date: *Thursday, 22 February 2024 at 20:01
> *To: *CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject: *Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> I am seeking a second endorser for this proposal. Below is a draft of the
> ballot language.
>
>
>
> Thanks,
>
>
>
> Wayne
>
> 
>
> **Ballot SC-XX: Compromised / Weak Keys**
>
> This ballot updates BR section 6.1.1.3 to address two issues:
>
> First, the requirements placed on CAs to reject a certificate request if
> they have been “made aware” that the key pair is compromised is vague and
> open-ended in regard to how CAs may be “made aware”. This ballot specifies
> that CAs be “made aware” via their problem reporting mechanism.
>
> Second, this ballot reintroduces the language from [failed] ballot SC-59:
> Weak Key Guidance. However, based on feedback received during the
> discussion and voting period for that ballot, Debian weak key checks are
> now explicitly out of scope.
>
> This ballot is proposed by Wayne Thayer (Fastly) and endorsed by Brittany
> Randall (GoDaddy) and . You can view and comment on the
> github pull request representing this ballot here:
> https://github.com/wthayer/servercert/p

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

[Tom Zermeno via Servercert-wg]

Wayne,

Regarding the change of the Debian weak keys statement at proposed line 1701: 
is the statement intended to be a sub-clause of the second item in the sublist, 
which would then make Debian weak keys exempt from the Fermat factorization 
method check?  Or, more likely based on the recent discussion, was the 
statement meant to be a third item in the list, which would then exempt Debian 
weak keys from the 5th condition of the list requiring CAs to reject 
certificate requests?

 

My question stems from the abnormal line spacing and indention of the 
statement, which stands out from the surrounding text.

 

Thanks, 

 

Tom

 

From: Servercert-wg  On Behalf Of Wayne 
Thayer via Servercert-wg
Sent: Friday, February 23, 2024 11:18 AM
To: Martijn Katerbarg 
Cc: CA/B Forum Server Certificate WG Public Discussion List 

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

 

Martijn,

 

I would summarize the reasoning for removing the Debian requirements as follows:

- CAs would prefer the greater clarity that would be provided by the weak keys 
ballot that failed last year.

- However, some CAs were of the opinion that the prior ballot imposed more 
explicit requirements for Debian weak key checking rather than just clarifying 
existing requirements. The "new" requirements were viewed as burdensome.

- The Debian vulnerability is more than 15 years old. If an Applicant submits a 
Debian weak key at this point, they almost certainly have bigger security 
issues.

- So the cost of these requirements outweighs the benefits at this point in 
time.

 

I included a few links to the discussion during the prior balot's voting 
period, and there was also discussion at the last SCWG teleconference that 
should be captured in the minutes.

 

Thanks,

 

Wayne

 

On Fri, Feb 23, 2024 at 2:19 AM Martijn Katerbarg 
mailto:martijn.katerb...@sectigo.com> > wrote:

Wayne, 

Apologies if I’ve missed something in discussions, but why exactly are we 
removing the Debian Weak Keys language, and even explicitly mentioned that CAs 
do not need to check for them (anymore)?


Regards,

Martijn

 

From: Servercert-wg mailto:servercert-wg-boun...@cabforum.org> > on behalf of Wayne Thayer via 
Servercert-wg mailto:servercert-wg@cabforum.org> >
Date: Thursday, 22 February 2024 at 20:01
To: CA/B Forum Server Certificate WG Public Discussion List 
mailto:servercert-wg@cabforum.org> >
Subject: Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.

 

I am seeking a second endorser for this proposal. Below is a draft of the 
ballot language.

 

Thanks,

 

Wayne



**Ballot SC-XX: Compromised / Weak Keys**

This ballot updates BR section 6.1.1.3 to address two issues:

First, the requirements placed on CAs to reject a certificate request if they 
have been “made aware” that the key pair is compromised is vague and open-ended 
in regard to how CAs may be “made aware”. This ballot specifies that CAs be 
“made aware” via their problem reporting mechanism.

Second, this ballot reintroduces the language from [failed] ballot SC-59: Weak 
Key Guidance. However, based on feedback received during the discussion and 
voting period for that ballot, Debian weak key checks are now explicitly out of 
scope.

This ballot is proposed by Wayne Thayer (Fastly) and endorsed by Brittany 
Randall (GoDaddy) and . You can view and comment on the github 
pull request representing this ballot here: 
https://github.com/wthayer/servercert/pull/1/files 

The preceding discussions can be seen here:

* This ballot: 
https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004195.html 
* The prior weak keys ballot: 
https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html and 
https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html
* The “made aware” language in 6.1.1.3 <http://6.1.1.3/> :  
https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html


--- Motion Begins ---

This ballot modifies the "Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates" ("Baseline Requirements") based on Version 
2.X.X

MODIFY the Baseline Requirements as specified in the following redline: 


--- Motion Ends ---

Discussion (at least 7 days):

- Start: TBD UTC
- End: TBD UTC

Vote for approval (7 days):

- Start: TBD UTC
- End: TBD UTC

 

On Mon, Feb 12, 2024 at 6:12 PM Wayne Thayer via Servercert-wg 
mailto:servercert-wg@cabforum.org> > wrote:

Thank you fo the feedback Aaron. I agree with both points you made in the PR 
and have updated it to reflect your suggestions.

 

- Wayne

 

On Mon, Feb 12, 2024 at 12:27 PM Aaron Gable mailto:aa...@letsencrypt.org> > wrote:

Thank you Wayne! I think th

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

[Wayne Thayer via Servercert-wg]

Martijn,

I would summarize the reasoning for removing the Debian requirements as
follows:
- CAs would prefer the greater clarity that would be provided by the weak
keys ballot that failed last year.
- However, some CAs were of the opinion that the prior ballot imposed more
explicit requirements for Debian weak key checking rather than just
clarifying existing requirements. The "new" requirements were viewed as
burdensome.
- The Debian vulnerability is more than 15 years old. If an Applicant
submits a Debian weak key at this point, they almost certainly have bigger
security issues.
- So the cost of these requirements outweighs the benefits at this point in
time.

I included a few links to the discussion during the prior balot's voting
period, and there was also discussion at the last SCWG teleconference that
should be captured in the minutes.

Thanks,

Wayne

On Fri, Feb 23, 2024 at 2:19 AM Martijn Katerbarg <
martijn.katerb...@sectigo.com> wrote:

> Wayne,
>
> Apologies if I’ve missed something in discussions, but why exactly are we
> removing the Debian Weak Keys language, and even explicitly mentioned that
> CAs do not need to check for them (anymore)?
>
>
> Regards,
>
> Martijn
>
>
>
> *From: *Servercert-wg  on behalf of
> Wayne Thayer via Servercert-wg 
> *Date: *Thursday, 22 February 2024 at 20:01
> *To: *CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg@cabforum.org>
> *Subject: *Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
> CAUTION: This email originated from outside of the organization. Do not
> click links or open attachments unless you recognize the sender and know
> the content is safe.
>
>
>
> I am seeking a second endorser for this proposal. Below is a draft of the
> ballot language.
>
>
>
> Thanks,
>
>
>
> Wayne
>
> 
>
> **Ballot SC-XX: Compromised / Weak Keys**
>
> This ballot updates BR section 6.1.1.3 to address two issues:
>
> First, the requirements placed on CAs to reject a certificate request if
> they have been “made aware” that the key pair is compromised is vague and
> open-ended in regard to how CAs may be “made aware”. This ballot specifies
> that CAs be “made aware” via their problem reporting mechanism.
>
> Second, this ballot reintroduces the language from [failed] ballot SC-59:
> Weak Key Guidance. However, based on feedback received during the
> discussion and voting period for that ballot, Debian weak key checks are
> now explicitly out of scope.
>
> This ballot is proposed by Wayne Thayer (Fastly) and endorsed by Brittany
> Randall (GoDaddy) and . You can view and comment on the
> github pull request representing this ballot here:
> https://github.com/wthayer/servercert/pull/1/files
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fwthayer%2Fservercert%2Fpull%2F1%2Ffiles=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ce1972d46f9014e77784508dc33d8a94a%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638442252850059096%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=gFjQNLM5vvNOPn6e%2F5Rqroqyrd5wWvOa1OMhr0ZKygA%3D=0>
>
> The preceding discussions can be seen here:
>
> * This ballot:
> https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004195.html
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fservercert-wg%2F2024-February%2F004195.html=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ce1972d46f9014e77784508dc33d8a94a%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638442252850068855%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=wWbBUYFJgmWv6%2BDGJozU3t%2BuAmZcz0B3JWQ8SLPGP1k%3D=0>
> * The prior weak keys ballot:
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fservercert-wg%2F2023-July%2F003820.html=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ce1972d46f9014e77784508dc33d8a94a%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638442252850076172%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=4EXcyRFbmLWIzmvtH7jMejnsdSKivK4DCAKt3CnQY7c%3D=0>
> and
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html
> <https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fservercert-wg%2F2023-July%2F003857.html=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ce1972d46f9014e77784508dc33d8a94a%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638442252850081831%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLC

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

[Martijn Katerbarg via Servercert-wg]

Wayne, 

Apologies if I’ve missed something in discussions, but why exactly are we 
removing the Debian Weak Keys language, and even explicitly mentioned that CAs 
do not need to check for them (anymore)? 

Regards,

Martijn 

From: Servercert-wg  on behalf of Wayne 
Thayer via Servercert-wg 
Date: Thursday, 22 February 2024 at 20:01
To: CA/B Forum Server Certificate WG Public Discussion List 

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

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe. 


I am seeking a second endorser for this proposal. Below is a draft of the 
ballot language. 



Thanks, 



Wayne 

 

**Ballot SC-XX: Compromised / Weak Keys**

This ballot updates BR section 6.1.1.3 to address two issues:

First, the requirements placed on CAs to reject a certificate request if they 
have been “made aware” that the key pair is compromised is vague and open-ended 
in regard to how CAs may be “made aware”. This ballot specifies that CAs be 
“made aware” via their problem reporting mechanism.

Second, this ballot reintroduces the language from [failed] ballot SC-59: Weak 
Key Guidance. However, based on feedback received during the discussion and 
voting period for that ballot, Debian weak key checks are now explicitly out of 
scope.

This ballot is proposed by Wayne Thayer (Fastly) and endorsed by Brittany 
Randall (GoDaddy) and . You can view and comment on the github 
pull request representing this ballot here: 
https://github.com/wthayer/servercert/pull/1/files 
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fwthayer%2Fservercert%2Fpull%2F1%2Ffilesdata=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ce1972d46f9014e77784508dc33d8a94a%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638442252850059096%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7Csdata=gFjQNLM5vvNOPn6e%2F5Rqroqyrd5wWvOa1OMhr0ZKygA%3Dreserved=0>
 

The preceding discussions can be seen here:

* This ballot: 
https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004195.html 
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fservercert-wg%2F2024-February%2F004195.htmldata=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ce1972d46f9014e77784508dc33d8a94a%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638442252850068855%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7Csdata=wWbBUYFJgmWv6%2BDGJozU3t%2BuAmZcz0B3JWQ8SLPGP1k%3Dreserved=0>
 
* The prior weak keys ballot: 
https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html 
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fservercert-wg%2F2023-July%2F003820.htmldata=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ce1972d46f9014e77784508dc33d8a94a%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638442252850076172%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7Csdata=4EXcyRFbmLWIzmvtH7jMejnsdSKivK4DCAKt3CnQY7c%3Dreserved=0>
 and https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html 
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fservercert-wg%2F2023-July%2F003857.htmldata=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ce1972d46f9014e77784508dc33d8a94a%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638442252850081831%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7Csdata=1Nb2h4lpYGRnBeo5rsepAzxv67MgomR3jzrLQi2673I%3Dreserved=0>
* The “made aware” language in 6.1.1.3 
<https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2F6.1.1.3%2Fdata=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ce1972d46f9014e77784508dc33d8a94a%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638442252850089378%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7Csdata=jfVRbttj6iNh4BZulivr9LMIvY10tKy2YUYtnFjcCtw%3Dreserved=0>:
 https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html 
<https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fpipermail%2Fservercert-wg%2F2023-July%2F003902.htmldata=05%7C02%7Cmartijn.katerbarg%40sectigo.com%7Ce1972d46f9014e77784508dc33d8a94a%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638442252850096339%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7Csdata=WnyrTX2%2BPcieAuFKKoSPMalLE1fgPkaQ3U51wuY%2BjZM%3Dreserved=0>


--- Motion Begins ---

This ballot modifies the "Baseline Requirements for the Issuance and Management 
of Publicly-Trusted Certificates" ("Baseline Requirements") based on Versi

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

[Wayne Thayer via Servercert-wg]

I am seeking a second endorser for this proposal. Below is a draft of the
ballot language.

Thanks,

Wayne

**Ballot SC-XX: Compromised / Weak Keys**

This ballot updates BR section 6.1.1.3 to address two issues:

First, the requirements placed on CAs to reject a certificate request if
they have been “made aware” that the key pair is compromised is vague and
open-ended in regard to how CAs may be “made aware”. This ballot specifies
that CAs be “made aware” via their problem reporting mechanism.

Second, this ballot reintroduces the language from [failed] ballot SC-59:
Weak Key Guidance. However, based on feedback received during the
discussion and voting period for that ballot, Debian weak key checks are
now explicitly out of scope.

This ballot is proposed by Wayne Thayer (Fastly) and endorsed by Brittany
Randall (GoDaddy) and . You can view and comment on the
github pull request representing this ballot here:
https://github.com/wthayer/servercert/pull/1/files

The preceding discussions can be seen here:

* This ballot:
https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004195.html
* The prior weak keys ballot:
https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html
and https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html
* The “made aware” language in 6.1.1.3:
https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html


--- Motion Begins ---

This ballot modifies the "Baseline Requirements for the Issuance and
Management of Publicly-Trusted Certificates" ("Baseline Requirements")
based on Version 2.X.X

MODIFY the Baseline Requirements as specified in the following redline:


--- Motion Ends ---

Discussion (at least 7 days):

- Start: TBD UTC
- End: TBD UTC

Vote for approval (7 days):

- Start: TBD UTC
- End: TBD UTC

On Mon, Feb 12, 2024 at 6:12 PM Wayne Thayer via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Thank you fo the feedback Aaron. I agree with both points you made in the
> PR and have updated it to reflect your suggestions.
>
> - Wayne
>
> On Mon, Feb 12, 2024 at 12:27 PM Aaron Gable 
> wrote:
>
>> Thank you Wayne! I think this gets close to the sweet spot for me,
>> personally. I've left two small comments on the ballot, but on the whole I
>> think I like this approach.
>>
>> Thanks again,
>> Aaron
>>
>> On Mon, Feb 12, 2024 at 8:18 AM Wayne Thayer via Servercert-wg <
>> servercert-wg@cabforum.org> wrote:
>>
>>> Following up from the last SCWG teleconference, I've reviewed the
>>> feedback from the discussion [1] and voting [2] periods for ballot SC-59
>>> Weak Key Guidance, along with the prior discussions on the "made aware"
>>> language in section 6.1.1.3 [3] and I would like to propose the following
>>> Baseline Requirements improvements:
>>>
>>> * Scope the 6.1.1.3 "made aware" language to "made aware via the CA's
>>> documented problem reporting mechanism". This addresses the concern that I
>>> raised by limiting how a CA can be "made aware". [4]
>>>
>>> * Remove the Debian requirements from the prior weak keys ballot and
>>> replace them with language that excludes Debian weak keys. Otherwise use
>>> the language from the prior ballot, with the exception of a new effective
>>> date. This consolidates feedback that CAs do desire the clarity that would
>>> have been provided by the prior ballot, but many believe that the burden
>>> for rejecting Debian weak keys exceeds the value of doing so at this point
>>> in time.
>>>
>>> Here's the result: https://github.com/wthayer/servercert/pull/1/files
>>>
>>> Note that, while there has been discussion about completely removing
>>> weak key checking requirements, there does not appear to be a consensus to
>>> do so.
>>>
>>> I would appreciate everyone's feedback on the proposal, and I am also
>>> seeking endorsers.
>>>
>>> Thanks,
>>>
>>> Wayne
>>>
>>> [1]
>>> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html
>>> [2]
>>> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html
>>> [3]
>>> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html
>>> [4] https://github.com/cabforum/servercert/issues/442
>>>
>>> ___
>>> Servercert-wg mailing list
>>> Servercert-wg@cabforum.org
>>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>>
>> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
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 fo the feedback Aaron. I agree with both points you made in the
PR and have updated it to reflect your suggestions.

- Wayne

On Mon, Feb 12, 2024 at 12:27 PM Aaron Gable  wrote:

> Thank you Wayne! I think this gets close to the sweet spot for me,
> personally. I've left two small comments on the ballot, but on the whole I
> think I like this approach.
>
> Thanks again,
> Aaron
>
> On Mon, Feb 12, 2024 at 8:18 AM Wayne Thayer via Servercert-wg <
> servercert-wg@cabforum.org> wrote:
>
>> Following up from the last SCWG teleconference, I've reviewed the
>> feedback from the discussion [1] and voting [2] periods for ballot SC-59
>> Weak Key Guidance, along with the prior discussions on the "made aware"
>> language in section 6.1.1.3 [3] and I would like to propose the following
>> Baseline Requirements improvements:
>>
>> * Scope the 6.1.1.3 "made aware" language to "made aware via the CA's
>> documented problem reporting mechanism". This addresses the concern that I
>> raised by limiting how a CA can be "made aware". [4]
>>
>> * Remove the Debian requirements from the prior weak keys ballot and
>> replace them with language that excludes Debian weak keys. Otherwise use
>> the language from the prior ballot, with the exception of a new effective
>> date. This consolidates feedback that CAs do desire the clarity that would
>> have been provided by the prior ballot, but many believe that the burden
>> for rejecting Debian weak keys exceeds the value of doing so at this point
>> in time.
>>
>> Here's the result: https://github.com/wthayer/servercert/pull/1/files
>>
>> Note that, while there has been discussion about completely removing weak
>> key checking requirements, there does not appear to be a consensus to do so.
>>
>> I would appreciate everyone's feedback on the proposal, and I am also
>> seeking endorsers.
>>
>> Thanks,
>>
>> Wayne
>>
>> [1]
>> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html
>> [2]
>> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html
>> [3]
>> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html
>> [4] https://github.com/cabforum/servercert/issues/442
>>
>> ___
>> Servercert-wg mailing list
>> Servercert-wg@cabforum.org
>> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>>
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

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

[Aaron Gable via Servercert-wg]

Thank you Wayne! I think this gets close to the sweet spot for me,
personally. I've left two small comments on the ballot, but on the whole I
think I like this approach.

Thanks again,
Aaron

On Mon, Feb 12, 2024 at 8:18 AM Wayne Thayer via Servercert-wg <
servercert-wg@cabforum.org> wrote:

> Following up from the last SCWG teleconference, I've reviewed the feedback
> from the discussion [1] and voting [2] periods for ballot SC-59 Weak Key
> Guidance, along with the prior discussions on the "made aware" language in
> section 6.1.1.3 [3] and I would like to propose the following Baseline
> Requirements improvements:
>
> * Scope the 6.1.1.3 "made aware" language to "made aware via the CA's
> documented problem reporting mechanism". This addresses the concern that I
> raised by limiting how a CA can be "made aware". [4]
>
> * Remove the Debian requirements from the prior weak keys ballot and
> replace them with language that excludes Debian weak keys. Otherwise use
> the language from the prior ballot, with the exception of a new effective
> date. This consolidates feedback that CAs do desire the clarity that would
> have been provided by the prior ballot, but many believe that the burden
> for rejecting Debian weak keys exceeds the value of doing so at this point
> in time.
>
> Here's the result: https://github.com/wthayer/servercert/pull/1/files
>
> Note that, while there has been discussion about completely removing weak
> key checking requirements, there does not appear to be a consensus to do so.
>
> I would appreciate everyone's feedback on the proposal, and I am also
> seeking endorsers.
>
> Thanks,
>
> Wayne
>
> [1]
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html
> [2]
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html
> [3]
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html
> [4] https://github.com/cabforum/servercert/issues/442
>
> ___
> Servercert-wg mailing list
> Servercert-wg@cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg

[Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Wayne Thayer via Servercert-wg]

Following up from the last SCWG teleconference, I've reviewed the feedback
from the discussion [1] and voting [2] periods for ballot SC-59 Weak Key
Guidance, along with the prior discussions on the "made aware" language in
section 6.1.1.3 [3] and I would like to propose the following Baseline
Requirements improvements:

* Scope the 6.1.1.3 "made aware" language to "made aware via the CA's
documented problem reporting mechanism". This addresses the concern that I
raised by limiting how a CA can be "made aware". [4]

* Remove the Debian requirements from the prior weak keys ballot and
replace them with language that excludes Debian weak keys. Otherwise use
the language from the prior ballot, with the exception of a new effective
date. This consolidates feedback that CAs do desire the clarity that would
have been provided by the prior ballot, but many believe that the burden
for rejecting Debian weak keys exceeds the value of doing so at this point
in time.

Here's the result: https://github.com/wthayer/servercert/pull/1/files

Note that, while there has been discussion about completely removing weak
key checking requirements, there does not appear to be a consensus to do so.

I would appreciate everyone's feedback on the proposal, and I am also
seeking endorsers.

Thanks,

Wayne

[1] https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html
[2] https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html
[3] https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html
[4] https://github.com/cabforum/servercert/issues/442
___
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg