<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<style type="text/css" style="display:none;"> P {margin-top:0;margin-bottom:0;} </style>
</head>
<body dir="ltr">
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<b>INTRO</b></div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif; font-size: 12pt; color: rgb(0, 0, 0);" class="elementToProof">
<div><br>
</div>
<div>Thanks to all who participated in the very useful discussion regarding this proposed ballot in our June 23 2022 call.</div>
<div><br>
</div>
<div>An important point was raised about how to handle external links to recommended (but not required) resources. In "Section 6.1.1.3. Subscriber Key Pair Generation" of the proposed language, we require CAs to reject requests for certificates with "industry
demonstrated weak Private Keys" (as "SHALL" and "MUST" directives), then provide links to "Suggested tools that CAs MAY use" to judge requests.</div>
<div><br>
</div>
<div><b>THE QUESTIONS</b></div>
<div><br>
</div>
<div>The questions here are:</div>
<div>
<ul>
<li><span><b>If we direct issuers to external resources in CABF documents, what level of CABF-level vetting should be required or expected for those links?</b></span></li><li>And<b style="color: inherit; font-family: inherit; font-size: inherit; font-style: inherit; font-variant-ligatures: inherit; font-variant-caps: inherit;"> is the ballot process itself sufficient vetting for such links?</b></li></ul>
</div>
<div><b>OUR ASSUMPTION AND EXISTING LINKS</b></div>
<div><br>
</div>
<div>We are assuming that for, weak key detection, we DO want to provide useful links to help guide certificate issuers (see sidebar below). Note that the current BR language already includes one such link, to a page maintained by Debian (https://wiki.debian.org/SSLkeys),
though with a vetted status unknown to us. </div>
<div><br>
</div>
<div>Our proposed ballot language also adds a requirement to reject keys "identified by the tools available at https://github.com/crocs-muni/roca or equivalent". As we recall it, this resource was suggested by a CABF participant now departed, and again the
status of vetting for this link is unknown.</div>
<div><br>
</div>
<div>For what it's worth, a quick scan of the BRs shows that, apart from weak key guidance, we do include links to other external resources which are presumably foundational enough to not require vetting. These include:</div>
<div>
<ul>
<li><span>IETF (various RFCs, ex. http://tools.ietf.org/html/rfc5890)</span></li><li>IANA (registry information, ex. https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml)</li><li>NIST (publications, ex. http://csrc.nist.gov/publications/nistpubs/800-89/SP-800-89_November2006.pdf)</li><li>and the Mozilla Foundation (the Public Suffix List, https://publicsuffix.org/).</li></ul>
</div>
<div><b>"CROSS-VETTING" OF PROPOSED RESOURCES</b></div>
<div><br>
</div>
<div>As Dimitris stated in the call, the two other links included as resources which MAY be utilized:</div>
<div>
<ul>
<li><span>https://github.com/CVE-2008-0166</span></li><li>https://github.com/HARICA-official/debian-weak-keys</li></ul>
</div>
<div>... have been "cross-vetted" by their respective providers (HARICA and Sectigo).</div>
<div><br>
</div>
<div>This discussion was spurred by a suggestion from Adriano Santoni to consider adding a third resource (Hanno Böck's badkeys tool):</div>
<div>
<ul>
<li><span>https://github.com/badkeys/badkeys (web version: <a href="https://badkeys.info/" id="LPNoLPOWALinkPreview">
https://badkeys.info/</a>)<br>
</span></li></ul>
</div>
<div>
<div class="_Entity _EType_OWALinkPreview _EId_OWALinkPreview _EReadonly_1"></div>
...for which no such CABF-level "cross-vetting" has been performed (as far as we know).<br>
<br>
</div>
<div>We ourselves very much appreciate the effort that went into creating these tools and intend to utilize them. However:<br>
<br>
</div>
<div><b>TO RESTATE THE QUESTIONS</b></div>
<div>
<ul>
<li><span><b>Is the ballot process itself considered adequate vetting for external links in CABF documents?</b></span></li><li><span>If not, <b>what vetting would we consider adequate?</b></span></li></ul>
</div>
<div><b>SIDEBAR: OTHER OPTIONS</b></div>
<div>
<ul>
<li><span>In the June 23 call, an external, CABF-supported resource (i.e. a separate web page with appropriate links) was considered, discussed, and rejected as likely to increase overhead and decrease reliability. Based on this, our sense is that
<b>any links deemed useful should indeed be included in the actual ballot language itself</b>.<br>
</span></li><li>And finally, as raised in previous discussions: <b>Would some sort of disclaimer be appropriate for external links</b>, and if so should it extend beyond the 6.1.1.3 links to cover external resources more generally?</li></ul>
</div>
<div><b>CLOSING REMARKS</b></div>
<div><br>
</div>
Thanks.<br>
</div>
<div id="appendonsend"></div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font face="Calibri, sans-serif" style="font-size:11pt" color="#000000"><b>From:</b> Servercert-wg <servercert-wg-bounces@cabforum.org> on behalf of Adriano Santoni via Servercert-wg <servercert-wg@cabforum.org><br>
<b>Sent:</b> Sunday, June 12, 2022 7:11 PM<br>
<b>To:</b> servercert-wg@cabforum.org <servercert-wg@cabforum.org><br>
<b>Cc:</b> Hanno Böck <hanno@hboeck.de><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot - Debian Weak Keys (and related vulnerabilities)</font>
<div> </div>
</div>
<div>
<p><font face="Calibri">Might a third option be the tool developed by Hanno Boeck?</font></p>
<p><font face="Calibri"><a class="x_moz-txt-link-freetext" href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbadkeys%2Fbadkeys&data=05%7C01%7Cchris%40ssl.com%7C8641292420c44f04613b08da4cd14ed0%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637906759104963939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=DwRmkMHaKGp4rQDSPpbekE%2B5MwXinAtDIPExqNT4yZ0%3D&reserved=0" originalsrc="https://github.com/badkeys/badkeys" shash="HkAOR53jqC8e9k7CYWoZGVM0zNtCu3mn8EkBSb3pff7yYVsYBB+Udpxz/nW+X+5WeUEvDYghflHCDydCTEcA6tRUbglVuUzxG4SX0zLmd1TqYBQA8SqMHMv5jjTwGbBIpXUwmobxonWbJnsX+xTWlVBjjDGn0OE/YY+3/S9LfXo=">https://github.com/badkeys/badkeys</a></font></p>
<p>From our point of view it's an effective tool.</p>
<p><font face="Calibri">Adriano</font></p>
<p><font face="Calibri"></font><br>
</p>
<div class="x_moz-cite-prefix">Il 09/06/2022 15:18, Chris Kemmerer via Servercert-wg ha scritto:<br>
</div>
<blockquote type="cite">
<div>Suggested tools that CAs MAY use to obtain lists of Debian weak keys include:</div>
<div><br>
</div>
<div> - <a class="x_moz-txt-link-freetext" href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCVE-2008-0166&data=05%7C01%7Cchris%40ssl.com%7C8641292420c44f04613b08da4cd14ed0%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637906759104963939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zfjpsiplLaqFzwkKzciu7cQTRzDeeqBP0XFs3zn5OJg%3D&reserved=0" originalsrc="https://github.com/CVE-2008-0166" shash="ibqGKQ/uq1YwhB4VhvjGJ9DAVbj5+YW9qj/EF8sl04FcYUKGN1RbGfdKtAQt/iXBKJ4SA7xW/URqoagC4zeiL79GtzCf62a+yhWVuDagq5wQPmYjhRwCY2tmhcVLh4mZqVDXI+A7lCtPqu1mpDffrOUVniUKMlI/V8cs4rdwq6o=">
https://github.com/CVE-2008-0166</a> provides a generator, for the complete set of parameters listed above, that runs on any modern 64-bit Linux system; it also provides complete sets of pregenerated keys for the most common RSA key sizes.</div>
<div> - <a class="x_moz-txt-link-freetext" href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FHARICA-official%2Fdebian-weak-keys&data=05%7C01%7Cchris%40ssl.com%7C8641292420c44f04613b08da4cd14ed0%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637906759104963939%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=JAHix0XFgxltAzN0FGh58bZkHVRLacTP8rUK35Ymn0c%3D&reserved=0" originalsrc="https://github.com/HARICA-official/debian-weak-keys" shash="aHnxqrXo3PFwej7pnShtLk8RyR5nFeAMQHTWlIBY27ITnbdINF/wNPUbsVhvjvZ5AFOC3iOt47B5Pj0h3sdGWDhwXPJO06mmL8e+Gk5nqPoIVb1lysD7hxb9GUqJrWKvB8wRuKeZMZ0crNO4Yi7AxjYtTLRUEsoUWc9jxt4wzmQ=">
https://github.com/HARICA-official/debian-weak-keys</a> provides a generator, for a subset of the parameters listed above, that can take advantage of a computer cluster.</div>
</blockquote>
</div>
</body>
</html>