<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Based on discussion in the SCWG call of July 21 2022, we are 1)
removing the language directing readers to external "suggested
tools" and 2) seeking endorsers.<br>
<br>
Many thanks to all for the useful input. <br>
<br>
Chris K<br>
<br>
=====<br>
<br>
</p>
<div>--- Motion Begins ---</div>
<div><br>
</div>
<div>This ballot is intended to clarify CA responsibilities
regarding weak key vulnerabilities (including specific guidance
for Debian weak key, ROCA and Fermat attack vulnerabilities) and
modifies the “Baseline Requirements for the Issuance and
Management of Publicly-Trusted Certificates” as follows, based on
Version 1.8.4:<br>
<br>
</div>
<div> </div>
<div><b>Proposed ballot language:</b></div>
<div><br>
</div>
<div> </div>
<div>4.9.1.1 Reasons for Revoking a Subscriber Certificate</div>
<div><br>
</div>
<div> </div>
<div><b>Replace:</b></div>
<div><br>
</div>
<div> </div>
<div>4. The CA is made aware of a demonstrated or proven method that
can easily compute the Subscriber’s Private Key based on the
Public Key in the Certificate (such as a Debian weak key, see
<a class="moz-txt-link-freetext" href="https://wiki.debian.org/SSLkeys">https://wiki.debian.org/SSLkeys</a>)</div>
<div><br>
</div>
<div> </div>
<div><b>With:</b></div>
<div><br>
</div>
<div> </div>
<div>4. The CA is made aware of a demonstrated or proven method that
can easily compute the Subscriber’s Private Key (such as those
identified in 6.1.1.3(4)).</div>
<div><br>
</div>
<div> </div>
<div>---</div>
<div><br>
</div>
<div> </div>
<div>6.1.1.3. Subscriber Key Pair Generation</div>
<div><br>
</div>
<div> </div>
<div><b>Replace:</b></div>
<div><br>
</div>
<div> </div>
<div>The CA SHALL reject a certificate request if one or more of the
following conditions are met:</div>
<div><br>
</div>
<div> </div>
<div>1. The Key Pair does not meet the requirements set forth in
Section 6.1.5 and/or Section 6.1.6;</div>
<div>2. There is clear evidence that the specific method used to
generate the Private Key was flawed;</div>
<div>3. The CA is aware of a demonstrated or proven method that
exposes the Applicant's Private Key to compromise;</div>
<div>4. The CA has previously been made aware that the Applicant's
Private Key has suffered a Key Compromise, such as through the
provisions of Section 4.9.1.1;</div>
<div>5. The CA is aware of a demonstrated or proven method to easily
compute the Applicant's Private Key based on the Public Key (such
as a Debian weak key, see <a class="moz-txt-link-freetext" href="https://wiki.debian.org/SSLkeys">https://wiki.debian.org/SSLkeys</a>).</div>
<div><br>
</div>
<div> </div>
<div><b>With:</b></div>
<b>
</b>
<div><br>
</div>
<div> </div>
<div>The CA SHALL reject a certificate request if one or more of the
following occurs:</div>
<div><br>
</div>
<div> </div>
<div>1) The requested Public Key does not meet the requirements set
forth in Sections 6.1.5 and/or 6.1.6;</div>
<div>2) The CA is aware of a demonstrated or proven method that
exposes the Subscriber's Private Key to compromise;</div>
<div>3) The CA has previously been made aware that the Subscriber's
Private Key has suffered a Key Compromise, such as through the
provisions of Section 4.9.1.1;</div>
<div>4) The Public Key corresponds to an industry demonstrated weak
Private Key, in particular:</div>
<div><br>
</div>
<div>a) In the case of ROCA vulnerability, the CA SHALL reject keys
identified by the tools available at
<a class="moz-txt-link-freetext" href="https://github.com/crocs-muni/roca">https://github.com/crocs-muni/roca</a> or equivalent.</div>
<div>b) In the case of Debian weak keys
(<a class="moz-txt-link-freetext" href="https://wiki.debian.org/SSLkeys">https://wiki.debian.org/SSLkeys</a>), the CA SHALL reject at least
keys generated by the flawed OpenSSL version with the combination
of the following parameters:</div>
<div> </div>
<div>i) Big-endian 32-bit, little-endian 32-bit, and little-endian
64-bit architecture;</div>
<div>ii) Process ID of 0 to 32767, inclusive;</div>
<div>iii) All RSA Public Key lengths supported by the CA up to and
including 4096 bits;</div>
<div>iv) rnd, nornd, and noreadrnd OpenSSL random file state.</div>
<div><br>
</div>
<div>c) In the case of Close Primes vulnerability, the CA SHALL
reject weak keys identified within 100 rounds using Fermat’s
factorization method</div>
<div><br>
</div>
<div>For Debian weak keys not covered above, the CA SHALL take
actions to minimize the probability of certificate issuance.</div>
<div><br>
</div>
<div>CAs MUST check for Debian weak keys for all RSA modulus lengths
and exponents that they accept.</div>
<div><br>
</div>
<div>--- Motion Ends ---</div>
<br>
=====<br>
<br>
<br>
<div class="moz-cite-prefix">On 7/13/2022 3:51 PM, Tim Hollebeek
wrote:<br>
</div>
<blockquote type="cite" cite="mid:DM8PR14MB5237856F1C8E9A6AD7CD29F783899@DM8PR14MB5237.namprd14.prod.outlook.com">
<meta name="Generator" content="Microsoft Word 15 (filtered
medium)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]-->
<style>@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}@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:inherit;
panose-1:0 0 0 0 0 0 0 0 0 0;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}span.EmailStyle19
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0in;}ul
{margin-bottom:0in;}</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]-->
<div class="WordSection1">
<p class="MsoNormal">I agree with the strategy of stating the
requirements and then using requirements-free language to
reference the ancillary resources, but a lowercased 2119 word
is still a 2119 word (“These words are *often* capitalized” –
RFC 2119, emphasis mine).<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">It’s best to rephrase non-requirements to
avoid MUST, SHALL, SHOULD, and MAY entirely. As well as
required, recommended, and optional
<span style="font-family:"Segoe UI
Emoji",sans-serif">😊</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Something like: “CAs might find these tools
useful”, or even something like: “Additional information is
available from these resources.”<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Referencing something does not in any way
imply it is free from errors or even that it can be used in a
BR-compliant way. I give you the BR reference to the original
RFC 6844 as an example. The original RFC 6844 had multiple
errors and was rather incompatible with the BRs, but got added
to the BRs anyway. Oops.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">We should make sure the resources we
reference are high enough quality to be useful, but I think
the standard ballot / discussion process can handle that.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">-Tim<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in
0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Servercert-wg
<a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg-bounces@cabforum.org"><servercert-wg-bounces@cabforum.org></a>
<b>On Behalf Of </b>Aaron Gable via Servercert-wg<br>
<b>Sent:</b> Friday, July 8, 2022 12:44 PM<br>
<b>To:</b> Chris Kemmerer <a class="moz-txt-link-rfc2396E" href="mailto:chris@ssl.com"><chris@ssl.com></a>; CA/B
Forum Server Certificate WG Public Discussion List
<a class="moz-txt-link-rfc2396E" href="mailto:servercert-wg@cabforum.org"><servercert-wg@cabforum.org></a><br>
<b>Cc:</b> Hanno Böck <a class="moz-txt-link-rfc2396E" href="mailto:hanno@hboeck.de"><hanno@hboeck.de></a><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot - Debian
Weak Keys (and related vulnerabilities)<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p class="MsoNormal">It seems to me like the appropriate
line to walk would be:<o:p></o:p></p>
<div>
<p class="MsoNormal">First, state the requirements (such
as blocking debian weak keys, or blocking ROCA keys) in
plain language, much as the current ballot does. This
makes the requirement that CAs must abide by clear.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Second, provide links to tools that
may be helpful. Do not preface these links with any
normative language, i.e. say "CAs may find these tools
useful: ...", not "CAs MAY use these tools: ...". This
serves the purpose of providing easy access to the
helpful external resources, but without stating that
their contents have been vetted and fully approved.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Does that makes sense?<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Aaron<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Fri, Jul 1, 2022 at 12:13 PM Chris
Kemmerer via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>
wrote:<o:p></o:p></p>
</div>
<blockquote style="border:none;border-left:solid #CCCCCC
1.0pt;padding:0in 0in 0in
6.0pt;margin-left:4.8pt;margin-right:0in">
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">INTRO</span></b><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Thanks to
all who participated in the very useful
discussion regarding this proposed ballot in our
June 23 2022 call.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">THE
QUESTIONS</span></b><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">The
questions here are:<o:p></o:p></span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l5
level1 lfo1">
<b><span style="font-size:12.0pt">If we direct
issuers to external resources in CABF
documents, what level of CABF-level vetting
should be required or expected for those
links?</span></b><span style="font-size:12.0pt"><o:p></o:p></span></li>
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l5
level1 lfo1">
<span style="font-size:12.0pt">And</span><b><span style="font-size:12.0pt;font-family:"inherit",serif"> is the
ballot process itself sufficient vetting for
such links?</span></b><span style="font-size:12.0pt"><o:p></o:p></span></li>
</ul>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">OUR
ASSUMPTION AND EXISTING LINKS</span></b><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">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 (<a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Cchris%40ssl.com%7Ca45a3c77d44c4f15254408da65117e42%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637933424459542060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=q0xrwOeCjio0S%2Fvx2iT0bouLRS9slBoo8AcU%2FpmyLYs%3D&reserved=0" originalsrc="https://wiki.debian.org/SSLkeys" shash="f1LgLqK149CkoV2rwLl3MuB2fIN9fTTMyaFExztTu9HYNkGmnim3DEMKlDrRqz0TqJDTaPeAOlAkT5E+g2Tabe79pJjVHVeM5tNPYopwfNcs22vDpQICUe5HkTWveoD9gS7wY+1IIAA2Qq+V1YYhO4p5cIiQsTLfWW6l3OcIAR4=" target="_blank" moz-do-not-send="true">https://wiki.debian.org/SSLkeys</a>),
though with a vetted status unknown to us. <o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Our
proposed ballot language also adds a requirement
to reject keys "identified by the tools
available at
<a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fcrocs-muni%2Froca&data=05%7C01%7Cchris%40ssl.com%7Ca45a3c77d44c4f15254408da65117e42%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637933424459542060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=2V%2F%2FzJkGYEefMVA9PT4nWggLslIPTykEK1lVYwA%2F78M%3D&reserved=0" originalsrc="https://github.com/crocs-muni/roca" shash="l6PN45z9AfFqoOTPq4vxG26Y5q3uc8AxCufp0F1lXRPQfUxGgSCcGerABK7tGNjoQFc8lIUkM2F657atRiQ66h8q0HX5JhwfpyNxaPiCoGNs1o+tjYubSEHP3m7YgxnoiUEfl+eG8KvvLw0E7W1UN/VREEEz1mGpXWa4th+2840=" target="_blank" moz-do-not-send="true">https://github.com/crocs-muni/roca</a>
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.<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">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:<o:p></o:p></span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1
level1 lfo2">
<span style="font-size:12.0pt">IETF (various
RFCs, ex. <a href="https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc5890&data=05%7C01%7Cchris%40ssl.com%7Ca45a3c77d44c4f15254408da65117e42%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637933424459542060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=CphVFR3%2FtHeVJmvlaTha7kgEbkAbUKEDHpYW1XgKEGg%3D&reserved=0" originalsrc="http://tools.ietf.org/html/rfc5890" shash="JshXS9oSsYIp5W7eDKYKTxemCISxhTFgp4thDR2WhKsrI0BDXdYAJ6QRh0hAgvfcaz3d3QTidTJZev1G7UjqaDxpKFlF+VUSjRnVxeZk9iBSUfq2m93jzZG0P47iNW2pkstYhoLV9RK53b/jzrXBTc2Wq2qyytoEEzxODSvTq3c=" target="_blank" moz-do-not-send="true">
http://tools.ietf.org/html/rfc5890</a>)<o:p></o:p></span></li>
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1
level1 lfo2">
<span style="font-size:12.0pt">IANA (registry
information, ex. <a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iana.org%2Fassignments%2Fiana-ipv4-special-registry%2Fiana-ipv4-special-registry.xhtml&data=05%7C01%7Cchris%40ssl.com%7Ca45a3c77d44c4f15254408da65117e42%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637933424459542060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=IWeBBDXP1Qq5bbmO8NtdC6NzazYz6afrevHKrRedwyk%3D&reserved=0" originalsrc="https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml" shash="gPd5WlMCIVx4ShqyMRIMiwVY/oCHWWz6TnIyB0ovdtt5ZeIIeF11EWjVDcCnRr9uOEjsAoHf2LV2e7dqSi6JjIz9bgNWRMf4HHmXZhMolxE+iZZmdhdkcsmVmm1N8mepyf4T/wJ0iKwmI8VhpIVhDOGOF0R8+KSzPmWztS+M6t4=" target="_blank" moz-do-not-send="true">
https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml</a>)<o:p></o:p></span></li>
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1
level1 lfo2">
<span style="font-size:12.0pt">NIST
(publications, ex. <a href="https://nam04.safelinks.protection.outlook.com/?url=http%3A%2F%2Fcsrc.nist.gov%2Fpublications%2Fnistpubs%2F800-89%2FSP-800-89_November2006.pdf&data=05%7C01%7Cchris%40ssl.com%7Ca45a3c77d44c4f15254408da65117e42%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637933424459542060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=%2FPpXv09nw%2BPgL3PcrhUAHL7ijW28eSq%2BNgC9IDZsFes%3D&reserved=0" originalsrc="http://csrc.nist.gov/publications/nistpubs/800-89/SP-800-89_November2006.pdf" shash="U5mxbC4eCgJ4PEd9CKYseioSo34fTJxK1gFPYl0k7c+iUdqdfYHJiUdTD3ChoPz8m+nsizF8KnqXjN78P+pkv4vjaqKJuuHjkXMUA01wVo2nK7aG205nXFMztcXkdEt/0PKelEfehlyuRzTS9lEXw2tgTBTLDcEd3r29kQHfkBQ=" target="_blank" moz-do-not-send="true">
http://csrc.nist.gov/publications/nistpubs/800-89/SP-800-89_November2006.pdf</a>)<o:p></o:p></span></li>
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1
level1 lfo2">
<span style="font-size:12.0pt">and the Mozilla
Foundation (the Public Suffix List,
<a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fpublicsuffix.org%2F&data=05%7C01%7Cchris%40ssl.com%7Ca45a3c77d44c4f15254408da65117e42%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637933424459542060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=pDtOeMKp7umIY137RkBLUYI6N%2BkGkpADb4%2F4%2F51l%2B5A%3D&reserved=0" originalsrc="https://publicsuffix.org/" shash="IviVSEPwsKvN1c1dCrWZUuHcZXezieSGKKEfX8vd/prtGkTe1ocw+6T+FmrJPy9L2uAoyfrl3/O0VQwIXqmbFqvBzRvl2cvJd21vZc9HFhxhJhReoioniTHPHjyRZ88hO/6fT/q+HdJD0v2hkyluAxkuBxJ9QVUJe9wwrcBo5ik=" target="_blank" moz-do-not-send="true">https://publicsuffix.org/</a>).<o:p></o:p></span></li>
</ul>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">"CROSS-VETTING"
OF PROPOSED RESOURCES</span></b><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">As Dimitris
stated in the call, the two other links included
as resources which MAY be utilized:<o:p></o:p></span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l4
level1 lfo3">
<span style="font-size:12.0pt"><a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCVE-2008-0166&data=05%7C01%7Cchris%40ssl.com%7Ca45a3c77d44c4f15254408da65117e42%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637933424459542060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=UkbR9pQt0QpAz%2FUxby2iuHj931EfGPcZUCJ4JXDye0I%3D&reserved=0" originalsrc="https://github.com/CVE-2008-0166" shash="BjhSKkujX67KLXsI2tGJYARmgrbriqxAto/eXcDnOnJ6jMIoFgR0ddvbtpvEhnoGpiN5DoGRUpZ2cDghmBb33+XmE5XjxpVCQXJRDn9/5p0BViHtfovZnsGIqN+Gy62XzYQPMxwa9Acp2I2xZDxXIOw7UyuD+h7wJ3PZMFU2e4s=" target="_blank" moz-do-not-send="true">https://github.com/CVE-2008-0166</a><o:p></o:p></span></li>
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l4
level1 lfo3">
<span style="font-size:12.0pt"><a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FHARICA-official%2Fdebian-weak-keys&data=05%7C01%7Cchris%40ssl.com%7Ca45a3c77d44c4f15254408da65117e42%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637933424459542060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=kLztd113kQVC49B2BERHPbiCFdtEoQBgUVdjr8M7myo%3D&reserved=0" originalsrc="https://github.com/HARICA-official/debian-weak-keys" shash="MPSTCewsfjsQACNnMsNSzhaiq5axwbb3AXJy4jyvEQH0koxoHoLl0+5Jscmt6Tn4qnGFNndaEu1/Zqn4C/DSS0G/e7x6XYkvgEx6hRvlP3GHe016dD7jBVSqWsFVy9hfBfluCRXE/AeLVvoMap23VzNoik63I2YgYuX+Zia2M/g=" target="_blank" moz-do-not-send="true">https://github.com/HARICA-official/debian-weak-keys</a><o:p></o:p></span></li>
</ul>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">... have
been "cross-vetted" by their respective
providers (HARICA and Sectigo).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">This
discussion was spurred by a suggestion from
Adriano Santoni to consider adding a third
resource (Hanno Böck's badkeys tool):<o:p></o:p></span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2
level1 lfo4">
<span style="font-size:12.0pt"><a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbadkeys%2Fbadkeys&data=05%7C01%7Cchris%40ssl.com%7Ca45a3c77d44c4f15254408da65117e42%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637933424459542060%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=MvB1tM3arDUQRGaJTR7xyrhh%2BVvibPIRqtMjn3MhCH0%3D&reserved=0" originalsrc="https://github.com/badkeys/badkeys" shash="ayNmKanB6g9IrmRqUGcoxDW7Rj2Qtocfxaxiblc3MdqIKaainLrluO0+Sl87HeH4lFWqLufSfK4J0ArcL2EoUH9gv4lbzX3RlT9+6yYTGmtIDt9BLZI6SrWHB50cH3Vi6V2KmYg96grEfqTBIBPAt3fV7DaF6/6LQr+KkBp99Ng=" target="_blank" moz-do-not-send="true">https://github.com/badkeys/badkeys</a>
(web version:
<a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbadkeys.info%2F&data=05%7C01%7Cchris%40ssl.com%7Ca45a3c77d44c4f15254408da65117e42%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637933424459698273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=q9HQjYjMHKuIH00RgHmC7rgg6ZyZqeBqUPs7j6KbB%2F0%3D&reserved=0" originalsrc="https://badkeys.info/" shash="lmF9qKFleWr7Z5wgnow/h1IE4cGTvE2Q3eMnoCcml/7koSaE8sr7tx7SpnnV1BAyUlHE1DU9y8fyHGmZEaU32d3jtOobxFUSZAQKXTHoPJYZW56YLOLJdpcRXzQPgIVoMX1FOMt2y6mYJ+11G8k+fJMXI8cRgsYywg3RGmSaL24=" target="_blank" moz-do-not-send="true">https://badkeys.info/</a>)<o:p></o:p></span></li>
</ul>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt;color:black">...for
which no such CABF-level "cross-vetting" has
been performed (as far as we know).<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:12.0pt;color:black">We
ourselves very much appreciate the effort that
went into creating these tools and intend to
utilize them. However:<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">TO
RESTATE THE QUESTIONS</span></b><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
level1 lfo5">
<b><span style="font-size:12.0pt">Is the ballot
process itself considered adequate vetting
for external links in CABF documents?</span></b><span style="font-size:12.0pt"><o:p></o:p></span></li>
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
level1 lfo5">
<span style="font-size:12.0pt">If not, <b>what
vetting would we consider adequate?</b><o:p></o:p></span></li>
</ul>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">SIDEBAR:
OTHER OPTIONS</span></b><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
</div>
<div>
<ul type="disc">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3
level1 lfo6">
<span style="font-size:12.0pt">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>.<o:p></o:p></span></li>
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3
level1 lfo6">
<span style="font-size:12.0pt">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?<o:p></o:p></span></li>
</ul>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">CLOSING
REMARKS</span></b><span style="font-size:12.0pt;color:black"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"><o:p> </o:p></span></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Thanks.<o:p></o:p></span></p>
</div>
<div class="MsoNormal" style="text-align:center" align="center">
<hr width="98%" size="2" align="center">
</div>
<div id="gmail-m_8952578848581799150divRplyFwdMsg">
<p class="MsoNormal"><b><span style="color:black">From:</span></b><span style="color:black"> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg-bounces@cabforum.org</a>>
on behalf of Adriano Santoni via Servercert-wg
<<a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>><br>
<b>Sent:</b> Sunday, June 12, 2022 7:11 PM<br>
<b>To:</b> <a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>
<<a href="mailto:servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>><br>
<b>Cc:</b> Hanno Böck <<a href="mailto:hanno@hboeck.de" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">hanno@hboeck.de</a>><br>
<b>Subject:</b> Re: [Servercert-wg] SCXX Ballot -
Debian Weak Keys (and related vulnerabilities)</span>
<o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<div>
<p>Might a third option be the tool developed by Hanno
Boeck?<o:p></o:p></p>
<p><a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fbadkeys%2Fbadkeys&data=05%7C01%7Cchris%40ssl.com%7Ca45a3c77d44c4f15254408da65117e42%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637933424459698273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=lrjBAYPaVoTj23aKP6K%2F1dJjkyDahkoOd7d4l4bo%2BbU%3D&reserved=0" originalsrc="https://github.com/badkeys/badkeys" shash="AVi18fWn10PcsSTlJd3LK3AtErAWeoNtpK+fvCAD7AHNy6a9F3hMZRWeIXfPw1bcuSzzVMrM7EERaaQ/fLe9tjfRShwKBAmLzOsA97eAyZFkulA2M7ybum/yD+Y+1TLfNSOpUtGQiaW3o2CM9u4Af9ftXvryARMlftq+QdiIJXM=" target="_blank" moz-do-not-send="true">https://github.com/badkeys/badkeys</a><o:p></o:p></p>
<p>From our point of view it's an effective tool.<o:p></o:p></p>
<p>Adriano<o:p></o:p></p>
<p><o:p> </o:p></p>
<div>
<p class="MsoNormal">Il 09/06/2022 15:18, Chris
Kemmerer via Servercert-wg ha scritto:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">Suggested tools that CAs MAY
use to obtain lists of Debian weak keys include:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> - <a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FCVE-2008-0166&data=05%7C01%7Cchris%40ssl.com%7Ca45a3c77d44c4f15254408da65117e42%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637933424459698273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=NyBmBazjBeW4jxL5i4KIDW8X1W5b2eKk1G320LQ8EW8%3D&reserved=0" originalsrc="https://github.com/CVE-2008-0166" shash="Wzp0MgMo4i1QWhQcEjTuJwLl76SF88KbB2k3BtRFhoNUmwnL7H9GUNIKR2ScUwcDZMuIwSUn3jDf2QmoVv/MkU3WRs4imj6F9S8d8RK0AaMxX7bPX5RZAo+sOaodyjOnVAN/HcdRfaj0XVeHCGd8rXxxwevtE5/Tj0XpEqReYSY=" target="_blank" moz-do-not-send="true">
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.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> - <a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2FHARICA-official%2Fdebian-weak-keys&data=05%7C01%7Cchris%40ssl.com%7Ca45a3c77d44c4f15254408da65117e42%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637933424459698273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=0mcLLJCHl962S6LfSaWhuqaQqqd9hUI42j%2FgJol1X4Q%3D&reserved=0" originalsrc="https://github.com/HARICA-official/debian-weak-keys" shash="xiTpxPwBdFkXmIjbyQFqvLFqmDZtZVjuG6O99Khiv6eZo+eqYirDPLjdTyiKT6e2SWm5OGQxG/hXwNLywhHhXmKluqHzOU2sqIhKFZPMH6bMvQKbHUntd2Up+lecgK3HehRBfuKNIRIApp7jVc8Pd6miGXqSf6sgdRowK/sIP0Y=" target="_blank" moz-do-not-send="true">
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.<o:p></o:p></p>
</div>
</blockquote>
</div>
</div>
<p class="MsoNormal">_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">Servercert-wg@cabforum.org</a><br>
<a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.cabforum.org%2Fmailman%2Flistinfo%2Fservercert-wg&data=05%7C01%7Cchris%40ssl.com%7Ca45a3c77d44c4f15254408da65117e42%7C7741372af1ae4cc7b93ce6c2c138b2bb%7C0%7C0%7C637933424459698273%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C2000%7C%7C%7C&sdata=O7bk2oASqj9L3Bb59a9ZnA4jt7ifpJXzWydUQssMZAQ%3D&reserved=0" originalsrc="https://lists.cabforum.org/mailman/listinfo/servercert-wg" shash="Toj19wswnlFIcBCaQ5U2i/pOmYgz8RyT7j4PvqGuPufEU+gYBBRzRmpC5jBkyl8RzdhVFx9OTaGGBhgoGDV7FXZJ2n3gyb9jZvVr47zangLKFWoWpbqOXUvmeam+aa+HsqSUGLqi/+NlIUyiEu1cw8CXwsmP85Nbt02ObqedIbE=" target="_blank" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</div>
</blockquote>
</body>
</html>