FWIW, I think in the recent years, it was mostly security researchers
that attempted to request certificates with Debian weak keys to test if
a CA was properly blocking them.
If an Applicant uses an outdated OS that generates weak keys, imagine
the actual web server or other software that runs on that server,
putting Relying Parties at risk. CAs don't have control over that but
they could have control over a common set of weak keys using common
parameters/algorithms which could be enforced by all CAs.
Dimitris.
On 9/3/2024 12:05 π.μ., Wayne Thayer via Servercert-wg wrote:
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 <cli...@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
_______________________________________________
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg
_______________________________________________
Servercert-wg mailing list
Servercert-wg@cabforum.org
https://lists.cabforum.org/mailman/listinfo/servercert-wg
