[Servercert-wg] [EXTERNAL] Re: SC-59 Weak Key Guidance

Thu Jun 1 14:31:09 UTC 2023

Hi Bruce,

Sorry for not being clear.

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"?)

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.

Thanks,
Ryan

On Thu, Jun 1, 2023 at 10:09 AM Bruce Morton <Bruce.Morton at entrust.com>
wrote:

> Hi Ryan,
>
>
>
> 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?
>
>
>
>
>
> Thanks, Bruce.
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Ryan
> Dickson via Servercert-wg
> *Sent:* Thursday, June 1, 2023 9:44 AM
> *To:* Dimitris Zacharopoulos (HARICA) <dzacharo at harica.gr>; CA/B Forum
> Server Certificate WG Public Discussion List <servercert-wg at cabforum.org>
> *Subject:* [EXTERNAL] Re: [Servercert-wg] SC-59 Weak Key Guidance
>
>
>
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
> ------------------------------
>
> [back to discussing the ballot]
>
>
>
> Hi all,
>
>
>
> I raised the following question during the January 19th
> <https://urldefense.com/v3/__https:/cabforum.org/2023/01/19/2023-01-19-minutes-of-the-server-certificate-working-group/__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEn9o8sx8A$>
> SCWG meeting, but I recognize only some group members can participate in
> our regularly scheduled meetings.
>
>
>
> Do participants in this Forum feel that weak-key checks should be removed
> from the scope of a CA’s set of mandatory responsibilities?
>
>
>
> While I appreciate the work carried out by ecosystem members to produce
> this ballot, primarily led by the SSL.com
> <https://urldefense.com/v3/__http:/ssl.com__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIElUnEh06Q$>
> team, I struggle with the demonstrated security value of these checks
> compared to the overall effort they represent.
>
>
>
> 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?
>
>
>
> 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).
>
>
>
> 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.
>
>
>
> - Ryan
>
>
>
>
>
> On Mon, May 29, 2023 at 1:18 AM Dimitris Zacharopoulos (HARICA) via
> Servercert-wg <servercert-wg at cabforum.org> wrote:
>
> Hi Clint,
>
> On 26/5/2023 6:45 μ.μ., Clint Wilson wrote:
>
> Hi Tom, Dimitris,
>
>
>
> 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.
>
>
>
> If there’s a particular penchant towards March and September, however,
> then I’d be unopposed to March, May, July, September, and November 15th.
>
>
>
> 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 *more than 3 years*) 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.
>
>
> 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.
>
> 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.
>
> 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.
>
> 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.
>
>
> Thanks,
> Dimitris.
>
>
>
>
> Thanks,
>
> -Clint
>
>
>
> On May 26, 2023, at 7:37 AM, Tom Zermeno via Servercert-wg
> <servercert-wg at cabforum.org> <servercert-wg at cabforum.org> wrote:
>
>
>
> Hello Dimitris,
>
>
>
> Thank you for the input.  We feel that September 15th does not provide
> enough time for CAs to implement these changes, but we are not against the
> March 15,  2024 effective date, if there is consensus from the Community.
>
>
>
> Thank you,
>
>
>
> Tom
>
> SSL.com
> <https://urldefense.com/v3/__http:/ssl.com/__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmQZfKH8A$>
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Dimitris
> Zacharopoulos (HARICA) via Servercert-wg
> *Sent:* Friday, May 26, 2023 1:54 AM
> *To:* servercert-wg at cabforum.org
> *Subject:* Re: [Servercert-wg] SC-59 Weak Key Guidance
>
>
>
>
> Hi Tom,
>
> 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 more favorable
> <https://urldefense.com/v3/__https:/docs.google.com/presentation/d/1oTGVYqggQpQMR4Lktbu_L6DhuBVJzeuiFGd9EAU1zsE__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmlvDMTQg$> than
> others.
>
>
> Thanks,
> Dimitris.
>
> On 25/5/2023 10:51 μ.μ., Tom Zermeno via Servercert-wg wrote:
>
> Purpose of Ballot SC-059 V3
>
> 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.
>
> 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.
>
> The following motion has been proposed by Thomas Zermeno of SSL.com
> <https://urldefense.com/v3/__http:/ssl.com/__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmQZfKH8A$> and
> endorsed by Ben Wilson of Mozilla and Martijn Katerbarg of Sectigo.
>
> --Motion Begins—
>
> 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.
>
> 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).
>
>
>
> MODIFY the Baseline Requirements as specified in the following Redline:
> https://github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3...SSLcom:servercert:3b0c6de32595d02fbd96762cda98cdc88addef00
> <https://urldefense.com/v3/__https:/github.com/cabforum/servercert/compare/a0360b61e73476959220dc328e3b68d0224fa0b3...SSLcom:servercert:3b0c6de32595d02fbd96762cda98cdc88addef00__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEkXOeodFw$>
>
>
>
>
> --Motion Ends—
>
> This ballot proposes a Final Maintenance Guideline. The procedure for
> approval of this ballot is as follows:
>
> Discussion (11+ days) • Start time: 2023-05-25 19:00:00 UTC • End time:
> 2023-06-08 18:59:00 UTC
> Vote for approval (7 days) • Start time: TBD • End time: TBD
>
>
>
>
>
> _______________________________________________
>
> Servercert-wg mailing list
>
> Servercert-wg at cabforum.org
>
> https://lists.cabforum.org/mailman/listinfo/servercert-wg <https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmdDgTqEQ$>
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
> <https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmdDgTqEQ$>
>
>
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
> <https://urldefense.com/v3/__https:/lists.cabforum.org/mailman/listinfo/servercert-wg__;!!FJ-Y8qCqXTj2!ZiS9e88ZglROzMqbZ57HX5kGTEoEo89sE6TPRs6_RvRCnQOeD9zdbxklqxVQD2dlDqEbV24CVdHmWw9BkoRWIEmdDgTqEQ$>
>
> *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. Please notify
> Entrust immediately and delete the message from your system.*
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20230601/e58fc65a/attachment-0001.html>