> > 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 <[email protected]> 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 <[email protected]> > *Sent:* Friday, February 23, 2024 2:45 PM > *To:* Tom Zermeno <[email protected]> > *Cc:* CA/B Forum Server Certificate WG Public Discussion List < > [email protected]>; Martijn Katerbarg < > [email protected]> > *Subject:* Re: [Servercert-wg] Compromised/Weak Keys Ballot Proposal > > > > You don't often get email from [email protected]. 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 <[email protected]> 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 <[email protected]> *On Behalf Of > *Wayne > Thayer via Servercert-wg > *Sent:* Friday, February 23, 2024 11:18 AM > *To:* Martijn Katerbarg <[email protected]> > *Cc:* CA/B Forum Server Certificate WG Public Discussion List < > [email protected]> > *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 < > [email protected]> 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 <[email protected]> on behalf of > Wayne Thayer via Servercert-wg <[email protected]> > *Date: *Thursday, 22 February 2024 at 20:01 > *To: *CA/B Forum Server Certificate WG Public Discussion List < > [email protected]> > *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 < > [email protected]> 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 <[email protected]> > 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 < > [email protected]> 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 > [email protected] > https://lists.cabforum.org/mailman/listinfo/servercert-wg > > _______________________________________________ > Servercert-wg mailing list > [email protected] > https://lists.cabforum.org/mailman/listinfo/servercert-wg > >
_______________________________________________ Servercert-wg mailing list [email protected] https://lists.cabforum.org/mailman/listinfo/servercert-wg
