<div dir="ltr"><div>Thank you fo the feedback Aaron. I agree with both points you made in the PR and have updated it to reflect your suggestions.</div><div><br></div><div>- Wayne<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 12, 2024 at 12:27 PM Aaron Gable <<a href="mailto:aaron@letsencrypt.org">aaron@letsencrypt.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 dir="ltr">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.<div><br></div><div>Thanks again,</div><div>Aaron</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Feb 12, 2024 at 8:18 AM Wayne Thayer 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 dir="ltr"><div>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:</div><div><br></div><div>* 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]</div><div><br></div><div>* 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.<br></div><div><br></div><div>Here's the result: <a href="https://github.com/wthayer/servercert/pull/1/files" target="_blank">https://github.com/wthayer/servercert/pull/1/files</a></div><div><br></div><div>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.<br></div><div><br></div><div>I would appreciate everyone's feedback on the proposal, and I am also seeking endorsers.</div><div><br></div><div>Thanks,</div><div><br></div><div>Wayne</div><div><br></div><div>[1] <a href="https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html" target="_blank">https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003820.html</a></div><div>[2] <a href="https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html" target="_blank">https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003857.html</a></div><div>[3] <a href="https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html" target="_blank">https://lists.cabforum.org/pipermail/servercert-wg/2023-July/003902.html</a></div><div>[4] <a href="https://github.com/cabforum/servercert/issues/442" target="_blank">https://github.com/cabforum/servercert/issues/442</a></div><div><br></div></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>
</blockquote></div>