<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:Aptos;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0in;
        font-size:12.0pt;
        font-family:"Aptos",sans-serif;}
a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:blue;
        text-decoration:underline;}
pre
        {mso-style-priority:99;
        mso-style-link:"HTML Preformatted Char";
        margin:0in;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";}
span.HTMLPreformattedChar
        {mso-style-name:"HTML Preformatted Char";
        mso-style-priority:99;
        mso-style-link:"HTML Preformatted";
        font-family:Consolas;
        mso-ligatures:none;}
span.EmailStyle21
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;
        mso-ligatures:none;}
@page WordSection1
        {size:8.5in 11.0in;
        margin:70.85pt 70.85pt 56.7pt 70.85pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Hi<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">My main concern has been that CAs are required to include additional controls, including generating possible weak Debian keys for supported key sizes or limit the supported
 key sizes due to a (more or less) theoretical threat of Debian keys from an OS that presumably should not be in use since many years ago.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I understand that Debian weak keys are still an issue, that’s why I suggested to keep the existing wording regarding Debian weak keys in BR (section 6.1.1.3) as is, e.g. ‘…<i>the
 CA SHALL reject Debian weak keys (see <a href="https://wiki.debian.org/SSLkeys)">
https://wiki.debian.org/SSLkeys)</a>...’ </i>or similar<i>. </i>This has been the wording since the first version of BR in 2011, and I hope this still suffice. If this is not the case, it would be great to get some more information about what problem we try
 to solve by adding more specific controls for Debian keys now (more than 15 years after the vulnerability was identified).
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Regards<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">Mads
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Servercert-wg <servercert-wg-bounces@cabforum.org>
<b>On Behalf Of </b>Roman Fischer via Servercert-wg<br>
<b>Sent:</b> Monday, March 25, 2024 9:06 AM<br>
<b>To:</b> CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><br>
<b>Subject:</b> Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">I would propose a pragmatic approach: Limit the Debian weak keys to be considered/rejected by CAs to an upper bound (e.g. 4096 or 8192 bits) assuming that any weak key above
 that has been intentionally manufactured by a security researcher.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">-Roman<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"><o:p> </o:p></span></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Servercert-wg <</span><a href="mailto:servercert-wg-bounces@cabforum.org"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">servercert-wg-bounces@cabforum.org</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">>
<b>On Behalf Of </b>Wayne Thayer via Servercert-wg<br>
<b>Sent:</b> Freitag, 15. März 2024 19:20<br>
<b>To:</b> CA/B Forum Server Certificate WG Public Discussion List <</span><a href="mailto:servercert-wg@cabforum.org"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">servercert-wg@cabforum.org</span></a><span style="font-size:11.0pt;font-family:"Calibri",sans-serif">><br>
<b>Subject:</b> Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="DE">On yesterday's SCWG teleconference, Mads suggested that a way forward would be to leave the existing requirements in place for Debian weak keys. I've interpreted that to mean that we would just remove references to Debian,
 resulting in this: </span><a href="https://github.com/wthayer/servercert/pull/1/files"><span lang="DE">https://github.com/wthayer/servercert/pull/1/files</span></a><span lang="DE"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">I'm not satisfied by this approach because it doesn't achieve the clarity intended to result from the original weak keys ballot and will seemingly result in CAs continuing to have varying interpretations of the specific
 requirements for rejecting Debian weak keys, but perhaps this is the best we can all agree to.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">What  do others think? Should we proceed with this approach?<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">Thanks,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">Wayne<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="DE">On Sat, Mar 9, 2024 at 9:15</span><span lang="DE" style="font-family:"Arial",sans-serif"> </span><span lang="DE">AM Dimitris Zacharopoulos (HARICA) via Servercert-wg <</span><a href="mailto:servercert-wg@cabforum.org"><span lang="DE">servercert-wg@cabforum.org</span></a><span lang="DE">>
 wrote:<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span lang="DE">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.<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="DE">On 9/3/2024 12:05 π.μ., Wayne Thayer via Servercert-wg wrote:<o:p></o:p></span></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span lang="DE">Hi Clint,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">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.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<div>
<div>
<p class="MsoNormal"><span lang="DE">On Thu, Mar 7, 2024 at 12:59</span><span lang="DE" style="font-family:"Arial",sans-serif"> </span><span lang="DE">AM Clint Wilson <</span><a href="mailto:clintw@apple.com" target="_blank"><span lang="DE">clintw@apple.com</span></a><span lang="DE">>
 wrote:<o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<p class="MsoNormal"><span lang="DE">Hi Wayne, <o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">Thank you for carrying this work item forward. I have a few concerns regarding the proposed removal of Debian weak key checking, outlined below.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">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.).
<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE"> <o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span lang="DE">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).<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE"> <o:p></o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span lang="DE">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?<o:p></o:p></span></p>
</div>
</div>
</blockquote>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">Thanks,<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">Wayne<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC 1.0pt;padding:0in 0in 0in 6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0in;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">Thank you!<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span lang="DE">-Clint<o:p></o:p></span></p>
<div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
</div>
</div>
</blockquote>
</div>
</div>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
<pre><span lang="DE">_______________________________________________<o:p></o:p></span></pre>
<pre><span lang="DE">Servercert-wg mailing list<o:p></o:p></span></pre>
<pre><a href="mailto:Servercert-wg@cabforum.org" target="_blank"><span lang="DE">Servercert-wg@cabforum.org</span></a><span lang="DE"><o:p></o:p></span></pre>
<pre><a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" target="_blank"><span lang="DE">https://lists.cabforum.org/mailman/listinfo/servercert-wg</span></a><span lang="DE"><o:p></o:p></span></pre>
</blockquote>
<p class="MsoNormal"><span lang="DE"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span lang="DE">_______________________________________________<br>
Servercert-wg mailing list<br>
</span><a href="mailto:Servercert-wg@cabforum.org" target="_blank"><span lang="DE">Servercert-wg@cabforum.org</span></a><span lang="DE"><br>
</span><a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" target="_blank"><span lang="DE">https://lists.cabforum.org/mailman/listinfo/servercert-wg</span></a><span lang="DE"><o:p></o:p></span></p>
</blockquote>
</div>
</div>
</body>
</html>