[Servercert-wg] Compromised/Weak Keys Ballot Proposal

[Wayne Thayer]

Hi Clint,

Thank you for your response. Unfortunately, it leads me to the conclusion
that there is not a path forward and we're stuck with the status quo.
Having said that, I'll reply to a few of your points below and encourage
others to do the same if there is a desire to move forward with an update
to our weak keys requirements.

On Thu, Mar 7, 2024 at 12:59 AM Clint Wilson <clintw at apple.com> wrote:

> Hi Wayne,
>
> Thank you for carrying this work item forward. I have a few concerns
> regarding the proposed removal of Debian weak key checking, outlined below.
>
> I don’t believe there has been sufficient explanation or data presented to
> justify the removal of the requirement to check for Debian weak keys. It
> seems to me there are feasible methods for CAs to continue performing this
> check. Similar to what Martijn has pointed out, the reasoning provided is
> lacking (hasty generalization, fallacy of composition, etc.).
>

The argument that I find compelling is that any system capable of
generating a Debian weak key in 2024 is also riddled with a decade of
vulnerabilities, so preventing the use of said weak key in a certificate is
security theater. In what scenario do you envision the rejection of a
Debian weak key having a meaningful impact on the security of a service
that relies on it? It's just not obvious to me that these checks continue
to provide any practical value at this point in time.


> I don’t believe a compromise where Debian weak keys only need be checked
> for specific key sizes addresses the core issue, unless tied together with
> a restriction from accepting key sizes which are not included in such a
> list (which I do see as reasonable and something I’m under the impression
> is already being done by some CAs).
>

My understanding is that the objections some CAs had to the original ballot
was the requirement to maintain a sizable database of Debian weak keys for
every key size they support. Limiting the requirement to the most popular
key sizes would resolve that issue and be more inline with my understanding
of some current practices. This approach would also greatly reduce the
threat of the accidental use of a Debian weak key.


> The removal of this check seems to shift a burden currently placed on CAs
> to a risk (long assumed resolved) for Relying Parties and Subscribers. From
> my reading of the ballot, the requirement that a CA revoke Certificates
> with Debian weak keys remains in effect, serving only to remove the
> pre-issuance “blocking” requirement, but retaining an expectation that
> certificates are checked post-issuance based on the CA’s awareness of this
> method of compromising a Private Key; this generally seems a significantly
> worse experience for Subscribers. Have I missed something regarding the
> intent of the changes in this regard?
>

This is a great point. It makes no sense to allow a CA to issue a cert that
is then immediately subject to a revocation requirement. I am open to
either exempting Debian weak keys from BR 4.9.1.1(4) or for CAs to be
required to revoke a certificate containing a Debian weak key only if they
are "made aware" using the mechanism specified in 4.9.3.

Thanks,

Wayne


> There have been incidents involving certificates issued to Debian weak
> keys in recent years; some CAs have indicated that they don’t receive
> Debian weak keys in requests, but evidence exists to the contrary for the
> ecosystem as a whole.
>
> Thank you!
> -Clint
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240308/0932874c/attachment.html>