[Servercert-wg] Updating BR 6.1.1.3

[Ryan Sleevi]

On Wed, Apr 8, 2020 at 2:08 PM Corey Bonnell <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) 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, 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.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200408/563bb150/attachment.html>