[Servercert-wg] Updating BR 6.1.1.3

[Ryan Sleevi]

On Thu, Apr 9, 2020 at 4:45 PM Corey Bonnell <CBonnell at securetrust.com>
wrote:

> 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.
>
> I disagree. We point to the algorithm for determining a Debian weak key. A
CA should be capable of determining whether or not that particular key
meets that requirement. I think a similar discussion would be related to
ROCA and which primes the CA has to consider.


>
>    1.
>    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.
>
> But there are always trade-offs. If the CA can't support a key size
securely, not issuing seems like a reasonable path.

>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://cabforum.org/pipermail/servercert-wg/attachments/20200409/cc3a9cc8/attachment-0001.html>