[Servercert-wg] SCXX Ballot - Debian Weak Keys (and related vulnerabilities)

Wed Jun 8 12:28:14 UTC 2022

Sadly, the previously sent draft incorrectly formatted the Fermat attack addition. Here is the corrected version.

CK

NO FUTURE EFFECTIVE DATE, fwiw

--- Motion Begins ---

This ballot is intended to clarify CA responsibilities regarding weak key vulnerabilities, including specific guidance for Debian weak key, ROCA and Fermat attack vulnerabilities, and modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based on Version 1.8.4:

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based on Version 1.7.4:

Proposed ballot language:

4.9.1.1 Reasons for Revoking a Subscriber Certificate

Replace:

4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys)

With:

4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key (such as those identified in 6.1.1.3(4)).

---

6.1.1.3. Subscriber Key Pair Generation

Replace:

The CA SHALL reject a certificate request if one or more of the following conditions are met:

1. The Key Pair does not meet the requirements set forth in Section 6.1.5 and/or Section 6.1.6;
2. There is clear evidence that the specific method used to generate the Private Key was flawed;
3. The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise;
4. The CA has previously been made aware that the Applicant's Private Key has suffered a Key Compromise, such as through the provisions of Section 4.9.1.1;
5. The CA is aware of a demonstrated or proven method to easily compute the Applicant's Private Key based on the Public Key (such as a Debian weak key, see https://wiki.debian.org/SSLkeys).

With:

The CA SHALL reject a certificate request if one or more of the following occurs:

1) The requested Public Key does not meet the requirements set forth in Sections 6.1.5 and/or 6.1.6;
2) The CA is aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise;
3) The CA has previously been made aware that the Subscriber's Private Key has suffered a Key Compromise, such as through the provisions of Section 4.9.1.1;
4) The Public Key corresponds to an industry demonstrated weak Private Key, in particular:

a) 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.
b) In the case of Debian weak keys (https://wiki.debian.org/SSLkeys), the CA SHALL reject at least keys generated by the flawed OpenSSL version with the combination of the following parameters:

i) Big-endian 32-bit, little-endian 32-bit, and little-endian 64-bit architecture;
ii) Process ID of 0 to 32767, inclusive;
iii) All RSA Public Key lengths supported by the CA up to and including 4096 bits;
iv) rnd, nornd, and noreadrnd OpenSSL random file state.

c) In the case of Close Primes vulnerability, the CA SHALL reject weak keys identified within 100 rounds using Fermat’s factorization method

For Debian weak keys not covered above, the CA SHALL take actions to minimize the probability of certificate issuance.

CAs MUST check for Debian weak keys for all RSA modulus lengths and exponents that they accept.

Suggested tools that CAs MAY use to obtain lists of Debian weak keys include:

  - https://github.com/CVE-2008-0166 provides a generator, for the complete set of parameters listed above, that runs on any modern 64-bit Linux system; it also provides complete sets of pregenerated keys for the most common RSA key sizes.
  - https://github.com/HARICA-official/debian-weak-keys provides a generator, for a subset of the parameters listed above, that can take advantage of a computer cluster.

--- Motion Ends ---

________________________________
From: Chris Kemmerer
Sent: Wednesday, June 8, 2022 6:41 AM
To: CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: SCXX Ballot - Debian Weak Keys (and related vulnerabilities)

Hello,

To forestall confusion, we are presenting the full text of our proposed ballot in this new thread. This draft includes the latest modifications to include references to useful tools for Debian weak key handling and Martijn's suggested language regarding the Fermat attack.

Many thanks to all who've contributed.

Chris K

--- Motion Begins ---

This ballot is intended to clarify CA responsibilities regarding weak key vulnerabilities, including specific guidance for Debian weak key, ROCA and Fermat attack vulnerabilities, and modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based on Version 1.8.4:

This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based on Version 1.7.4:

Proposed ballot language:

4.9.1.1 Reasons for Revoking a Subscriber Certificate

Replace:

4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key based on the Public Key in the Certificate (such as a Debian weak key, see https://wiki.debian.org/SSLkeys)

With:

4. The CA is made aware of a demonstrated or proven method that can easily compute the Subscriber’s Private Key (such as those identified in 6.1.1.3(4)).

---

6.1.1.3. Subscriber Key Pair Generation

Replace:

The CA SHALL reject a certificate request if one or more of the following conditions are met:

1. The Key Pair does not meet the requirements set forth in Section 6.1.5 and/or Section 6.1.6;
2. There is clear evidence that the specific method used to generate the Private Key was flawed;
3. The CA is aware of a demonstrated or proven method that exposes the Applicant's Private Key to compromise;
4. The CA has previously been made aware that the Applicant's Private Key has suffered a Key Compromise, such as through the provisions of Section 4.9.1.1;
5. The CA is aware of a demonstrated or proven method to easily compute the Applicant's Private Key based on the Public Key (such as a Debian weak key, see https://wiki.debian.org/SSLkeys).

With:

The CA SHALL reject a certificate request if one or more of the following occurs:

1) The requested Public Key does not meet the requirements set forth in Sections 6.1.5 and/or 6.1.6;
2) The CA is aware of a demonstrated or proven method that exposes the Subscriber's Private Key to compromise;
3) The CA has previously been made aware that the Subscriber's Private Key has suffered a Key Compromise, such as through the provisions of Section 4.9.1.1;
4) The Public Key corresponds to an industry demonstrated weak Private Key, in particular:
a) 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.
b) In the case of Debian weak keys (https://wiki.debian.org/SSLkeys), the CA SHALL reject at least keys generated by the flawed OpenSSL version with the combination of the following parameters:
c) In the case of Close Primes vulnerability, the CA SHALL reject weak keys identified within 100 rounds using Fermat’s factorization method

i) Big-endian 32-bit, little-endian 32-bit, and little-endian 64-bit architecture;
ii) Process ID of 0 to 32767, inclusive;
iii) All RSA Public Key lengths supported by the CA up to and including 4096 bits;
iv) rnd, nornd, and noreadrnd OpenSSL random file state.

For Debian weak keys not covered above, the CA SHALL take actions to minimize the probability of certificate issuance.

CAs MUST check for Debian weak keys for all RSA modulus lengths and exponents that they accept.

Suggested tools that CAs MAY use to obtain lists of Debian weak keys include:

  - https://github.com/CVE-2008-0166 provides a generator, for the complete set of parameters listed above, that runs on any modern 64-bit Linux system; it also provides complete sets of pregenerated keys for the most common RSA key sizes.
  - https://github.com/HARICA-official/debian-weak-keys provides a generator, for a subset of the parameters listed above, that can take advantage of a computer cluster.

--- Motion Ends ---
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20220608/044a0a65/attachment.html>