[Servercert-wg] Updating BR 6.1.1.3

Wed Apr 8 11:08:48 MST 2020

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

Thoughts?

Thanks,
Corey

From: Christopher Kemmerer <chris at ssl.com>
Sent: Wednesday, April 8, 2020 1:10 PM
To: Corey Bonnell <CBonnell at securetrust.com>; Ryan Sleevi <sleevi at google.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

We would not object to further clarifying our proposed language, possibly to something like the following:

"The minimum set for the Debian weak keys can be found at https://sources.debian.org/data/main/o/openssl-blacklist/0.5-3/<https://scanmail.trustwave.com/?c=4062&d=6YWO3vBesoJCTkYPwwXewWXAhBsQKL31KhzFzGXjTA&s=5&u=https%3a%2f%2fsources%2edebian%2eorg%2fdata%2fmain%2fo%2fopenssl-blacklist%2f0%2e5-3%2f> and MUST include at least lists containing 2048 and 4096 bit keys."

Chris
On 4/7/2020 3:23 PM, Corey Bonnell wrote:
Hi Ryan,
The openssl-blacklist package referenced in Chris’s draft ballot text contains hashes for 4096 bit keys, for example: https://sources.debian.org/data/main/o/openssl-blacklist/0.5-3/blacklists/le64/blacklist-4096.db<https://scanmail.trustwave.com/?c=4062&d=6YWO3vBesoJCTkYPwwXewWXAhBsQKL31Kh6fwTXgHw&s=5&u=https%3a%2f%2fsources%2edebian%2eorg%2fdata%2fmain%2fo%2fopenssl-blacklist%2f0%2e5-3%2fblacklists%2fle64%2fblacklist-4096%2edb>. Or were you referring to something else?

While we’re on the topic of blocklisting known bad Debian keys, what is the expectation on CA’s for blocking larger key sizes, such as 8192 or 16384? AFAIK there is no publicly available distribution that contains hashes of keys this large and pre-computing them is a rather… expensive operation. According to censys.io,<http://scanmail.trustwave.com/?c=4062&d=6YWO3vBesoJCTkYPwwXewWXAhBsQKL31KkyRwTTnTg&s=5&u=http%3a%2f%2fcensys%2eio> there’s ~3700 currently trusted certificates (including pre-cert/final cert dupes) with RSA key length of 8192 bits (https://censys.io/certificates?q=%28parsed.subject_key_info.rsa_public_key.length%3A+8192%29+AND+tags.raw%3A+%22trusted%22&<https://scanmail.trustwave.com/?c=4062&d=6YWO3vBesoJCTkYPwwXewWXAhBsQKL31KkGQwDPjEg&s=5&u=https%3a%2f%2fcensys%2eio%2fcertificates%3fq%3d%2528parsed%2esubject%5fkey%5finfo%2ersa%5fpublic%5fkey%2elength%253A%2b8192%2529%2bAND%2btags%2eraw%253A%2b%2522trusted%2522%26>) and only 13 certs with 16384 bit key length (https://censys.io/certificates?q=%28parsed.subject_key_info.rsa_public_key.length%3A+16384%29+AND+tags.raw%3A+%22trusted%22<https://scanmail.trustwave.com/?c=4062&d=6YWO3vBesoJCTkYPwwXewWXAhBsQKL31KkmWwmGxGQ&s=5&u=https%3a%2f%2fcensys%2eio%2fcertificates%3fq%3d%2528parsed%2esubject%5fkey%5finfo%2ersa%5fpublic%5fkey%2elength%253A%2b16384%2529%2bAND%2btags%2eraw%253A%2b%2522trusted%2522>). Given the low certificate counts and the elapsed time between when openssl was patched for this vulnerability and now (~12 years), I’d be inclined to think anything above 4096 is a “don’t care” case but I’d think it would be good to explicitly mention that in the ballot so that deviations in expectations/interpretations do not occur.

Thanks,
Corey

From: Servercert-wg <servercert-wg-bounces at cabforum.org><mailto:servercert-wg-bounces at cabforum.org> On Behalf Of Ryan Sleevi via Servercert-wg
Sent: Tuesday, April 7, 2020 3:18 PM
To: Christopher Kemmerer <chris at ssl.com><mailto:chris at ssl.com>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg at cabforum.org><mailto:servercert-wg at cabforum.org>
Subject: Re: [Servercert-wg] Updating BR 6.1.1.3

Chris,

You can see that I'm already proposing changes to this section in https://github.com/sleevi/cabforum-docs/pull/12<https://scanmail.trustwave.com/?c=4062&d=6YWO3vBesoJCTkYPwwXewWXAhBsQKL31Kk6QwDDtEg&s=5&u=https%3a%2f%2fgithub%2ecom%2fsleevi%2fcabforum-docs%2fpull%2f12>

I notice that you excluded the set of 4096-bit keys. Was that intentional?
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.

--

Chris Kemmerer

Manager of Operations

SSL.com<http://scanmail.trustwave.com/?c=4062&d=6YWO3vBesoJCTkYPwwXewWXAhBsQKL31KkvAxWG2TA&s=5&u=http%3a%2f%2fSSL%2ecom>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

~~~~~ To find the reefs, look~~~~~~~~

~~~~     for the wrecks.    ~~~~~~~~~

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/20200408/543ebf20/attachment-0001.html>