[Servercert-wg] SCXX Ballot proposal: Debian Weak keys

[Jacob Hoffman-Andrews]

Thanks for your continued efforts to improve this part of the BRs! Let's
Encrypt is in theory interested in endorsing, but I think it still needs a
bit of work. Thanks for incorporating my most recent comments on endianness
and word size vs 11 platforms.

Goals: We want CAs to consistently not issue certificates for weak keys in
general, and also in the specific case of Debian and ROCA keys. We want the
definition of Debian and ROCA keys to be clear and actionable for as long
as possible - say, at least twenty years.

We have three ways to specify Debian and ROCA keys: With a list, with a
tool, or with an algorithm*. The original revision of this ballot proposed
to use a list (
https://lists.cabforum.org/pipermail/servercert-wg/2020-April/001821.html).
There were two objections:

 - The list (openssl-blacklist) is subject to change or removal.
 - The list only covers 2048 and 4096 bit keys.

The current draft proposes specifying a tool for ROCA (
https://github.com/crocs-muni/roca) and an algorithm for Debian keys.

The ROCA tool is subject to change or removal, just like the
openssl-blacklist package. I propose we instead specify ROCA detection in
terms of the paper (https://crocs.fi.muni.cz/public/papers/rsa_ccs17) and
ask for permission from the authors to archive an unchanging copy as an
addendum to the BRs.

For Debian keys, what looks like an algorithm specification is actually a
tool + algorithm specification. The tool is "OpenSSL 0.9.8c-1 up to
versions before 0.9.8g-9 on Debian-based operating systems" (per
CVE-2008-01666 - https://cve.mitre.org/cgi-bin/cvename.cgi?name=2008-0166).
To ensure an unchanging copy of that, we should archive 3 copies of Debian,
for the 3 word size + endianness combinations.

The algorithm also needs an additional line: "v) using the command 'openssl
req -nodes -subj / -newkey rsa:<Public Key length>'" (adapted from
https://sources.debian.org/data/main/o/openssl-blacklist/0.5-3/examples/gen_certs.sh).
Other tools that linked OpenSSL, like openvpn and openssh, generated
different sets of keys. We can include or exclude openvpn and openssh keys,
but should thoroughly specify.

Lastly, I think we should archive openssl-blacklist, and include in the
BRs: "A CA may reject the full set of Debian weak keys by rejecting this
superset of the Debian weak keys:

 - All RSA public keys with modulus lengths other than 2048 or 4096, and
 - All RSA public keys with exponents other than 65537, and
 - All RSA public keys that are detected as vulnerable by the
openssl-vulnkey program in the openssl-blacklist package version 0.5-3 (see
addendum), or an equivalent program."

My reasoning: Given the difficulty of correctly setting up old Debian
versions and generating weak keys for sizes that are not part of
openssl-blacklist, I expect most CAs will choose this path. Given that, we
should just say what we mean: the pregenerated list is fine if you restrict
key sizes, but you don't *have* to restrict key sizes, so long as you have
an alternate method to ensure you're not issuing for Debian weak keys at
other sizes.

*I'm considering specifying an algorithm to be functionally equivalent to
specifying an "outcome," though I recognize this may be too hand-wavy.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20201211/a909175d/attachment.html>