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

Thu Sep 3 09:48:50 MST 2020

I think the ROCA vulnerability shows pretty clearly that even generation by secure hardware can have its issues, so I think it’s premature to attempt to shut down the discussion by pointing to all the pomp and ceremony around ICA generation.

-Tim

From: Ryan Sleevi <sleevi at google.com> 
Sent: Thursday, September 3, 2020 12:45 PM
To: Tim Hollebeek <tim.hollebeek at digicert.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Cc: Christopher Kemmerer <chris at ssl.com>
Subject: Re: [Servercert-wg] Proposed ballot: Minimum expectations regarding weak keys

Tim,

While in principle, I agree that it would be extremely unfortunate, I don't see the same gap as you. That is, it seems like that's an issue already controlled for with respect to key generation and protection requirements. Could you more concretely describe (perhaps using past issues, i.e. those that CAs would be looking for) a scenario that would make it through the existing controls?

As you note, the fact that these are not Subscriber keys is extremely relevant: the CA has controls (for self-generated) and assurances (for 3P CA generated, via audit reports and the requirements) on key generation that don't apply to Subscriber certs. As such, I'm having trouble seeing the same risk, and if there is any (from Roots or Sub CAs), it seems like we can and should tackle that through the ceremonies/generation time, rather than at signing time. So I don't support tweaking this for ICAs, now or in the future, but am open to understanding more about the problems you see, so we can look for a more systemic fix, if the existing controls aren't sufficient.

On Thu, Sep 3, 2020 at 12:33 PM Tim Hollebeek via Servercert-wg <servercert-wg at cabforum.org <mailto:servercert-wg at cabforum.org> > wrote:

One of the things we’ve noticed before is the fact that these requirements are in the section for Subscriber keys, therefore there are no weak key check requirements for roots and ICAs.

We think that’s worth fixing.  If CAs have to implement these checks for subscriber certificates, it should be pretty straightforward to run these checks when creating ICAs as well.

The requirements for ICAs may need some tweaking, since there are some substantial differences in use cases, but I wanted to find out if there is any interest from others on fixing this loophole as well, either in this ballot or another one.

It would be extremely unfortunate if a certification authority issued an ICA with a key that is known to be compromised, for example.

-Tim

From: Servercert-wg <servercert-wg-bounces at cabforum.org <mailto: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 <mailto: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). 

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

_______________________________________________
Servercert-wg mailing list
Servercert-wg at cabforum.org <mailto:Servercert-wg at cabforum.org> 
https://lists.cabforum.org/mailman/listinfo/servercert-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200903/b29a92bd/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4940 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20200903/b29a92bd/attachment-0001.p7s>