<div dir="ltr"><span id="m_-5254082314308633194gmail-docs-internal-guid-c76419bc-7fff-1008-d5ed-2eb7b622711e"><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">[back to discussing the ballot] </span></p><p style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"><br></span></p><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">Hi all,</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">I raised the following question during the </span><a href="https://cabforum.org/2023/01/19/2023-01-19-minutes-of-the-server-certificate-working-group/" style="text-decoration-line:none" target="_blank"><span style="font-family:Arial;color:rgb(74,110,224);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;text-decoration-line:underline;vertical-align:baseline">January 19th</span></a><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"> SCWG meeting, but I recognize only some group members can participate in our regularly scheduled meetings.</span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">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></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">While I appreciate the work carried out by ecosystem members to produce this ballot, primarily led by the </span><a href="http://ssl.com" style="text-decoration-line:none" target="_blank"><span style="font-family:Arial;color:rgb(74,110,224);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;text-decoration-line:underline;vertical-align:baseline">SSL.com</span></a><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline"> team, I struggle with the demonstrated security value of these checks compared to the overall effort they represent. </span></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">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></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(14,16,26);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">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></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">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></p><br><p dir="ltr" style="line-height:1.38;margin-top:0pt;margin-bottom:0pt"><span style="font-family:Arial;color:rgb(0,0,0);background-color:transparent;font-variant-numeric:normal;font-variant-east-asian:normal;font-variant-alternates:normal;vertical-align:baseline">- Ryan</span></p></span><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">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:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
Hi Clint,<br>
<br>
<div>On 26/5/2023 6:45 μ.μ., Clint Wilson
wrote:<br>
</div>
<blockquote type="cite">
Hi Tom, Dimitris,
<div><br>
</div>
<div>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.</div>
<div>
<div><br>
</div>
<div>If there’s a particular penchant towards March and
September, however, then I’d be unopposed to March, May, July,
September, and November 15th. </div>
<div><br>
</div>
<div>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.</div>
</div>
</blockquote>
<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>
<blockquote type="cite">
<div>
<div><br>
</div>
<div>Thanks,</div>
<div>-Clint</div>
<div><br>
<blockquote type="cite">
<div>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:</div>
<br>
<div>
<div style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Hello Dimitris,<u></u><u></u></div>
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Thank you for the input. We
feel that September 15<sup>th</sup><span> </span>does not
provide enough time for CAs to implement these
changes, but we are not against the March 15,<span> </span><sup> </sup>2024
effective date, if there is consensus from the
Community.<span> </span><u></u><u></u></div>
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Thank you,<u></u><u></u></div>
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">Tom<u></u><u></u></div>
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><a href="http://ssl.com/" style="color:blue;text-decoration:underline" target="_blank">SSL.com</a><u></u><u></u></div>
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
<div>
<div style="border-width:1pt medium medium;border-style:solid none none;border-color:rgb(225,225,225) currentcolor currentcolor;padding:3pt 0in 0in">
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><b><span>From:</span></b><span><span> </span>Servercert-wg
<<a href="mailto:servercert-wg-bounces@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">servercert-wg-bounces@cabforum.org</a>><span> </span><b>On
Behalf Of<span> </span></b>Dimitris
Zacharopoulos (HARICA) via Servercert-wg<br>
<b>Sent:</b><span> </span>Friday,
May 26, 2023 1:54 AM<br>
<b>To:</b><span> </span><a href="mailto:servercert-wg@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">servercert-wg@cabforum.org</a><br>
<b>Subject:</b><span> </span>Re:
[Servercert-wg] SC-59 Weak Key Guidance<u></u><u></u></span></div>
</div>
</div>
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><u></u> <u></u></div>
<p class="MsoNormal" style="margin:0in 0in 12pt;font-size:11pt;font-family:Calibri,sans-serif"><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<span> </span><a href="https://docs.google.com/presentation/d/1oTGVYqggQpQMR4Lktbu_L6DhuBVJzeuiFGd9EAU1zsE" style="color:blue;text-decoration:underline" target="_blank">more favorable</a><span> </span>than others.<span> </span><br>
<br>
<br>
Thanks,<br>
Dimitris.<span><u></u><u></u></span></p>
<div>
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif">On 25/5/2023 10:51 μ.μ., Tom
Zermeno via Servercert-wg wrote:<u></u><u></u></div>
</div>
<blockquote style="margin-top:5pt;margin-bottom:5pt">
<p style="margin-right:0in;margin-left:0in;font-size:11pt;font-family:Calibri,sans-serif;vertical-align:baseline"><span>Purpose of Ballot SC-059 V3</span><span> </span><u></u><u></u></p>
<p style="margin-right:0in;margin-left:0in;font-size:11pt;font-family:Calibri,sans-serif;vertical-align:baseline"><span>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.</span><span> </span><u></u><u></u></p>
<p style="margin-right:0in;margin-left:0in;font-size:11pt;font-family:Calibri,sans-serif;vertical-align:baseline"><span>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.<span> </span></span><span> </span><u></u><u></u></p>
<p style="margin-right:0in;margin-left:0in;font-size:11pt;font-family:Calibri,sans-serif;vertical-align:baseline"><span><span>The following
motion has been proposed by Thomas Zermeno of<span> </span><a href="http://ssl.com/" style="color:blue;text-decoration:underline" target="_blank">SSL.com</a><span> </span>and
endorsed by Ben Wilson of Mozilla and Martijn
Katerbarg of Sectigo.</span></span><span><span> </span></span><u></u><u></u></p>
<p style="margin-right:0in;margin-left:0in;font-size:11pt;font-family:Calibri,sans-serif;vertical-align:baseline"><span>--Motion Begins—</span><span> </span><u></u><u></u></p>
<p style="margin-right:0in;margin-left:0in;font-size:11pt;font-family:Calibri,sans-serif;vertical-align:baseline"><span><span style="font-size:12pt">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.<span> </span></span></span><span><span style="font-size:12pt"> </span></span><span style="font-size:12pt"><br>
<span> </span><br>
<span>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><span> </span></span><u></u><u></u></p>
<p style="margin-right:0in;margin-left:0in;font-size:11pt;font-family:Calibri,sans-serif;vertical-align:baseline"><span> </span><span> </span><u></u><u></u></p>
<p style="margin-right:0in;margin-left:0in;font-size:11pt;font-family:Calibri,sans-serif;vertical-align:baseline"><span><span>MODIFY the
Baseline Requirements as specified in the
following Redline:<span> </span></span></span><a href="https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3...SSLcom:servercert:3b0c6de32595d02fbd96762cda98cdc88addef00" style="color:blue;text-decoration:underline" target="_blank"><span><span>https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3...SSLcom:servercert:3b0c6de32595d02fbd96762cda98cdc88addef00</span></span></a><span><span> </span></span><u></u><u></u></p>
<p style="margin-right:0in;margin-left:0in;font-size:11pt;font-family:Calibri,sans-serif;vertical-align:baseline"><span> </span><span> </span><u></u><u></u></p>
<p style="margin-right:0in;margin-left:0in;font-size:11pt;font-family:Calibri,sans-serif;vertical-align:baseline"><span>--Motion Ends—</span><span> </span><u></u><u></u></p>
<p style="margin-right:0in;margin-left:0in;font-size:11pt;font-family:Calibri,sans-serif;vertical-align:baseline"><span>This ballot proposes a Final
Maintenance Guideline. The procedure for approval
of this ballot is as follows:</span><span> </span><u></u><u></u></p>
<p style="margin-right:0in;margin-left:0in;font-size:11pt;font-family:Calibri,sans-serif;vertical-align:baseline"><span>Discussion (11+ days) •
Start time: 2023-05-25 19:00:00 UTC • End time:
2023-06-08 18:59:00 UTC</span><span> </span><br>
<span>Vote for approval (7
days) • Start time: TBD • End time: TBD</span><span> </span><u></u><u></u></p>
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"> <u></u><u></u></div>
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span><br>
<br>
<u></u><u></u></span></div>
<pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">_______________________________________________<u></u><u></u></pre>
<pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New"">Servercert-wg mailing list<u></u><u></u></pre>
<pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""><a href="mailto:Servercert-wg@cabforum.org" style="color:blue;text-decoration:underline" target="_blank">Servercert-wg@cabforum.org</a><u></u><u></u></pre>
<pre style="margin:0in 0in 0.0001pt;font-size:10pt;font-family:"Courier New""><a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" style="color:blue;text-decoration:underline" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><u></u><u></u></pre>
</blockquote>
<div style="margin:0in;font-size:11pt;font-family:Calibri,sans-serif"><span><u></u> <u></u></span></div>
</div>
<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">_______________________________________________</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<span style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none;float:none;display:inline">Servercert-wg mailing list</span><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<a href="mailto:Servercert-wg@cabforum.org" style="color:blue;text-decoration:underline;font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">Servercert-wg@cabforum.org</a><br style="font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;text-decoration:none">
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" style="color:blue;text-decoration:underline;font-family:Helvetica;font-size:12px;font-style:normal;font-variant-caps:normal;font-weight:400;letter-spacing:normal;text-align:start;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a></div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div>
_______________________________________________<br>
Servercert-wg mailing list<br>
<a href="mailto:Servercert-wg@cabforum.org" target="_blank">Servercert-wg@cabforum.org</a><br>
<a href="https://lists.cabforum.org/mailman/listinfo/servercert-wg" rel="noreferrer" target="_blank">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a><br>
</blockquote></div>