[Servercert-wg] Updating BR 6.1.1.3

[Corey Bonnell]

While the requirement for CAs to pre-compute blocklists for all RSA key sizes that they support is definitely worthy of consideration and discussion, I don’t believe that aligns with the current interpretation of the requirement to reject weak Debian keys for two reasons:


  1.  The Debian project selected the key sizes in openssl-blacklist (and the SSH counterpart blocklists, etc.) to represent the sizes that their users would commonly use and that they determined by blocking would provide protection for their users. CAs that block these same keys are implementing the same set of safeguards that the Debian maintainers have determined as appropriate for their own users. Going above and beyond what the Debian project currently has available for its own users’ security is worth a discussion, but I don’t believe that is the current expectation.
  2.  By mandating that CAs must pre-compute blocklists for all supported key sizes, it becomes increasingly computationally expensive to support the array of key sizes currently supported today by CAs and especially larger keys, such as 16384 bits. If we believe that pre-generating these lists is a requirement prior to supporting a given key length, then we are essentially setting the upper bound (as determined by CAs’ computing power) on allowed key sizes for the web PKI to satisfy checking for a vulnerability that was patched 12 years ago, a time when much smaller keys were predominant.

As an aside, it was pointed out to me privately that the language I proposed yesterday didn’t account for the rnd/nornd/noreadrnd random file states, so as an addendum to my proposed ballot text:
d.            rnd, nornd, and noreadrnd OpenSSL random file state

Thanks,
Corey

From: Ryan Sleevi <sleevi at google.com>
Sent: Wednesday, April 8, 2020 2:38 PM
To: Corey Bonnell <CBonnell at securetrust.com>
Cc: Christopher Kemmerer <chris at ssl.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Updating BR 6.1.1.3



On Wed, Apr 8, 2020 at 2:08 PM Corey Bonnell <CBonnell at securetrust.com<mailto:CBonnell at securetrust.com>> wrote:
Thinking about this further, we should shy away from normatively specifying a package/dataset that is susceptible to change or removal. In others words, how does a CA determine what the requirements are if that Debian package is no longer available? I think that describing the minimum dataset requirements directly in the BRs would be preferable so that those requirements are not modified or lost when the external content inevitably changes.

With that in mind, my proposed language for 6.1.1.3 is as follows:
The CA SHALL reject a certificate request if the requested Public Key does not meet the requirements set forth in Sections 6.1.5 and 6.1.6 or if it has a known weak Private Key.

Lists of Debian weak keys (https://wiki.debian.org/SSLkeys<https://scanmail.trustwave.com/?c=4062&d=mpqO3gqSxD3FvVo-1hF7a0NVApG35Vra0d7K6Tg45Q&s=5&u=https%3a%2f%2fwiki%2edebian%2eorg%2fSSLkeys>) with the following parameters are considered to be known weak Private Keys and MUST be rejected by the CA:

a.       Big-endian 32-bit, little-endian 32-bit, and little-endian 64-bit architecture;

b.       Process ID of 0 to 32767, inclusive; and

c.       RSA Public Key length of 2048 and 4096 bits.
Thanks for raising this Corey.

I agree that an objective-based outcome is a far better approach. It also addresses the concern I had previously raised, where historically the 4096-bit keys were part of the openssl-blacklist-extra package, although as you pointed out, this was thankfully folded into the same source repository. My only concern is that I don't think limiting to 2048 or 4096-bit is sufficient; that weakens the existing requirement/expectation.

The process for determining whether or not a key is weak is published - right there on that page. The expectation is that, for a given key size, the CA has a process to determine if it's part of the set for all architectures and process IDs.  This results in language like:

Weak keys generated by Debian systems vulnerable to CVE-2008-0166, as described at https://wiki.debian.org/SSLkeys<https://scanmail.trustwave.com/?c=4062&d=mpqO3gqSxD3FvVo-1hF7a0NVApG35Vra0d7K6Tg45Q&s=5&u=https%3a%2f%2fwiki%2edebian%2eorg%2fSSLkeys>, are considered to be known weak Private Keys and MUST be rejected by the CA. At minimum, the CA MUST block keys of the requested RSA Public Key length that have been generated by the openssl utility on big-endian 32-bit, little-endian 32-bit, and little-endian 64-bit architectures, and for process IDs 0 to 32767, inclusive.

If a CA only accepts 2048 / 4096-bit keys, then this is equivalent to what you wrote. If a CA accepts 3072-bit keys, for example, then they're responsible for determining the set of keys and blocking them appropriately.
This transmission may contain information that is privileged, confidential, and/or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of the information contained herein (including any reliance thereon) is STRICTLY PROHIBITED. If you received this transmission in error, please immediately contact the sender and destroy the material in its entirety, whether in electronic or hard copy format.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200409/97f9ab13/attachment.html>