<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Purpose of ballot:<br>
<br>
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
<a class="moz-txt-link-freetext" href="https://wiki.debian.org/SSLkeys">https://wiki.debian.org/SSLkeys</a>, and 2) included a cutoff point
regarding the key length.<br>
<br>
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.<br>
<br>
Other changes as part of the proposed language:<br>
<br>
• New clause for the detection of weak keys that are affected by
the ROCA vulnerability<br>
• Updated 4.9.1.1(4) to point to 6.1.1.3(4), which tries to more
generally deal with “weak” keys.<br>
• 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.<br>
• 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.<br>
• Removal of 6.1.1.3(2); we believe that it is covered by
6.1.1.3(3).<br>
<br>
This motion is made by Chris Kemmerer of SSL.com and we are
seeking two endorsers.<br>
<br>
<br>
--- Motion Begins ---<br>
<br>
<br>
This ballot modifies the “Baseline Requirements for the Issuance
and Management of Publicly-Trusted Certificates” as follows, based
on Version 1.7.3:<br>
<br>
Proposed ballot language:<br>
<br>
<b>4.9.1.1 Reasons for Revoking a Subscriber Certificate</b><br>
<br>
<b>Replace:</b><br>
<br>
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
<a class="moz-txt-link-freetext" href="https://wiki.debian.org/SSLkeys">https://wiki.debian.org/SSLkeys</a>)<br>
<br>
<b>With:</b><br>
<br>
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)).<br>
<br>
---<br>
<br>
<b>6.1.1.3. Subscriber Key Pair Generation</b><br>
<br>
<b>Replace:</b><br>
<br>
The CA SHALL reject a certificate request if one or more of the
following conditions are met:<br>
<br>
1. The Key Pair does not meet the requirements set forth in
Section 6.1.5 and/or Section 6.1.6;<br>
2. There is clear evidence that the specific method used to
generate the Private Key was flawed;<br>
3. The CA is aware of a demonstrated or proven method that exposes
the Applicant's Private Key to compromise;<br>
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;<br>
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 <a class="moz-txt-link-freetext" href="https://wiki.debian.org/SSLkeys">https://wiki.debian.org/SSLkeys</a>).<br>
<br>
<b>With:</b><br>
<br>
The CA SHALL reject a certificate request if one or more of the
following occurs:<br>
<br>
1) The requested Public Key does not meet the requirements set
forth in Sections 6.1.5 and/or 6.1.6;<br>
2) The CA is aware of a demonstrated or proven method that exposes
the Subscriber's Private Key to compromise;<br>
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;<br>
4) The Public Key corresponds to an industry demonstrated weak
Private Key, in particular:<br>
a) In the case of ROCA vulnerability, the CA SHALL reject keys
identified by the tools available at
<a class="moz-txt-link-freetext" href="https://github.com/crocs-muni/roca">https://github.com/crocs-muni/roca</a> or equivalent.<br>
b) In the case of Debian weak keys
(<a class="moz-txt-link-freetext" href="https://wiki.debian.org/SSLkeys">https://wiki.debian.org/SSLkeys</a>), the CA SHALL reject at least
keys generated by the flawed OpenSSL version with the combination
of the following parameters:<br>
<br>
i) Big-endian 32-bit, little-endian 32-bit, and little-endian
64-bit architecture;<br>
ii) Process ID of 0 to 32767, inclusive;<br>
iii) All RSA Public Key lengths supported by the CA up to and
including 4096 bits;<br>
iv) rnd, nornd, and noreadrnd OpenSSL random file state.<br>
<br>
For Debian weak keys not covered above, the CA SHALL take actions
to minimize the probability of certificate issuance.<br>
<br>
--- Motion Ends ---</p>
</body>
</html>