<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;"><div>Hi Wayne,</div><div><br></div><div>Agreed, your proposal [1] is basically what I was describing; I only added that it would be useful, in my mind, to add a repository usable by Certificate Issuers (but not required to be used) similar to what we’ve provided for ROCA and Close Primes.</div><div><br></div><div>However, based on the discussion today, I think both of the below sets of changes make sense to me, though I sensed consensus on the call leaning towards the first set of changes. Set 2 is intended to be the same as what I previously described in Option 2.</div><div><br></div><div>I believe the only clarification I’ve added in Set 1, beyond what Aaron and Tim discussed, is the addition of a requirement for key <b>sizes</b> <i>other</i> than those specifically represented in a known complete (at this time) repository of Debian weak keys for common key sizes. At least, that was my only intentional addition, so if the described set of changes don’t otherwise align with the proposal represented in Aaron and Tim’s discussion, please let me know. </div><div>In other words, I believe it satisfactory to establish a constrained set of Debian weak keys which CAs must block (rather than leaving the requirement fully open-ended), but I don’t believe that should obviate the need for a CA to check uncommon key sizes — which are otherwise in the key size ranges of that constrained set’s key sizes — should a CA allow those uncommon key sizes. </div><div><br></div><div>I want to further clarify that I do expect any such repository representing this constrained set of Debian weak keys to be updated in the future if some meaningful change is identified to Debian weak keys generated in the included key size ranges, but this approach would allow that to be a structured process within the CA/BF, rather than some “surprise, here’s a random def con preso; block all the keys it describes as being possible to generate yesterday please” situation as we could otherwise (and currently) encounter.</div><div><br></div><div><u>Set 1:</u></div><div><span style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">1) Create a CA/BF repo with presently known Debian weak keys for the key sizes RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521 (the repo Rob pointed to seems the most complete from what I’ve seen, but no particularly strong opinions here)</span><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">2) Update TBRs: For RSA key sizes or smaller than 8193 bits and ECC key sizes smaller than 522 bits, CAs must not issue certificates containing Debian weak keys</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">3) Update TBRs: Include a reference to the above CA/BF repo as the set of Debian weak keys which meet the requirement of 2) specifically for the key sizes RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521 included in that repo</div><div style="caret-color: rgb(0, 0, 0); color: rgb(0, 0, 0);">4) Update TBRs: Add an explanatory note clarifying that if a CA allows for issuance of certificates other than RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521, the CA must ensure certificates containing any other key size do not contain a Debian weak key</div></div><div><br></div><div><u>Set 2:</u></div>1) Create a CA/BF repo with presently known Debian weak keys for the key sizes RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521<div>2) Update TBRs: For RSA key sizes smaller than 8193 bits and ECC key sizes smaller than 522 bits, CAs must not issue certificates containing Debian weak keys</div><div>3) Update TBRs: Include a reference to the above CA/BF repo as an <i>optional</i> resource for CAs to use in checking for Debian weak keys</div><div><br></div><div>I hope I’m contributing something useful to this discussion; please reach out if I could do better here.</div><div><br></div><div>Thank you!</div><div>-Clint</div><div><br></div><div>[1] https://github.com/wthayer/servercert/pull/1/files<br id="lineBreakAtBeginningOfMessage"><div><br><blockquote type="cite"><div>On Apr 10, 2024, at 11:51 AM, Wayne Thayer <wthayer@gmail.com> wrote:</div><br class="Apple-interchange-newline"><div><div dir="ltr"><div dir="ltr"><div>Hi Clint,</div><div><br></div><div>I think my latest proposal [1] is essentially what you are proposing in option #2, the only difference being that we would add repositories containing weak keys to <a href="https://cabforum.org/resources/tools/">https://cabforum.org/resources/tools/</a> (and we can do that without a ballot). If you are instead proposing that we require CAs to check for a specified weak keys contained in one or more repositories, then that is similar to Aaron's proposal except that I understand you want to require CAs to also check for weak keys even if they sign non-standard key sizes that are not included in the repository of weak keys.<br></div><div><br></div><div>The more I think about the two approaches, the more I prefer my current proposal [1] that does not require CAs to check for specific keys found in one or more repositories. The reason is that I believe CAs already have Debian weak key checks in place and would likely prefer not to have to change their systems to use different logic/data to meet the same requirement as before. <br></div><div><br></div>Thanks,</div><div dir="ltr"><br></div><div>Wayne</div><div><br></div><div>[1] <a href="https://github.com/wthayer/servercert/pull/1/files" target="_blank">https://github.com/wthayer/servercert/pull/1/files</a></div><div dir="ltr"><div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr"><br></div></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Apr 9, 2024 at 2:26 PM Clint Wilson <<a href="mailto:clintw@apple.com" target="_blank">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>I think this does seem like it could be a tractable solution, however I’d like to understand why one of the proposals I’ve brought up a couple times on the calls isn’t also a suitable option. From what I can gather, they’re nearly identical in practical impact, but one provides a much more defined boundary for relying parties. </div><div><br></div><div>Option 1:</div><div><span style="">The CA/BF creates or mirrors a repository of pre-computed Debian Weak keys for the following key sizes (representing those most commonly issued against): RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521.</span><span style=""> </span>The TBRs stipulate that CAs must not issue certificates containing keys in this repository.</div><div><br></div><div>Option 2:</div><div><span style="">The CA/BF creates or mirrors a repository of pre-computed Debian Weak keys for the following key sizes (representing those most commonly issued against): RSA 2048, 3072, 4096, 8192; ECC 256, 384, 521.</span><span style=""> </span>The TBRs stipulate that CAs must not issue certificates containing weak keys, with a pointer to the repository of the most common key sizes of Debian Weak keys among other similar/relevant pointers for other vulnerabilities.</div><div><br></div><div>The reason these 2 proposals are so nearly identical in practice is that there are only a very tiny number of certificates issued against key sizes that are not <font><span>RSA 2048, 3072, 4096, or 8192; or ECC 256, 384, or 521. By my count, somewhere around 80 certificates out of roughly 750 million (though I really only took a quick glance, so perhaps this is off to an extent… but probably not by huge quantities).</span></font></div><div><font><span><br></span></font></div><div><font>Under Option 2, if a CA wants to allow for Certificate requests containing a key size other than these 7, they’re fully free to do so; they must merely ensure the key is not a Debian Weak key. For every other CA, they can limit the accepted key sizes to those in the repository and the result is functionally the same as Option 1, but without the possibility of “certificates can be issued that are weak and CAs are under no obligation to prevent that if it’s not one of 7 key sizes”.</font></div><div><font><br></font></div><div><font>Concretely, is there a reason Option 2 is intractable for CAs? If so, I would greatly appreciate help understanding how that approach meaningfully differs from Option 1.</font></div><div><font><br></font></div><div><font>Thanks,</font></div><div><font>-Clint<br id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471lineBreakAtBeginningOfMessage"></font><div><br><blockquote type="cite"><div>On Apr 9, 2024, at 11:43 AM, Rob Stradling via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>> wrote:</div><br><div><div style="font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt">> * Aaron Gable commented in the PR with a suggestion that we require CAs to reject any key found in Hanno Bock's repository at<span> </span><a href="https://github.com/badkeys/debianopenssl" target="_blank">https://github.com/badkeys/debianopenssl</a>. This includes RSA 1024/2048/3072/4096 and EC P256/P384 keys.</div><div style="font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt"><br></div><div style="font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt">Some of the EC key files in Hanno's repository have ASN.1 encoding issues (see<span> </span><a href="https://www.mail-archive.com/dev-security-policy@mozilla.org/msg00911.html" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWAb4d7fc64-d681-b02c-8203-ddb986be2cd9" target="_blank">https://www.mail-archive.com/dev-security-policy@mozilla.org/msg00911.html</a>); whereas the equivalent files in<a href="https://github.com/CVE-2008-0166/private_keys" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWAe97607e4-a8ff-0c2a-59f2-b69e4c16f64f" target="_blank">https://github.com/CVE-2008-0166/private_keys</a> are correctly encoded.</div><div style="font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt"><br>> * Roman Fischer suggested that we limit the requirement to check Debian weak keys only with sizes up to RSA 4096 under the logic that no one would “accidentally” create an 8192 bit RSA key on a system vulnerable to Debian Weak keys</div><div style="font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt"><br></div><div style="font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt">FWIW,<span> </span><a href="https://github.com/CVE-2008-0166/private_keys" target="_blank">https://github.com/CVE-2008-0166/private_keys</a> already has all of the possible 8192-bit RSA Debian weak keys.</div><div style="font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt"><br></div><hr style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;display:inline-block;width:767.328px"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline"></span><div style="font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr;font-family:Calibri,sans-serif;font-size:11pt"><b>From:</b> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank">servercert-wg-bounces@cabforum.org</a>> on behalf of Wayne Thayer via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br><b>Sent:</b> 05 April 2024 23:47<br><b>To:</b> CA/B Forum Server Certificate WG Public Discussion List <<a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a>><br><b>Subject:</b> Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr"> </div><div style="font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;text-align:left;line-height:12pt;background-color:rgb(250,250,3);padding:2pt;border-width:1pt;border-style:solid;border-color:rgb(0,0,0);font-family:Calibri;font-size:10pt"><span>CAUTION:</span><span> This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.</span></div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr">Two new alternatives have been proposed in addition to the one I proposed below:</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr">* Aaron Gable commented in the PR with a suggestion that we require CAs to reject any key found in Hanno Bock's repository at<a href="https://github.com/badkeys/debianopenssl" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWA31e91472-a12a-4afb-abec-4639cc182738" target="_blank">https://github.com/badkeys/debianopenssl</a>. This includes RSA 1024/2048/3072/4096 and EC P256/P384 keys. We might prefer to reference a clone in the CAB Forum GitHub org (or some other source of the actual generated weak keys) but that's a detail we can work out if others like this approach.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr">* Roman Fischer suggested that we limit the requirement to check Debian weak keys only with sizes up to RSA 4096 under the logic that no one would “accidentally” create an 8192 bit RSA key on a system vulnerable to Debian Weak keys</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr">Each of these methods has the benefit of adding clarity to the Debian requirement rather than just maintaining the existing language, but they also [arguably] allow CAs to issue certs containing abnormally sized Debian weak keys.</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr">I would like to hear from other members (especially Apple) if you prefer or object to either of these alternatives?</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr">Thanks,</div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr"><br></div><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr">Wayne</div><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;direction:ltr">On Thu, Mar 28, 2024 at 4:13 PM Wayne Thayer via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWA334195ed-dd20-b315-827a-2b7b38982b04" target="_blank">servercert-wg@cabforum.org</a>> wrote:</div><blockquote style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)"><div style="direction:ltr">There was further discussion of this ballot proposal on today's teleconference. It was suggested that rather than omitting any reference to Debian weak keys, the ballot should retain the current language. Unfortunately, the ballot restructures the language in such a way that this is challenging. My new proposal is that TLS BR Section 6.1.1.3(5) be updated to read as follows (<a href="https://github.com/wthayer/servercert/pull/1/files" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWA1c23a3b4-e06e-a793-b7a7-95178d10cc29" target="_blank">https://github.com/wthayer/servercert/pull/1/files</a>):</div><div style="direction:ltr">=====</div><div style="direction:ltr">5. The Public Key corresponds to an industry-demonstrated weak Private Key. For requests submitted on or after November 15, 2024, at least the following precautions SHALL be implemented:<br> 1. The CA SHALL reject Debian weak keys (<a href="https://wiki.debian.org/SSLkeys" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWA80402dc8-08fa-78f9-a593-e1bd5d166294" target="_blank">https://wiki.debian.org/SSLkeys</a>).<br> 2. In the case of ROCA vulnerability, the CA SHALL reject keys identified by the tools available at<span> </span><a href="https://github.com/crocs-muni/roca" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWA024eb113-e603-4a5e-2f07-c1357a15f321" target="_blank">https://github.com/crocs-muni/roca</a> or equivalent.<br> 3. In the case of Close Primes vulnerability (<a href="https://fermatattack.secvuln.info/" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWAc9a62049-420c-9085-6ef3-88c75f872995" target="_blank">https://fermatattack.secvuln.info/</a>), the CA SHALL reject weak keys which can be factored within 100 rounds using Fermat’s factorization method. <br><br> Suggested tools for checking for weak keys can be found here:<span> </span><a href="https://cabforum.org/resources/tools/" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWA94d6f8b9-6f2d-1669-37d5-4a25ec8ab446" target="_blank">https://cabforum.org/resources/tools/</a></div><div style="direction:ltr">=====</div><div style="direction:ltr">I would greatly appreciate feedback from any member that finds this language unacceptable, or that has suggestions to improve it.</div><div style="direction:ltr"><br></div><div style="direction:ltr">Thanks,</div><div style="direction:ltr"><br></div><div style="direction:ltr">Wayne</div><div style="direction:ltr"><br></div><br><div style="direction:ltr">On Fri, Mar 15, 2024 at 11:19 AM Wayne Thayer via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWA83ca926e-2c8b-de07-8f5b-04852d47f014" target="_blank">servercert-wg@cabforum.org</a>> wrote:</div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)"><div style="direction:ltr">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> </span><a href="https://github.com/wthayer/servercert/pull/1/files" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWAb2e1af5a-979b-ab2d-eba8-92278b28d928" target="_blank">https://github.com/wthayer/servercert/pull/1/files</a></div><div style="direction:ltr"><br></div><div style="direction:ltr">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.</div><div style="direction:ltr"><br></div><div style="direction:ltr">What do others think? Should we proceed with this approach?</div><div style="direction:ltr"><br></div><div style="direction:ltr">Thanks,</div><div style="direction:ltr"><br></div><div style="direction:ltr">Wayne</div><br><div style="direction:ltr">On Sat, Mar 9, 2024 at 9:15 AM Dimitris Zacharopoulos (HARICA) via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWAfd021ab2-cc72-6bc5-6f21-dd5c4b0a40be" target="_blank">servercert-wg@cabforum.org</a>> wrote:</div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)"><div>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><div>On 9/3/2024 12:05 π.μ., Wayne Thayer via Servercert-wg wrote:</div><blockquote><div style="direction:ltr">Hi Clint,</div><div style="direction:ltr"><br></div><div style="direction:ltr">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.</div><div style="direction:ltr"><br></div><div style="direction:ltr">On Thu, Mar 7, 2024 at 12:59 AM Clint Wilson <<a href="mailto:clintw@apple.com" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWAf8fe7bb6-140e-b38f-a5d2-94204e7cd2a0" target="_blank">clintw@apple.com</a>> wrote:</div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)"><div style="direction:ltr">Hi Wayne,</div><div style="direction:ltr"><br></div><div style="direction:ltr">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 style="direction:ltr"><br></div><div style="direction:ltr">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.).</div></blockquote><div style="direction:ltr"><br></div><div style="direction:ltr">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.</div><div style="direction:ltr"> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)"><div style="direction:ltr">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></blockquote><div style="direction:ltr"><br></div><div style="direction:ltr">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.</div><div style="direction:ltr"> </div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)"><div style="direction:ltr">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></blockquote><div style="direction:ltr"><br></div><div style="direction:ltr">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.</div><div style="direction:ltr"><br></div><div style="direction:ltr">Thanks,</div><div style="direction:ltr"><br></div><div style="direction:ltr">Wayne</div><div style="direction:ltr"><br></div><blockquote style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left:1px solid rgb(204,204,204)"><div style="direction:ltr"><br></div><div style="direction:ltr">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 style="direction:ltr"><br></div><div style="direction:ltr">Thank you!</div><div style="direction:ltr">-Clint</div><div style="direction:ltr"><br></div></blockquote><br><fieldset></fieldset><pre><div>_______________________________________________
Servercert-wg mailing list
<a href="mailto:Servercert-wg@cabforum.org" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWAba1d295b-6316-8d6a-b9b0-d30a14dbb6cb" target="_blank">Servercert-wg@cabforum.org</a>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWA7745a98b-95b9-0de4-1584-0c01a959a7ad" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a>
</div></pre></blockquote><br>_______________________________________________<br>Servercert-wg mailing list<br><a href="mailto:Servercert-wg@cabforum.org" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWA0c582809-83bf-b1a8-c2d3-ea8dc3f6e583" target="_blank">Servercert-wg@cabforum.org</a><br><a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWAd143bfd0-cbb9-abe0-80c3-901ae5d5a0ba" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br></blockquote>_______________________________________________<br>Servercert-wg mailing list<br><a href="mailto:Servercert-wg@cabforum.org" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWAe32922e9-4c2c-05eb-d56d-b77ab02601d3" target="_blank">Servercert-wg@cabforum.org</a><br><a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWAa6371aa2-35f0-f843-8ab7-0ab7dc0a8810" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br></blockquote>_______________________________________________<br>Servercert-wg mailing list<br><a href="mailto:Servercert-wg@cabforum.org" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWA28795adc-5e22-768d-79ec-db7c6143444b" target="_blank">Servercert-wg@cabforum.org</a><br><a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" id="m_-7009398709855078807m_4469783284652936578m_-7577030331507609919m_-2359405307761231471OWAdf889203-5f5a-5948-0426-a9dcf89f8e6d" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br></blockquote><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">Servercert-wg mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><a href="mailto:Servercert-wg@cabforum.org" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">Servercert-wg@cabforum.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none"><a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a></div></blockquote></div><br></div></div></blockquote></div>
</div>
</div></blockquote></div><br></div></body></html>