<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
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.<br>
<br>
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.<br>
<br>
Dimitris.<br>
<br>
<div class="moz-cite-prefix">On 9/3/2024 12:05 π.μ., Wayne Thayer
via Servercert-wg wrote:<br>
</div>
<blockquote type="cite"
cite="mid:0100018e201955fe-0ae7463f-d7a5-4c4e-aff1-bbff50126406-000000@email.amazonses.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">Hi Clint,</div>
<div dir="ltr"><br>
</div>
<div>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.<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Mar 7, 2024 at
12:59 AM Clint Wilson <<a href="mailto:clintw@apple.com"
moz-do-not-send="true" class="moz-txt-link-freetext">clintw@apple.com</a>>
wrote:<br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>Hi Wayne,
<div><br>
</div>
<div>Thank you for carrying this work item forward. I have
a few concerns regarding the proposed removal of Debian
weak key checking, outlined below.</div>
<div><br>
</div>
<div>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.). <br>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.<br>
</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>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).</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.<br>
</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div>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?</div>
</div>
</blockquote>
<div><br>
</div>
<div>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.<br>
</div>
<div><br>
</div>
<div>Thanks,</div>
<div><br>
</div>
<div>Wayne</div>
<div><br>
</div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>Thank you!</div>
<div>-Clint<br
id="m_-5196886636388968739lineBreakAtBeginningOfMessage">
<div><br>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
Servercert-wg mailing list
<a class="moz-txt-link-abbreviated" href="mailto:Servercert-wg@cabforum.org">Servercert-wg@cabforum.org</a>
<a class="moz-txt-link-freetext" href="https://lists.cabforum.org/mailman/listinfo/servercert-wg">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a>
</pre>
</blockquote>
<br>
</body>
</html>