<html>
<head>
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Greetings,<br>
<br>
We propose the following amendments to language in the CA/B Forum
in Baseline Requirements, taking into account the proposed changes
from SC35: Cleanups and Clarifications (as documented in
<a class="moz-txt-link-freetext" href="https://github.com/cabforum/documents/pull/208">https://github.com/cabforum/documents/pull/208</a>). <br>
<br>
The purpose of this ballot is to set minimum expectations for CAs
regarding industry-proven methods to generate weak private keys,
and more specifically to ROCA and Debian weak keys. This topic was
discussed in m.d.s.p. on several occasions and in various CA
public incidents.<br>
<br>
Regards,<br>
<br>
Chris Kemmerer<br>
SSL.com<br>
<br>
=====<br>
<br>
Proposed ballot language:<br>
<br>
</p>
<p>4.9.1.1 Reasons for Revoking a Subscriber Certificate <br>
</p>
<p><br>
<b>Replace: </b><br>
<br>
The CA SHALL revoke a Certificate within 24 hours if one or more
of the following occurs: <br>
<br>
[…] <br>
<br>
11. The CA is made aware of a demonstrated or proven method that
exposes the Subscriber's Private Key to compromise or if there is
clear evidence that the specific method used to generate the
Private Key was flawed. <br>
<br>
<b>With </b><br>
<br>
<br>
The CA SHALL revoke a Certificate within 24 hours if one or more
of the following occurs: <br>
<br>
[…] <br>
<br>
11. The CA is made aware of a demonstrated or proven method that
exposes the Subscriber's Private Key to compromise; <br>
<br>
12. There is clear evidence that the specific method used to
generate the Private Key was flawed; or <br>
<br>
13. The certificate was issued with a weak key (such as a Debian
weak key, see 6.1.1.3). <br>
<br>
--- <br>
<br>
6.1.1.3. Subscriber Key Pair Generation <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>
The Key Pair does not meet the requirements set forth in Section
6.1.5 and/or Section 6.1.6; <br>
<br>
There is clear evidence that the specific method used to generate
the Private Key was flawed; <br>
<br>
The CA is aware of a demonstrated or proven method that exposes
the Applicant's Private Key to compromise; <br>
<br>
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>
<br>
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>
If the Subscriber Certificate will contain an extKeyUsage
extension containing either the values id-kp-serverAuth [RFC5280]
or anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key
Pair on behalf of a Subscriber, and SHALL NOT accept a certificate
request using a Key Pair previously generated by the CA. <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>
<br>
2. The CA is aware of a demonstrated or proven method that exposes
the Subscriber's Private Key to compromise; <br>
<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>
<br>
4. It has an industry demonstrated weak Private Key, in
particular: <br>
<br>
(i) 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>
<br>
(ii) 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 following
parameters: <br>
a. Architectures supported by the flawed Debian distribution
(alpha, arm, armel, hppa, i386, amd64, ia64, mips, mipsel,
powerpc, s390, sparc); <br>
b. Process ID of 0 to 32767, inclusive; <br>
c. All RSA Public Key lengths supported by the CA up to and
including 4096 bits; <br>
d. rnd, nornd, and noreadrnd OpenSSL random file state; <br>
For Debian weak keys not covered above, the CA SHALL take actions
to minimize the probability of certificate issuance. <br>
<br>
If the Subscriber Certificate will contain an extKeyUsage
extension containing either the values id-kp-serverAuth [RFC5280]
or anyExtendedKeyUsage [RFC5280], the CA SHALL NOT generate a Key
Pair on behalf of a Subscriber, and SHALL NOT accept a certificate
request using a Key Pair previously generated by the CA. <br>
<br>
=====<br>
</p>
<pre class="moz-signature" cols="72">--
Chris Kemmerer
Manager of Operations
SSL.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~ To find the reefs, look~~~~~~~~
~~~~ for the wrecks. ~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~</pre>
</body>
</html>