[Servercert-wg] Updating BR 6.1.1.3

[Corey Bonnell]

> Yes, sometimes requirements for CAs mean they can't just take the lazy way out, but I don't think that in any way changes the expectations. I'm particularly keen to avoid the irrational demarcation between methods that are 'easy'
> and methods that are 'hard' and to somehow suggest that methods that
> are 'hard' allow the CA to take shortcuts. This is especially unreasonable when, as you note, a variety of means exist at the CA's disposal to make these computations easy, including the most obvious, precomputation.

As described in my previous message, implementation of the "algorithm" requires precomputation of an incredible number of tables, the vast majority of which must be generated on moribund hardware of questionable availability.

> The assumption here is flawed, which is somehow that CAs must support
> these, and must support these with precomputed tables. The reality is that this is a set of tradeoffs here for how a CA can meet their obligations, and suggesting that "foolish implementation A, which ignores all constraints" is
> somehow proof that the expectation is unreasonable is not convincing. Yes, we can construct strawman implementations that fail to make the tradeoff.

Not strawmen, and not foolish. The allowed set of exponents (and other restrictions in section 6.1.6) are informed from NIST guidance, which explicitly allows for exponents to be generated randomly within the range of exponents recommended in section 6.1.6. I pointed to several open-source implementations that would require an astronomical number of tables such that even with parallelizing the effort, would take billions and billions of years to generate.

Additionally, the previous remediations accepted by the Root Programs for CAs not flagging Debian weak keys in the openssl-blacklist blocklists has been for these CAs to check for weak keys enumerated within that package. Nowhere in the associated discussions were the allowed set of modulus lengths, exponents, or platforms to be checked by the CA brought up. This precedent, coupled with the analysis in the previous message and above, would suggest that the current expectation is for CAs to check for those keys within the openssl-blacklist package.

Thanks,
Corey
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.