[Servercert-wg] [EXTERNAL] Re: Voting Begins for Ballot SC46: Sunset the CAA exception for DNS Operator
sleevi at google.com
Wed May 26 19:49:19 UTC 2021
An excellent question, and an unfortunate situation with respect to me
being out of office and missing the start of the voting period.
The short answer is "no", because the BRs don't apply retroactively to past
events, only to new events. This was similar to the discussion had about
validation methods and reuse of data.
Basically, the effect of an effective date in the past is that it behaves
"as if" it's not effective until the BRs are adopted, and on a go-forward
basis. For something like the CAA exception, what this means is that if a
certificate was issued on 2021-07-01, and this ballot wasn't effective
until 2021-07-02, that certificate would have complied with the
then-current version of the BRs, and not have been misissued. That's
because, at least with respect to this ballot, it's touching on an event
that happens "in the present"; it can certainly get messier with other
Equally, this also means that if you issued a pre-certificate on
2021-07-01, and relied on the CAA exception because DNS operator, and then
issued the actual certificate on 2021-07-03, you'd also be fine: because
the certificate issued on 2021-07-03 was relying on the pre-certificate
exception, not the DNS operator exception, when it was issued, and thus
complies with the effective version of the BRs on the date the certificate
The alternative would be to remove the "Effective 2021-07-01" language, and
restart the discussion period. The net effect would be that it'd shift the
effective date out a week. Sorry, I should have highlighted this rationale
for why I didn't, because it's understandable to bring it up. However,
because we've consistently said "The version of the BRs that apply are the
version of the BRs when the certificate is issued", it wouldn't be
That said, this is also why the discussion in validation WG is trying to
find ways to make sure that "When the certificate is issued" is accurately
reflected in the certificate's notBefore, since otherwise, complexity
arises for relying parties and CAs.
If you feel strongly, though, I can explore restarting the ballot. It was
entirely my fault for not setting up a scheduled send. There was some brief
discussion of this problem two calls ago, during the ballot update, to draw
attention to the possibility.
On Wed, May 26, 2021 at 3:02 PM Bruce Morton <Bruce.Morton at entrust.com>
> Quick question about the voting period. Is there an issue if the ballot is
> effective prior to the IPR period concluding?
> Thanks, Bruce.
> *From:* Servercert-wg <servercert-wg-bounces at cabforum.org> *On Behalf Of *Ryan
> Sleevi via Servercert-wg
> *Sent:* Wednesday, May 26, 2021 2:30 PM
> *To:* Ryan Sleevi <sleevi at google.com>; CA/B Forum Server Certificate WG
> Public Discussion List <servercert-wg at cabforum.org>
> *Subject:* [EXTERNAL] Re: [Servercert-wg] Voting Begins for Ballot SC46:
> Sunset the CAA exception for DNS Operator
> WARNING: This email originated outside of Entrust.
> DO NOT CLICK links or attachments unless you trust the sender and know the
> content is safe.
> Unfortunately, I realized belatedly that I forgot to clearly indicate the
> Voting End Time.
> 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?
> Please find the corrected announcement below:
> This email begins the voting period for Ballot SC46: Sunset the CAA
> exception for DNS operator
> Purpose of Ballot:
> This Ballot addresses security issues with Section 188.8.131.52 regarding CAA
> Currently, Section 184.108.40.206 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
> 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.
> 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.
> 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
> It can be viewed on GitHub as
> -- MOTION BEGINS --
> This ballot modifies the “Baseline Requirements for the Issuance and
> Management of Publicly-Trusted Certificates” (“Baseline Requirements”),
> based on Version 1.7.4:
> MODIFY the Baseline Requirements as specified in the following Redline:
> -- MOTION ENDS --
> This ballot proposes a Final Maintenance Guideline.
> The procedure for approval of this ballot is as follows:
> Discussion (7+ days)
> Start Time: 2021-05-13 20:00:00 UTC
> End Time: 2021-05-26 14:00:00 UTC
> Vote for approval (7 days)
> Start Time: 2021-05-26 18:30:00 UTC
> End Time: 2021-06-02 18:30:00 UTC
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Servercert-wg