<div dir="ltr"><div>Reminder: Voting on this ballots ends Wednesday June 2nd at 18:30 UTC.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 26, 2021 at 11:30 AM Ryan Sleevi via Servercert-wg <<a href="mailto:servercert-wg@cabforum.org">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 dir="ltr">Unfortunately, I realized belatedly that I forgot to clearly indicate the Voting End Time.<div><br></div><div>As such, the previous mail did not officially start voting. Thankfully, as no votes were received, I think we can just say I didn't start it correctly?</div><div><br></div><div>Please find the corrected announcement below:</div><div><br></div><div>This email begins the voting period for Ballot SC46: Sunset the CAA exception for DNS operator<br><br>Purpose of Ballot:<br><br>This Ballot addresses security issues with Section 3.2.2.8 regarding CAA checking.<br><br>Currently, Section 3.2.2.8 permits a CA to bypass CAA checking if the CA or an Affiliate of the CA is the DNS Operator. This term is referred to through RFC 7719, and involves a precise technical definition regarding how a zone's authoritative servers are configured and expressed (e.g. NS records). While this allows a CA to skip looking up the CAA record, it does not absolve them of the need to look up these other records on every issuance.<br><br>As practiced by CAs, this has clearly caused some confusion. For example, some CAs have incorrectly implemented policies that determine they're authoritative based on self-assertion that they are authoritative, which is not consistent with the current requirements.<br><br>To avoid these issues, this sunsets the CAA exception on 2021-07-01 for the DNS Operator, simplifying the requirements and reducing ambiguities for CAs performing validation.<br><br>The following motion has been proposed by Ryan Sleevi of Google and endorsed by Ben Wilson of Mozilla and Jacob Hoffman-Andrews of ISRG/Let's Encrypt.<br><br>It can be viewed on GitHub as <a href="https://github.com/cabforum/servercert/pull/271" target="_blank">https://github.com/cabforum/servercert/pull/271</a><br><br>-- MOTION BEGINS --<br><br>This ballot modifies the “Baseline Requirements for the Issuance and Management of Publicly-Trusted Certificates” (“Baseline Requirements”), based on Version 1.7.4:<br><br>MODIFY the Baseline Requirements as specified in the following Redline:<br><br><a href="https://github.com/cabforum/servercert/compare/47248d77d371356780b08cfa971b26d88d704ca8..6d34b1d51f645912d2237d5d4b46f4a49e8352ed" target="_blank">https://github.com/cabforum/servercert/compare/47248d77d371356780b08cfa971b26d88d704ca8..6d34b1d51f645912d2237d5d4b46f4a49e8352ed</a><br><br>-- MOTION ENDS --<br><br>This ballot proposes a Final Maintenance Guideline.<br><br>The procedure for approval of this ballot is as follows:<br><br>Discussion (7+ days)<br><br>Start Time: 2021-05-13 20:00:00 UTC<br>End Time: 2021-05-26 14:00:00 UTC<br><br>Vote for approval (7 days)<br><br>Start Time: 2021-05-26 18:30:00 UTC<br>End Time: 2021-06-02 18:30:00 UTC<br></div></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></div>