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  > 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 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 

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 uses an outdated OS that generates weak keys,