<html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body>
<p>Martijn and all,<br>
<br>
I agree with you that anything helping CAs comply with
requirements should be made available, and am glad the tools we've
been discussing are already available on the CABF site.<br>
<br>
However, the sense of the discussion last Thursday was that the
proposal to refer readers to specific resources in the text of the
BRs opens several questions and potential issues (particularly
vetting and maintenance of links, IIRC) which are best addressed
by simply removing the references from the BRs entirely.<br>
<br>
(Note that <a class="moz-txt-link-freetext" href="https://cabforum.org/resources/tools/">https://cabforum.org/resources/tools/</a> includes many
items which the community uses on a daily basis [e.g. crt.sh] but
which the BRs do not specify as tools fit for a given purpose, so
this would seem to be the precedent to follow.)<br>
<br>
That said, a more general reference somewhere in the BRs to the
/tools page would seem to be a Good Thing, but probably not in
scope for this ballot.<br>
<br>
Chris K<br>
</p>
<div class="moz-cite-prefix">On 7/26/2022 3:24 AM, Martijn Katerbarg
wrote:<br>
</div>
<blockquote type="cite" cite="mid:MW5PR17MB6012DCDA849976D173960896E3949@MW5PR17MB6012.namprd17.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:"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:"Segoe UI Emoji";
panose-1:2 11 5 2 4 2 4 2 2 3;}@font-face
{font-family:inherit;}p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}span.EmailStyle21
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}div.WordSection1
{page:WordSection1;}ol
{margin-bottom:0cm;}ul
{margin-bottom:0cm;}</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"><span style="mso-fareast-language:EN-US" lang="EN-US">Chris, All,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-US">I was reading through the minutes of the last
meeting to see why the references were removed since I was
unable to attend.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-US">While I do understand the reasoning, I would
recommend adding a reference in the language, pointing to
the correct section of the website that is actually listing
the tools. <o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-US">It looks like we’re already planning to make it
more clear on the website that these tools belong to this
requirement. However, I expect most CA’s and other parties
wanting to comply with BR requirement to read and
investigate the BRs, not the Tools page on the CA/B website.
<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="EN-US">Therefore I’d like to suggest adding the
following sentence before the Motion Ends line in your
proposal:</span><span lang="EN-US"> “A non-exhausting list
of tools and resources capable of assisting to comply with
these requirements can be found at <a href="https://cabforum.org/resources/tools/" moz-do-not-send="true" class="moz-txt-link-freetext">https://cabforum.org/resources/tools/</a>”<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US">Martijn<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US" lang="en-SE"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> 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>Chris Kemmerer via Servercert-wg<br>
<b>Sent:</b> Monday, 25 July 2022 18:19<br>
<b>To:</b> Tim Hollebeek
<a class="moz-txt-link-rfc2396E" href="mailto:tim.hollebeek@digicert.com"><tim.hollebeek@digicert.com></a>; Aaron Gable
<a class="moz-txt-link-rfc2396E" href="mailto:aaron@letsencrypt.org"><aaron@letsencrypt.org></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></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:solid black 1.0pt;padding:2.0pt 2.0pt 2.0pt
2.0pt">
<p class="MsoNormal" style="line-height:12.0pt;background:#FAFA03"><span style="font-size:10.0pt;color:black">CAUTION: 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.<o:p></o:p></span></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<p style="margin-bottom:12.0pt">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>
=====<o:p></o:p></p>
<div>
<p class="MsoNormal">--- Motion Begins ---<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt">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:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b>Proposed ballot language:</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">4.9.1.1 Reasons for Revoking a
Subscriber Certificate<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b>Replace:</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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 href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075534002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2hjyo2PcEKLZFcAcCW%2FmQ7llWWXCNPhYISm2uF3zEIE%3D&reserved=0" moz-do-not-send="true">https://wiki.debian.org/SSLkeys</a>)<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b>With:</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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)).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">---<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">6.1.1.3. Subscriber Key Pair Generation<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b>Replace:</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The CA SHALL reject a certificate
request if one or more of the following conditions are
met:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1. The Key Pair does not meet the
requirements set forth in Section 6.1.5 and/or Section
6.1.6;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2. There is clear evidence that the
specific method used to generate the Private Key was
flawed;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">3. The CA is aware of a demonstrated or
proven method that exposes the Applicant's Private Key to
compromise;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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 href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075534002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2hjyo2PcEKLZFcAcCW%2FmQ7llWWXCNPhYISm2uF3zEIE%3D&reserved=0" moz-do-not-send="true">https://wiki.debian.org/SSLkeys</a>).<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b>With:</b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">The CA SHALL reject a certificate
request if one or more of the following occurs:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">1) The requested Public Key does not
meet the requirements set forth in Sections 6.1.5 and/or
6.1.6;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">2) The CA is aware of a demonstrated or
proven method that exposes the Subscriber's Private Key to
compromise;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">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;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">4) The Public Key corresponds to an
industry demonstrated weak Private Key, in particular:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">a) In the case of ROCA vulnerability,
the CA SHALL 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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075534002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=W1Pxb77B2WKbKkM92SO5382czGJ8ou04JKiQ0LEGaz0%3D&reserved=0" moz-do-not-send="true">https://github.com/crocs-muni/roca</a>
or equivalent.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">b) In the case of Debian weak keys (<a href="https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwiki.debian.org%2FSSLkeys&data=05%7C01%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075534002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2hjyo2PcEKLZFcAcCW%2FmQ7llWWXCNPhYISm2uF3zEIE%3D&reserved=0" moz-do-not-send="true">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:<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">i) Big-endian 32-bit, little-endian
32-bit, and little-endian 64-bit architecture;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">ii) Process ID of 0 to 32767,
inclusive;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">iii) All RSA Public Key lengths
supported by the CA up to and including 4096 bits;<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">iv) rnd, nornd, and noreadrnd OpenSSL
random file state.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">c) In the case of Close Primes
vulnerability, the CA SHALL reject weak keys identified
within 100 rounds using Fermat’s factorization method<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For Debian weak keys not covered above,
the CA SHALL take actions to minimize the probability of
certificate issuance.<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">CAs MUST check for Debian weak keys for
all RSA modulus lengths and exponents that they accept.<span lang="EN-US"><o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">--- Motion Ends ---<o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
=====<br>
<br>
<o:p></o:p></p>
<div>
<p class="MsoNormal">On 7/13/2022 3:51 PM, Tim Hollebeek
wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<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:0cm 0cm 0cm 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1
1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b>From:</b> Servercert-wg <a href="mailto:servercert-wg-bounces@cabforum.org" moz-do-not-send="true"><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 href="mailto:chris@ssl.com" moz-do-not-send="true"><chris@ssl.com></a>;
CA/B Forum Server Certificate WG Public Discussion
List <a href="mailto:servercert-wg@cabforum.org" moz-do-not-send="true"><servercert-wg@cabforum.org></a><br>
<b>Cc:</b> Hanno Böck <a href="mailto:hanno@hboeck.de" moz-do-not-send="true"><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:0cm 0cm 0cm
6.0pt;margin-left:4.8pt;margin-top:5.0pt;margin-right:0cm;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">INTRO</span></b><o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">THE
QUESTIONS</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">The
questions here are:</span><o:p></o:p></p>
</div>
<div>
<ol type="1" start="1">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1
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><o:p></o:p></li>
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l1
level1 lfo1"><span style="font-size:12.0pt">And</span><b><span style="font-size:12.0pt;font-family:inherit"> is the ballot process
itself sufficient vetting for such
links?</span></b><o:p></o:p></li>
</ol>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">OUR
ASSUMPTION AND EXISTING LINKS</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075534002%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=2hjyo2PcEKLZFcAcCW%2FmQ7llWWXCNPhYISm2uF3zEIE%3D&reserved=0" target="_blank" moz-do-not-send="true">https://wiki.debian.org/SSLkeys</a>),
though with a vetted status unknown to us. </span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=MrPVgvf4CvjHpdhGnh%2BcP7P%2BUxkJ%2B20RQPoabQm4dw8%3D&reserved=0" 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.</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></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:</span><o:p></o:p></p>
</div>
<div>
<ol type="1" start="1">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l4
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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Lbo28F8%2Fx2d306fLSud0u3LiWuVGOphIK6zeo6Ftel0%3D&reserved=0" target="_blank" moz-do-not-send="true">http://tools.ietf.org/html/rfc5890</a>)</span><o:p></o:p></li>
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l4
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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Hz3bMVZMFmBQesBrtTXYnSjnndcY8Mc8xgujEgOr81c%3D&reserved=0" target="_blank" moz-do-not-send="true">https://www.iana.org/assignments/iana-ipv4-special-registry/iana-ipv4-special-registry.xhtml</a>)</span><o:p></o:p></li>
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l4
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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zpIHS6JVHP8wgHQ%2FlwbgWODg8fKH6EFNT2HpMendpyA%3D&reserved=0" target="_blank" moz-do-not-send="true">http://csrc.nist.gov/publications/nistpubs/800-89/SP-800-89_November2006.pdf</a>)</span><o:p></o:p></li>
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l4
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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=Rue2szur3TchDXxc8WW5nnxkf3TCUeffsXVzooucBac%3D&reserved=0" target="_blank" moz-do-not-send="true">https://publicsuffix.org/</a>).</span><o:p></o:p></li>
</ol>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">"CROSS-VETTING"
OF PROPOSED RESOURCES</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></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:</span><o:p></o:p></p>
</div>
<div>
<ol type="1" start="1">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l5
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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bYbObWp1PySlrvcwGeFfqIKnZRarfMJKiE83abTe8yg%3D&reserved=0" target="_blank" moz-do-not-send="true">https://github.com/CVE-2008-0166</a></span><o:p></o:p></li>
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l5
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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zao1ch6I8qObN46RWPrSG9yySNsfMvSSjJ00MLSfh50%3D&reserved=0" target="_blank" moz-do-not-send="true">https://github.com/HARICA-official/debian-weak-keys</a></span><o:p></o:p></li>
</ol>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">...
have been "cross-vetted" by their respective
providers (HARICA and Sectigo).</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></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):</span><o:p></o:p></p>
</div>
<div>
<ol type="1" start="1">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l3
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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m4eFeqTReq6FPJN%2BeOai2uSa8WlPyHOBxftn9Nvw5%2BU%3D&reserved=0" 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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=sONo3h0BzG79pbUMdTFEBXYpUUoeie%2BBIuG7P2HiYe4%3D&reserved=0" target="_blank" moz-do-not-send="true">https://badkeys.info/</a>)</span><o:p></o:p></li>
</ol>
</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).</span><o:p></o:p></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:</span><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">TO
RESTATE THE QUESTIONS</span></b><o:p></o:p></p>
</div>
<div>
<ol type="1" start="1">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2
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><o:p></o:p></li>
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l2
level1 lfo5"><span style="font-size:12.0pt">If
not, <b>what vetting would we consider
adequate?</b></span><o:p></o:p></li>
</ol>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">SIDEBAR:
OTHER OPTIONS</span></b><o:p></o:p></p>
</div>
<div>
<ol type="1" start="1">
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
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>.</span><o:p></o:p></li>
<li class="MsoNormal" style="color:black;mso-margin-top-alt:auto;mso-margin-bottom-alt:auto;mso-list:l0
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?</span><o:p></o:p></li>
</ol>
</div>
<div>
<p class="MsoNormal"><b><span style="font-size:12.0pt;color:black">CLOSING
REMARKS</span></b><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black"> </span><o:p></o:p></p>
</div>
<p class="MsoNormal"><span style="font-size:12.0pt;color:black">Thanks.</span><o:p></o:p></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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=m4eFeqTReq6FPJN%2BeOai2uSa8WlPyHOBxftn9Nvw5%2BU%3D&reserved=0" 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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=bYbObWp1PySlrvcwGeFfqIKnZRarfMJKiE83abTe8yg%3D&reserved=0" 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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=zao1ch6I8qObN46RWPrSG9yySNsfMvSSjJ00MLSfh50%3D&reserved=0" 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%7Cmartijn.katerbarg%40sectigo.com%7C70d815a3cc924bf1521f08da6e596262%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C637943629075690223%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=EB6%2FDIQzZhpDbJobRVn2dHqskn7r5yIKfZmoMoS%2BKfc%3D&reserved=0" target="_blank" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></p>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>