<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
FWIW, I think Certificate Applicants have incredibly low probability
of using the old insecure Debian libraries to generate keys in 2023.
In recent cases, mostly security researchers attempted to submit
vulnerable keys to test if CAs followed the BRs in that regard.<br>
<br>
However, a CA checking EVERY CSR submitted against a list of
vulnerable Debian keys seems to increase the cost of issuance
(delays, etc). If a CA wants to increase the size of RSA keys to
-say- 6144bits, that CA would need to pre-calculate the weak private
keys of that size and the related permutations, before being allowed
to accept CSRs with keys of that size.<br>
<br>
The actual key lookup is not such a painful or CPU intensive process
because the comparison is usually done with hashes. The vulnerable
key generation of large key sizes is. I recall HARICA spending a lot
of resources to calculate the 4096 bit keys posted in
<a class="moz-txt-link-freetext" href="https://github.com/HARICA-official/debian-weak-keys">https://github.com/HARICA-official/debian-weak-keys</a>.<br>
<br>
This does not apply to more "modern" key attacks, like the Fermat
factorization method where CAs could play an important role
protecting unsuspecting Subscribers and Relying Parties.<br>
<br>
<br>
Thanks,<br>
Dimitris.<br>
<br>
<br>
<div class="moz-cite-prefix">On 1/6/2023 5:31 μ.μ., Ryan Dickson
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CADEW5O88gwfM0ZzS5B9nxtDAhX7BF8eATC7t0bgxUw0oYCZu9Q@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">Hi Bruce,<br>
<br>
Sorry for not being clear.
<div><br>
</div>
<div>I was using linting as an example of an automated check
that would occur at roughly the same frequency as we observe
necessary for weak-key checks (i.e., once for every
certificate). While I can't easily quantify the difference in
effort comparing linting versus weak-key checking, based on
incident disclosures to Bugzilla - we often see issues that
could have been prevented with linting, but rarely see
incidents related to weak-keys. It's also not clear, on
average, what % of certificate requests are rejected due to a
violation of 6.1.1.3 (i.e., how prevalent is the "weak-keys
problem"?)<br>
<br>
I didn't intend for us to shift the scope of this ballot to
focus on linting, but instead, to understand whether CAs
thought continued weak-key checking was considered valuable. <br>
<br>
Thanks,<br>
Ryan<br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Thu, Jun 1, 2023 at
10:09 AM Bruce Morton <<a
href="mailto:Bruce.Morton@entrust.com"
moz-do-not-send="true" class="moz-txt-link-freetext">Bruce.Morton@entrust.com</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 class="msg-8764041357669043721">
<div style="overflow-wrap: break-word;" lang="EN-US">
<div class="m_-8764041357669043721WordSection1">
<p class="MsoNormal">Hi Ryan,</p>
<p class="MsoNormal"> </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? </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal"> </p>
<p class="MsoNormal">Thanks, Bruce.</p>
<p class="MsoNormal"> </p>
<div
style="border-right:none;border-bottom:none;border-left:none;border-top:1pt
solid rgb(225,225,225);padding:3pt 0in 0in">
<p class="MsoNormal"><b>From:</b> 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>>
<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) <<a
href="mailto:dzacharo@harica.gr" target="_blank"
moz-do-not-send="true"
class="moz-txt-link-freetext">dzacharo@harica.gr</a>>;
CA/B Forum Server Certificate WG Public Discussion
List <<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>Subject:</b> [EXTERNAL] Re: [Servercert-wg] SC-59
Weak Key Guidance</p>
</div>
<p class="MsoNormal"> </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.</p>
<div class="MsoNormal" style="text-align:center"
align="center">
<hr width="100%" size="2" align="center">
</div>
<div>
<p style="margin:0in"><span
style="font-family:Arial,sans-serif;color:black">[back
to discussing the ballot]
</span></p>
<p style="margin:0in"> </p>
<p style="margin:0in"><span
style="font-family:Arial,sans-serif;color:black">Hi
all,</span></p>
<p class="MsoNormal"> </p>
<p style="margin:0in"><span
style="font-family:Arial,sans-serif;color:rgb(14,16,26)">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" moz-do-not-send="true"><span
style="font-family:Arial,sans-serif;color:rgb(74,110,224)">January
19th</span></a><span
style="font-family:Arial,sans-serif;color:rgb(14,16,26)">
SCWG meeting, but I recognize only some group
members can participate in our regularly scheduled
meetings.</span></p>
<p class="MsoNormal"> </p>
<p style="margin:0in"><span
style="font-family:Arial,sans-serif;color:rgb(14,16,26)">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>
<p class="MsoNormal"> </p>
<p style="margin:0in"><span
style="font-family:Arial,sans-serif;color:rgb(14,16,26)">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" moz-do-not-send="true"><span
style="font-family:Arial,sans-serif;color:rgb(74,110,224)">SSL.com</span></a><span
style="font-family:Arial,sans-serif;color:rgb(14,16,26)"> team, I
struggle with the demonstrated security value of
these checks compared to the overall effort they
represent. </span></p>
<p class="MsoNormal"> </p>
<p style="margin:0in"><span
style="font-family:Arial,sans-serif;color:rgb(14,16,26)">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>
<p class="MsoNormal"> </p>
<p style="margin:0in"><span
style="font-family:Arial,sans-serif;color:rgb(14,16,26)">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>
<p class="MsoNormal"> </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></p>
<p class="MsoNormal"> </p>
<p style="margin:0in"><span
style="font-family:Arial,sans-serif;color:black">-
Ryan</span></p>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal"> </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" moz-do-not-send="true"
class="moz-txt-link-freetext">servercert-wg@cabforum.org</a>>
wrote:</p>
</div>
<blockquote
style="border-top:none;border-right:none;border-bottom:none;border-left:1pt
solid rgb(204,204,204);padding:0in 0in 0in
6pt;margin-left:4.8pt;margin-right:0in">
<div>
<p class="MsoNormal" style="margin-bottom:12pt">Hi
Clint,</p>
<div>
<p class="MsoNormal">On 26/5/2023 6:45 μ.μ.,
Clint Wilson wrote:</p>
</div>
<blockquote
style="margin-top:5pt;margin-bottom:5pt">
<p class="MsoNormal">Hi Tom, Dimitris, </p>
<div>
<p class="MsoNormal"> </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.</p>
</div>
<div>
<div>
<p class="MsoNormal"> </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. </p>
</div>
<div>
<p class="MsoNormal"> </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.</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>
</p>
<blockquote
style="margin-top:5pt;margin-bottom:5pt">
<div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Thanks,</p>
</div>
<div>
<p class="MsoNormal">-Clint</p>
</div>
<div>
<p class="MsoNormal"><br>
<br>
</p>
<blockquote
style="margin-top:5pt;margin-bottom:5pt">
<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"
moz-do-not-send="true">
<servercert-wg@cabforum.org></a>
wrote:</p>
</div>
<p class="MsoNormal"> </p>
<div>
<div>
<div>
<p class="MsoNormal">Hello Dimitris,</p>
</div>
<div>
<p class="MsoNormal"> </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. </p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Thank you,</p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal">Tom</p>
</div>
<div>
<p class="MsoNormal"><a
href="https://urldefense.com/v3/__http:/ssl.com/__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmQZfKH8A$"
target="_blank"
moz-do-not-send="true">SSL.com</a></p>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<div style="border-right:none
currentcolor;border-bottom:none
currentcolor;border-left:none
currentcolor;border-top:1pt solid
currentcolor;padding:3pt 0in 0in">
<div>
<p class="MsoNormal"><b>From:</b> 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>> <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"
moz-do-not-send="true"
class="moz-txt-link-freetext">servercert-wg@cabforum.org</a><br>
<b>Subject:</b> Re:
[Servercert-wg] SC-59 Weak Key
Guidance</p>
</div>
</div>
</div>
<div>
<p class="MsoNormal"> </p>
</div>
<p class="MsoNormal"
style="margin-bottom:12pt"><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"
moz-do-not-send="true">more
favorable</a> than others. <br>
<br>
<br>
Thanks,<br>
Dimitris.</p>
<div>
<div>
<p class="MsoNormal">On 25/5/2023
10:51 μ.μ., Tom Zermeno via
Servercert-wg wrote:</p>
</div>
</div>
<blockquote
style="margin-top:5pt;margin-bottom:5pt">
<p style="vertical-align:baseline">Purpose
of Ballot SC-059 V3 </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. </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. </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"
moz-do-not-send="true">SSL.com</a> and
endorsed by Ben Wilson of Mozilla
and Martijn Katerbarg of Sectigo. </p>
<p style="vertical-align:baseline">--Motion
Begins— </p>
<p style="vertical-align:baseline"><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. <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></p>
<p style="vertical-align:baseline"> </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"
moz-do-not-send="true">https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3...SSLcom:servercert:3b0c6de32595d02fbd96762cda98cdc88addef00</a> </p>
<p style="vertical-align:baseline"> </p>
<p style="vertical-align:baseline">--Motion
Ends— </p>
<p style="vertical-align:baseline">This
ballot proposes a Final
Maintenance Guideline. The
procedure for approval of this
ballot is as follows: </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 </p>
<div>
<p class="MsoNormal"> </p>
</div>
<div>
<p class="MsoNormal"
style="margin-bottom:12pt"> </p>
</div>
<pre>_______________________________________________</pre>
<pre>Servercert-wg mailing list</pre>
<pre><a href="mailto:Servercert-wg@cabforum.org" target="_blank" moz-do-not-send="true" class="moz-txt-link-freetext">Servercert-wg@cabforum.org</a></pre>
<pre><a href="https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmdDgTqEQ$" target="_blank" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a></pre>
</blockquote>
<div>
<p class="MsoNormal"> </p>
</div>
</div>
<p class="MsoNormal"><span
style="font-size:9pt;font-family:Helvetica,sans-serif">_______________________________________________<br>
Servercert-wg mailing list<br>
</span><a
href="mailto:Servercert-wg@cabforum.org"
target="_blank"
moz-do-not-send="true"><span
style="font-size:9pt;font-family:Helvetica,sans-serif">Servercert-wg@cabforum.org</span></a><span
style="font-size:9pt;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"
moz-do-not-send="true"><span
style="font-size:9pt;font-family:Helvetica,sans-serif">https://lists.cabforum.org/mailman/listinfo/servercert-wg</span></a></p>
</div>
</blockquote>
</div>
<p class="MsoNormal"> </p>
</div>
</blockquote>
<p class="MsoNormal"> </p>
</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://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmdDgTqEQ$"
target="_blank" moz-do-not-send="true">https://lists.cabforum.org/mailman/listinfo/servercert-wg</a></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>
</div>
</div>
</blockquote>
</div>
</blockquote>
<br>
</body>
</html>