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

Corey Bonnell CBonnell at securetrust.com
Fri Sep 4 11:30:39 MST 2020 

Hi Chris,

I am curious why the clause on exponents as seen on the previous version of the draft (https://archive.cabforum.org/pipermail/servercert-wg/2020-May/001954.html) was removed, as I believe it is a useful clarification alongside the modulus lengths.

 

Additionally, for the list of architectures, my understanding is that different architectures may yield a separate set of keys (https://archive.cabforum.org/pipermail/servercert-wg/2020-April/001846.html) due to different word widths/widths of the pid_t type and endianness. Several of the architectures listed are moribund, which makes this an increasingly challenging requirement for CAs as hardware becomes increasingly rare. Given this, it may be desirable to target a few of the architectures in common use at the time of the vulnerability and restrict to those.

 

Thanks,

Corey

 

From: Servercert-wg <servercert-wg-bounces at cabforum.org> On Behalf Of Christopher Kemmerer via Servercert-wg
Sent: Thursday, September 3, 2020 10:48 AM
To: Doug Beattie via Servercert-wg <servercert-wg at cabforum.org>
Subject: [Servercert-wg] Proposed ballot: Minimum expectations regarding weak keys

 

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 <https://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxZwSuiVmgg&s=5&u=https%3a%2f%2fgithub%2ecom%2fcabforum%2fdocuments%2fpull%2f208> ). 

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 <http://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxclAunBhgA&s=5&u=http%3a%2f%2fSSL%2ecom> 

=====

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 <https://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxcwTuiRi0A&s=5&u=https%3a%2f%2fwiki%2edebian%2eorg%2fSSLkeys> ). 

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 <https://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxZkSvSE73w&s=5&u=https%3a%2f%2fgithub%2ecom%2fcrocs-muni%2froca>  or equivalent. 

(ii) In the case of Debian weak keys (https://wiki.debian.org/SSLkeys <https://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxcwTuiRi0A&s=5&u=https%3a%2f%2fwiki%2edebian%2eorg%2fSSLkeys> ), 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 <http://scanmail.trustwave.com/?c=4062&d=noLR3_BuS9Qf2sEvxoUDMtcjwAl0vJFtxclAunBhgA&s=5&u=http%3a%2f%2fSSL%2ecom> 
 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~~~ To find the reefs, look~~~~~~~~
~~~~     for the wrecks.    ~~~~~~~~~
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200904/0190a78b/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4947 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200904/0190a78b/attachment-0001.p7s>

More information about the Servercert-wg mailing list