[Servercert-wg] SCXX Ballot proposal: Debian Weak keys

[Christopher Kemmerer]

Purpose of ballot:

We believe that there is a need to clarify the set of Debian weak keys 
that are relevant to the Web PKI and that CAs are expected to reject. To 
this end, we have 1) updated 6.1.1.3 to more precisely define them, 
instead of just deferring to https://wiki.debian.org/SSLkeys, and 2) 
included a cutoff point regarding the key length.

More specifically, we believe that for key length greater than 4096 
bits, we enter an area of diminishing returns. This proposed cutoff 
point takes into account the antiquity of the vulnerable Debian 
environment, the lack of meaningful probability of users creating and 
using keys of greater length in this environment, and the amount of 
computational effort required to generate complete Debian weak key sets 
with such key lengths (in the various combinations). Even so, in an 
abundance of caution, we have included a clause to force CAs to take 
some action when they offer certificates with greater key lengths. That 
action could include requesting information from the subscriber about 
the circumstances under which the keys were generated, using a 
probabilistic mechanism that can detect the most common cases or even 
banning certain key lengths.

Other changes as part of the proposed language:

• New clause for the detection of weak keys that are affected by the 
ROCA vulnerability
• Updated 4.9.1.1(4) to point to 6.1.1.3(4), which tries to more 
generally deal with “weak” keys.
• Removal of “based on the Public Key in the Certificate” from 
4.9.1.1(4), in order to make it more general. If a Private Key can be 
easily computed, it shouldn’t matter how it’s done.
• Change of “Key Pair” to “requested Public Key” in 6.1.1.3(1); since 
the CA doesn’t have access to the Private Key this seems more precise.
• Removal of 6.1.1.3(2); we believe that it is covered by 6.1.1.3(3).

This motion is made by Chris Kemmerer of SSL.com and we are seeking two 
endorsers.


--- Motion Begins ---


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

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.

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

--- Motion Ends ---

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20201210/272819e8/attachment.html>