[Servercert-wg] Compromised/Weak Keys Ballot Proposal

Sat Feb 24 17:31:18 UTC 2024

>
> I think it's safest to err on the side of caution and use the explicit
> wording that you proposed.

I've made that clarification in the PR at
https://github.com/wthayer/servercert/pull/1/files

I'm still seeking a second endorser.

Thanks,

Wayne

On Fri, Feb 23, 2024 at 2:25 PM Tom Zermeno <tom at ssl.com> wrote:

> Wayne,
>
>
>
> I think it's safest to err on the side of caution and use the explicit
> wording that you proposed.
>
>
>
> Thanks,
>
>
>
> Tom
>
>
>
> *From:* Wayne Thayer <wthayer at gmail.com>
> *Sent:* Friday, February 23, 2024 2:45 PM
> *To:* Tom Zermeno <tom at ssl.com>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>; Martijn Katerbarg <
> martijn.katerbarg at sectigo.com>
> *Subject:* Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
>
>
> You don't often get email from wthayer at gmail.com. Learn why this is
> important <https://aka.ms/LearnAboutSenderIdentification>
>
> Tom,
>
>
>
> I had originally placed the Debian exception in the sublist of 6.1.1.3(5),
> but Aaron Gable correctly pointed out that it doesn't make sense there
> because that sublist is prefaced with the statement "the following
> precautions SHALL be implemented:" I think it would be logically difficult
> to interpret the exception as belonging with 6.1.1.3(5)(ii) Close Primes,
> but I do agree that it could be clearer. To that end, I've change the
> indentation of the exception sentence in
> https://github.com/wthayer/servercert/pull/1/files Does that help? I
> could also change the wording to "Debian weak keys (
> https://wiki.debian.org/SSLkeys) are exempt from the requirements of
> Section 6.1.1.3(5).
>
>
>
> Thanks,
>
>
>
> Wayne
>
>
>
> On Fri, Feb 23, 2024 at 10:33 AM Tom Zermeno <tom at ssl.com> wrote:
>
> Wayne,
>
> Regarding the change of the Debian weak keys statement at proposed line
> 1701: is the statement intended to be a sub-clause of the second item in
> the sublist, which would then make Debian weak keys exempt from the Fermat
> factorization method check?  Or, more likely based on the recent
> discussion, was the statement meant to be a third item in the list, which
> would then exempt Debian weak keys from the 5th condition of the list
> requiring CAs to reject certificate requests?
>
>
>
> My question stems from the abnormal line spacing and indention of the
> statement, which stands out from the surrounding text.
>
>
>
> Thanks,
>
>
>
> Tom
>
>
>
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Wayne
> Thayer via Servercert-wg
> *Sent:* Friday, February 23, 2024 11:18 AM
> *To:* Martijn Katerbarg <martijn.katerbarg at sectigo.com>
> *Cc:* CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>
> *Subject:* Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
>
>
> Martijn,
>
>
>
> I would summarize the reasoning for removing the Debian requirements as
> follows:
>
> - CAs would prefer the greater clarity that would be provided by the weak
> keys ballot that failed last year.
>
> - However, some CAs were of the opinion that the prior ballot imposed more
> explicit requirements for Debian weak key checking rather than just
> clarifying existing requirements. The "new" requirements were viewed as
> burdensome.
>
> - The Debian vulnerability is more than 15 years old. If an Applicant
> submits a Debian weak key at this point, they almost certainly have bigger
> security issues.
>
> - So the cost of these requirements outweighs the benefits at this point
> in time.
>
>
>
> I included a few links to the discussion during the prior balot's voting
> period, and there was also discussion at the last SCWG teleconference that
> should be captured in the minutes.
>
>
>
> Thanks,
>
>
>
> Wayne
>
>
>
> On Fri, Feb 23, 2024 at 2:19 AM Martijn Katerbarg <
> martijn.katerbarg at sectigo.com> wrote:
>
> Wayne,
>
> Apologies if I’ve missed something in discussions, but why exactly are we
> removing the Debian Weak Keys language, and even explicitly mentioned that
> CAs do not need to check for them (anymore)?
>
>
> Regards,
>
> Martijn
>
>
>
> *From: *Servercert-wg <servercert-wg-bounces at cabforum.org> on behalf of
> Wayne Thayer via Servercert-wg <servercert-wg at cabforum.org>
> *Date: *Thursday, 22 February 2024 at 20:01
> *To: *CA/B Forum Server Certificate WG Public Discussion List <
> servercert-wg at cabforum.org>
> *Subject: *Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal
>
> 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.
>
>
>
> I am seeking a second endorser for this proposal. Below is a draft of the
> ballot language.
>
>
>
> Thanks,
>
>
>
> Wayne
>
> ================================
>
> **Ballot SC-XX: Compromised / Weak Keys**
>
> This ballot updates BR section 6.1.1.3 to address two issues:
>
> First, the requirements placed on CAs to reject a certificate request if
> they have been “made aware” that the key pair is compromised is vague and
> open-ended in regard to how CAs may be “made aware”. This ballot specifies
> that CAs be “made aware” via their problem reporting mechanism.
>
> Second, this ballot reintroduces the language from [failed] ballot SC-59:
> Weak Key Guidance. However, based on feedback received during the
> discussion and voting period for that ballot, Debian weak key checks are
> now explicitly out of scope.
>
> This ballot is proposed by Wayne Thayer (Fastly) and endorsed by Brittany
> Randall (GoDaddy) and <someone else( )>. You can view and comment on the
> github pull request representing this ballot here:
> https://github.com/wthayer/servercert/pull/1/files
>
> The preceding discussions can be seen here:
>
> * This ballot:
> https://lists.cabforum.org/pipermail/servercert-wg/2024-February/004195.html
> * The prior weak keys ballot:
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html
> and
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html
> * The “made aware” language in 6.1.1.3:
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html
>
>
> --- Motion Begins ---
>
> This ballot modifies the "Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates" ("Baseline Requirements")
> based on Version 2.X.X
>
> MODIFY the Baseline Requirements as specified in the following redline:
> <Immutable redline link>
>
> --- Motion Ends ---
>
> Discussion (at least 7 days):
>
> - Start: TBD UTC
> - End: TBD UTC
>
> Vote for approval (7 days):
>
> - Start: TBD UTC
> - End: TBD UTC
>
>
>
> On Mon, Feb 12, 2024 at 6:12 PM Wayne Thayer via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> Thank you fo the feedback Aaron. I agree with both points you made in the
> PR and have updated it to reflect your suggestions.
>
>
>
> - Wayne
>
>
>
> On Mon, Feb 12, 2024 at 12:27 PM Aaron Gable <aaron at letsencrypt.org>
> wrote:
>
> Thank you Wayne! I think this gets close to the sweet spot for me,
> personally. I've left two small comments on the ballot, but on the whole I
> think I like this approach.
>
>
>
> Thanks again,
>
> Aaron
>
>
>
> On Mon, Feb 12, 2024 at 8:18 AM Wayne Thayer via Servercert-wg <
> servercert-wg at cabforum.org> wrote:
>
> Following up from the last SCWG teleconference, I've reviewed the feedback
> from the discussion [1] and voting [2] periods for ballot SC-59 Weak Key
> Guidance, along with the prior discussions on the "made aware" language in
> section 6.1.1.3 [3] and I would like to propose the following Baseline
> Requirements improvements:
>
>
>
> * Scope the 6.1.1.3 "made aware" language to "made aware via the CA's
> documented problem reporting mechanism". This addresses the concern that I
> raised by limiting how a CA can be "made aware". [4]
>
>
>
> * Remove the Debian requirements from the prior weak keys ballot and
> replace them with language that excludes Debian weak keys. Otherwise use
> the language from the prior ballot, with the exception of a new effective
> date. This consolidates feedback that CAs do desire the clarity that would
> have been provided by the prior ballot, but many believe that the burden
> for rejecting Debian weak keys exceeds the value of doing so at this point
> in time.
>
>
>
> Here's the result: https://github.com/wthayer/servercert/pull/1/files
>
>
>
> Note that, while there has been discussion about completely removing weak
> key checking requirements, there does not appear to be a consensus to do so.
>
>
>
> I would appreciate everyone's feedback on the proposal, and I am also
> seeking endorsers.
>
>
>
> Thanks,
>
>
>
> Wayne
>
>
>
> [1]
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html
>
> [2]
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html
>
> [3]
> https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html
>
> [4] https://github.com/cabforum/servercert/issues/442
>
>
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
> _______________________________________________
> Servercert-wg mailing list
> Servercert-wg at cabforum.org
> https://lists.cabforum.org/mailman/listinfo/servercert-wg
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/servercert-wg/attachments/20240224/ad7e8f1f/attachment-0001.html>