<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<!--[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 Definitions */
@font-face
{font-family:Helvetica;
panose-1:2 11 6 4 2 2 2 2 2 4;}
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:DengXian;
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
{font-family:"\@DengXian";
panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
{font-family:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
pre
{mso-style-priority:99;
mso-style-link:"HTML Preformatted Char";
margin:0in;
font-size:10.0pt;
font-family:"Courier New";}
span.HTMLPreformattedChar
{mso-style-name:"HTML Preformatted Char";
mso-style-priority:99;
mso-style-link:"HTML Preformatted";
font-family:Consolas;
mso-ligatures:none;}
span.EmailStyle21
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-ligatures:standardcontextual;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">Hi Ryan,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">I like your direction, but I need some help understanding how “requiring pre-/post-issuance linting instead of weak-key checks” would reduce the effort by the CA? I’m assuming a CA can meet the proposed ballot by doing pre-issuance linting
of the CSR? <o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks, Bruce.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> Servercert-wg <servercert-wg-bounces@cabforum.org>
<b>On Behalf Of </b>Ryan Dickson via Servercert-wg<br>
<b>Sent:</b> Thursday, June 1, 2023 9:44 AM<br>
<b>To:</b> Dimitris Zacharopoulos (HARICA) <dzacharo@harica.gr>; CA/B Forum Server Certificate WG Public Discussion List <servercert-wg@cabforum.org><br>
<b>Subject:</b> [EXTERNAL] Re: [Servercert-wg] SC-59 Weak Key Guidance<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">WARNING: This email originated outside of Entrust.<br>
DO NOT CLICK links or attachments unless you trust the sender and know the content is safe.<o:p></o:p></p>
<div class="MsoNormal" align="center" style="text-align:center">
<hr size="2" width="100%" align="center">
</div>
<div>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:black">[back to discussing the ballot]
</span><o:p></o:p></p>
<p style="margin:0in"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:black">Hi all,</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">I raised the following question during the
</span><a href="https://urldefense.com/v3/__https:/cabforum.org/2023/01/19/2023-01-19-minutes-of-the-server-certificate-working-group/__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEn9o8sx8A$" target="_blank"><span style="font-family:"Arial",sans-serif;color:#4A6EE0">January
19th</span></a><span style="font-family:"Arial",sans-serif;color:#0E101A"> SCWG meeting, but I recognize only some group members can participate in our regularly scheduled meetings.</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">Do participants in this Forum feel that weak-key checks should be removed from the scope of a CA’s set of mandatory responsibilities? </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">While I appreciate the work carried out by ecosystem members to produce this ballot, primarily led by the
</span><a href="https://urldefense.com/v3/__http:/ssl.com__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIElUnEh06Q$" target="_blank"><span style="font-family:"Arial",sans-serif;color:#4A6EE0">SSL.com</span></a><span style="font-family:"Arial",sans-serif;color:#0E101A">
team, I struggle with the demonstrated security value of these checks compared to the overall effort they represent. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">In a recent Validation Subcommittee meeting where we focused on delegating parts of the domain validation process, we discussed that subscribers often make security decisions that
can have considerable consequences but are ultimately beyond the CA’s scope of responsibility (for example, delegating domain validation to an insecure third-party service). Wouldn’t we consider using an outdated software application/library to generate key-pairs
along the same lines?</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:#0E101A">Beyond perceived security value, I also struggle with the opportunity cost of time spent evaluating weak keys and responding to weak key incidents. It seems to me that something
like requiring pre-/post-issuance linting instead of weak-key checks is a better tradeoff and would be more valuable for the ecosystem (e.g., reducing the likelihood of unexpected customer impact due to prescribed revocations timelines in the BRs related to
mis-issuance). </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:black">As this is now in discussion, I wanted to again offer the perspective that maybe weak-key checks should not be in scope of a CA’s responsibilities in case others share the same opinion. </span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p style="margin:0in"><span style="font-family:"Arial",sans-serif;color:black">- Ryan</span><o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<p class="MsoNormal">On Mon, May 29, 2023 at 1:18 AM Dimitris Zacharopoulos (HARICA) via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org" target="_blank">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>
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi Clint,<o:p></o:p></p>
<div>
<p class="MsoNormal">On 26/5/2023 6:45 μ.μ., Clint Wilson wrote:<o:p></o:p></p>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p class="MsoNormal">Hi Tom, Dimitris, <o:p></o:p></p>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">I continue to be opposed to the SCWG trying to limit effective dates to 2 per year. I think it’s entirely reasonable to align on a day of the month (I think the 15th has broadly been the only one I’ve heard proposed). I think it’s reasonable
to try to avoid January and December. I also think there may be value in trying to reduce the overall number of effective dates somewhat. The dates I’m personally in favor of aligning on are February, April, June, August, and October 15th.<o:p></o:p></p>
</div>
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">If there’s a particular penchant towards March and September, however, then I’d be unopposed to March, May, July, September, and November 15th. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">For this ballot in particular, I think October 15 or November 15 2023 are feasible targets for implementing these changes and would greatly prefer closing this issue (open now for
<u>more than 3 years</u>) sooner than later, especially given the number of incidents we’ve seen in the last years related to weak key vulnerabilities and CAs issuing certificates with weak keys.<o:p></o:p></p>
</div>
</div>
</blockquote>
<p class="MsoNormal"><br>
It's fine for me also to close this issue sooner than later which is why I recommended even the September 15, 2023 effective date.<br>
<br>
On the 2 document releases per year issue, this is a preliminary result after having long discussions. I was not aware of any opposition until now, but perhaps your opposition didn't consider the emergency options of the proposal? The "standardized release
cycle for Guidelines" proposal addresses a series of concerns about the frequency and number of document updates, as highlighted in the presentation shared in my previous reply. If you recall, the proposal still allows the release of "Emergency Guidelines"
that bypasses the 6-month regular release cycle. We still need to work on the details which I hope to make progress on after passing the first Bylaws updates that are already prepared, but I'm confident that all concerns will be addressed.<br>
<br>
If we use this ballot as an example for applying the "standardized release cycle for Guidelines", Apple would propose that this is an Emergency Guideline and specify an effective date that would not be one of March 15 or September 15. If there was no opposition,
we would proceed with a ballot that would result in an emergency guideline release and the proposed effective date exactly as we normally do today.<br>
<br>
I plan to start a separate thread to continue this discussion at the Forum level after we make some progress with the recently proposed Bylaws changes.<br>
<br>
<br>
Thanks,<br>
Dimitris.<br>
<br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<div>
<p class="MsoNormal">Thanks,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">-Clint<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
<o:p></o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal">On May 26, 2023, at 7:37 AM, Tom Zermeno via Servercert-wg <a href="mailto:servercert-wg@cabforum.org" target="_blank">
<servercert-wg@cabforum.org></a> wrote:<o:p></o:p></p>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<div>
<div>
<div>
<p class="MsoNormal">Hello Dimitris,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Thank you for the input. We feel that September 15<sup>th</sup> does not provide enough time for CAs to implement these changes, but we are not against the March 15, <sup> </sup>2024 effective date, if there is consensus from the Community. <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Thank you,<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal">Tom<o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"><a href="https://urldefense.com/v3/__http:/ssl.com/__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmQZfKH8A$" target="_blank">SSL.com</a><o:p></o:p></p>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<div style="border:none;border-top:solid windowtext 1.0pt;padding:3.0pt 0in 0in 0in;border-color:currentcolor currentcolor">
<div>
<p class="MsoNormal"><b>From:</b> Servercert-wg <<a href="mailto:servercert-wg-bounces@cabforum.org" target="_blank">servercert-wg-bounces@cabforum.org</a>> <b>On Behalf Of </b>Dimitris Zacharopoulos (HARICA) via Servercert-wg<br>
<b>Sent:</b> Friday, May 26, 2023 1:54 AM<br>
<b>To:</b> <a href="mailto:servercert-wg@cabforum.org" target="_blank">servercert-wg@cabforum.org</a><br>
<b>Subject:</b> Re: [Servercert-wg] SC-59 Weak Key Guidance<o:p></o:p></p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
Hi Tom,<br>
<br>
Historically, the SCWG has been trying to avoid effective dates during January or December. I recommend using September 15, 2023 or March 15, 2024 as possible effective dates. These two dates seem to be <a href="https://urldefense.com/v3/__https:/docs.google.com/presentation/d/1oTGVYqggQpQMR4Lktbu_L6DhuBVJzeuiFGd9EAU1zsE__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmlvDMTQg$" target="_blank">more
favorable</a> than others. <br>
<br>
<br>
Thanks,<br>
Dimitris.<o:p></o:p></p>
<div>
<div>
<p class="MsoNormal">On 25/5/2023 10:51 μ.μ., Tom Zermeno via Servercert-wg wrote:<o:p></o:p></p>
</div>
</div>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<p style="vertical-align:baseline">Purpose of Ballot SC-059 V3 <o:p></o:p></p>
<p style="vertical-align:baseline">Several events within the community have led to concerns that the Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates (BRs) lacked a specificity required to properly guide CAs on matters
dealing with the identification and processing of digital certificates based on private keys considered weak, or easy to ascertain. In the hopes that elaboration and clarity on the subject would be beneficial to the community, we are presenting updates to
§4.9.1.1(“Reasons for Revoking a Subscriber Certificate) and §6.1.1.3 (Subscriber Key Pair Generation) of the BRs. <o:p></o:p></p>
<p style="vertical-align:baseline">The first update is to §4.9.1.1 and is made to expand the scope of easily computable Private Keys from “Debian weak keys” to “those listed in section 6.1.1.3(5)”. While the initial language in the BRs did not exclude other
concerns, the use of a single example could be interpreted to mean that other easily computable Private Keys are few and far between. The next update was to §6.1.1.3(5), wherein we added specific actions to be taken for ROCA vulnerability, Debian weak keys
- both RSA and ECDSA – and Close Primes vulnerability. We also added a link to suggested tools to be used for checking weak keys. Finally, an implementation date of December 1, 2023 was added to allow CAs time to update processes to meet the requirements. <o:p></o:p></p>
<p style="vertical-align:baseline">The following motion has been proposed by Thomas Zermeno of <a href="https://urldefense.com/v3/__http:/ssl.com/__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmQZfKH8A$" target="_blank">SSL.com</a> and
endorsed by Ben Wilson of Mozilla and Martijn Katerbarg of Sectigo. <o:p></o:p></p>
<p style="vertical-align:baseline">--Motion Begins— <o:p></o:p></p>
<p style="vertical-align:baseline"><span style="font-size:12.0pt">This ballot is intended to clarify CA responsibilities regarding weak key vulnerabilities, including specific guidance for Debian weak key, ROCA and Close Primes attack vulnerabilities, and modifies
the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” as follows, based on Version 2.0.0. <br>
<br>
Notes: Upon beginning discussion for SC-59, the then-current version of the BRs was 1.8.4; since that time several ballots have been approved, leading to the increment of the version to 1.8.7 and eventually 2.0.0, which is the latest approved version of the
BRs. The changes introduced in SC-59 do not conflict with any of the recent ballots. As observed with other ballots in the past, minor administrative updates must be made to the proposed ballot text before publication such that the appropriate Version # and
Change History are accurately represented (e.g., to indicate these changes will be represented in Version 2.0.1). </span><o:p></o:p></p>
<p style="vertical-align:baseline"> <o:p></o:p></p>
<p style="vertical-align:baseline">MODIFY the Baseline Requirements as specified in the following Redline: <a href="https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3...SSLcom:servercert:3b0c6de32595d02fbd96762cda98cdc88addef00__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEkXOeodFw$" target="_blank">https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3...SSLcom:servercert:3b0c6de32595d02fbd96762cda98cdc88addef00</a> <o:p></o:p></p>
<p style="vertical-align:baseline"> <o:p></o:p></p>
<p style="vertical-align:baseline">--Motion Ends— <o:p></o:p></p>
<p style="vertical-align:baseline">This ballot proposes a Final Maintenance Guideline. The procedure for approval of this ballot is as follows: <o:p></o:p></p>
<p style="vertical-align:baseline">Discussion (11+ days) • Start time: 2023-05-25 19:00:00 UTC • End time: 2023-06-08 18:59:00 UTC <br>
Vote for approval (7 days) • Start time: TBD • End time: TBD <o:p></o:p></p>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p> </o:p></p>
</div>
<pre>_______________________________________________<o:p></o:p></pre>
<pre>Servercert-wg mailing list<o:p></o:p></pre>
<pre><a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><o:p></o:p></pre>
<pre><a href="https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmdDgTqEQ$" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></pre>
</blockquote>
<div>
<p class="MsoNormal"> <o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">_______________________________________________<br>
Servercert-wg mailing list<br>
</span><a href="mailto:Servercert-wg@cabforum.org" target="_blank"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">Servercert-wg@cabforum.org</span></a><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif"><br>
</span><a href="https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmdDgTqEQ$" target="_blank"><span style="font-size:9.0pt;font-family:"Helvetica",sans-serif">https://lists.cabforum.org/mailman/listinfo/servercert-wg</span></a><o:p></o:p></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
</blockquote>
<p class="MsoNormal"><o:p> </o:p></p>
</div>
<p class="MsoNormal">_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmdDgTqEQ$" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><o:p></o:p></p>
</blockquote>
</div>
</div>
<i>Any email and files/attachments transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. If this message has been sent to you in error, you must not copy, distribute or disclose of the
information it contains. <u>Please notify Entrust immediately</u> and delete the message from your system.</i>
</body>
</html>