[Servercert-wg] Proposed ballot: Minimum expectations regarding weak keys

[Christopher Kemmerer]

Greetings,

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 
https://github.com/cabforum/documents/pull/208).

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.

Regards,

Chris Kemmerer
SSL.com

=====

Proposed ballot language:

4.9.1.1 Reasons for Revoking a Subscriber Certificate


*Replace: *

The CA SHALL revoke a Certificate within 24 hours if one or more of the 
following occurs:

[…]

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.

*With *


The CA SHALL revoke a Certificate within 24 hours if one or more of the 
following occurs:

[…]

11. The CA is made aware of a demonstrated or proven method that exposes 
the Subscriber's Private Key to compromise;

12. There is clear evidence that the specific method used to generate 
the Private Key was flawed; or

13. The certificate was issued with a weak key (such as a Debian weak 
key, see 6.1.1.3).

---

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:

The Key Pair does not meet the requirements set forth in Section 6.1.5 
and/or Section 6.1.6;

There is clear evidence that the specific method used to generate the 
Private Key was flawed;

The CA is aware of a demonstrated or proven method that exposes the 
Applicant's Private Key to compromise;

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;

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

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.

*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. It has an industry demonstrated weak Private Key, in particular:

(i) 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.

(ii) 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 following parameters:
   a. Architectures supported by the flawed Debian distribution (alpha, 
arm, armel, hppa, i386, amd64, ia64, mips, mipsel, powerpc, s390, sparc);
   b. Process ID of 0 to 32767, inclusive;
   c. All RSA Public Key lengths supported by the CA up to and including 
4096 bits;
   d. 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.

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.

=====

-- 
Chris Kemmerer
Manager of Operations
SSL.com

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~ To find the reefs, look~~~~~~~~
~~~~     for the wrecks.    ~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200903/d5c943d8/attachment-0001.html>