[cabfpub] [EXTERNAL]Re: Voting has started on Ballot 214 - CAA Discovery CNAME Errata

Tue Sep 26 05:50:44 UTC 2017

Well, it is useful to note we're neither a legislative body nor a
regulatory body. Our Antitrust Statement is a fair reflection of that - the
Forum is merely a discussion venue for CAs to provide input to various Root
Stores on their technical requirements and proposed changes, and for Root
Stores to identify common requirements amongst their root programs that
might benefit from being harmonized within CA/Browser Forum documents as
used for inputs to audit criteria they find acceptable. The CA/Browser
Forum does not decide what is a valid CA or certificate, nor does it decide
what is an untrustworthy CA or certificate. Those decisions are left to
individual root stores, as to decided to who they will contract the
security of their product and their users to.

Much as we would not agree to disagree as to what the result of 2+2 is (4),
it is very important that we come to a harmonious understanding of the role
of the Forum, in order to ensure it remains a relevant and productive
venue. Were the Forum a legislative or regulatory body, as you compare it
to, it would be noteworthy that the Forum itself would have succumbed to
regulatory capture, and thus lose both relevance and respect within the
industry. Should the Forum move to a model of proposing, let alone
granting, indulgences for its members, at the exclusion of those who will
not accept the IP policy, this would be a seriously concerning and
problematic development.

Devon's message is an example of what I was highlighting to you, so I hope
it does not seem confusing. Independent of the Forum's position on CAA
Erratum 5065 (with respect specifically to Ballot 214), Google Chrome views
either form of validation to be an acceptable level of assurance. CAs that
validate using Erratum 5065 will be issuing certificates that are not
compliant with the Baseline Requirements, but such non-compliance will not
be seen as a matter for further investigation.

With respect to ETSI and WebTrust requirements, such CAs using Erratum 5065
will not be issuing certificates compliant with the current version of the
Baseline Requirements (as attested to and required by Section 2.2 of the
BRs within the CA's CP/CPS), but we view such non-compliant issuance as
acceptable.

On Tue, Sep 26, 2017 at 2:26 PM, Kirk Hall <Kirk.Hall at entrustdatacard.com>
wrote:

> Well, I don’t agree with your analysis – it’s not supported by law or
> practice outside the Forum – but it’s not worth arguing about any further.
> We can agree to disagree.
>
>
>
> How should we interpret Devon’s (very welcome) recent Google message about
> Ballot 214 – can CAs rely on it?  See attached.
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Monday, September 25, 2017 9:53 PM
> *To:* Kirk Hall <Kirk.Hall at entrustdatacard.com>
> *Cc:* CA/Browser Forum Public Discussion List <public at cabforum.org>; Tim
> Hollebeek <THollebeek at trustwave.com>; Jacob Hoffman-Andrews <
> jsha at letsencrypt.org>; Doug Beattie <doug.beattie at globalsign.com>
> *Subject:* Re: [EXTERNAL]Re: [cabfpub] Voting has started on Ballot 214 -
> CAA Discovery CNAME Errata
>
>
>
> Kirk,
>
>
>
> I think it again highlights a misunderstanding about the role and
> relevance of the Forum to suggest that the Forum can excuse anything, lest
> we also suggest that the Forum also enforces compliance on its members.
> Similarly, it highlights a misunderstanding about whether or not compliance
> is a binary state. I'm sure no CA would want to be in the unenviable
> position of finding them retroactively sanctioned for something expressly
> permitted in the BRs, on the basis that the Forum later decided it was
> non-compliant.
>
>
>
> That is, it would be unimaginable to suggest that the Forum could adopt a
> ballot that suggests that everything issued under 3.2.2.4 in the past year
> was misissuance. As such, it must also remain unimaginable to suggest that
> the Forum could adopt a ballot that suggests something prohibited under the
> past year was valid issuance. Merely, the Forum can decide what its
> documents state for the future. They cannot state what they want about the
> past, at least not without sacrificing the legitimacy and value of the
> Forum.
>
>
>
> This is why it's terribly unproductive to keep suggesting such ballots,
> and instead focus on allowing discussions about the future to inform how
> browsers - and auditors - evaluate the past.
>
>
>
> On Tue, Sep 26, 2017 at 1:35 PM, Kirk Hall <Kirk.Hall at entrustdatacard.com>
> wrote:
>
> Ryan, of course the browsers can make any rules they like – neither I nor
> anyone else has questioned that.
>
>
>
> But likewise, the CA/Browser Forum can make any rules it likes, and it
> (like any Legislature in the world) can adopt its rules in the manner I
> described below, including retroactively making changes to rules that have
> been adopted.  I can provide numerous examples if you like.
>
>
>
> So it could be that the Forum retroactively excuses brief non-compliance
> with a rule that was adopted by the Forum in error.  At that point, it’s up
> to browsers like Google and others to decide and announce whether they
> agree (through their root program) or not.  Both groups – the Forum and
> individual browsers – get to decide for themselves.
>
>
>
> *From:* Ryan Sleevi [mailto:sleevi at google.com]
> *Sent:* Monday, September 25, 2017 6:22 PM
> *To:* Kirk Hall <Kirk.Hall at entrustdatacard.com>; CA/Browser Forum Public
> Discussion List <public at cabforum.org>
> *Cc:* Tim Hollebeek <THollebeek at trustwave.com>; Jacob Hoffman-Andrews <
> jsha at letsencrypt.org>; Doug Beattie <doug.beattie at globalsign.com>
> *Subject:* [EXTERNAL]Re: [cabfpub] Voting has started on Ballot 214 - CAA
> Discovery CNAME Errata
>
>
>
>
>
>
>
> On Tue, Sep 26, 2017 at 5:39 AM, Kirk Hall via Public <public at cabforum.org>
> wrote:
>
>  So Ballot 214 would be in effect for about 12 days (Oct. 27 – Nov. 9).
> It’s possible a new ballot could say “It is not a violation of the BRs if
> CAs did not comply with Ballot 214 after its effective date but before the
> effective date of this ballot.”  We would know that provision had passed on
> about Oct. 10, but wouldn’t be effective until about Nov. 9 – but if worded
> correctly it would be retroactive to the effective date of Ballot 214.  I
> think auditors would take the position that CAs who ignored Ballot 214 for
> the 12 day period had not violated the BRs – we can check.
>
>
>
> As noted many, many times before, the suggestion of retroactive immunity
> is a decision for root stores - not the CA/Browser Forum. Compliance is
> binary, measured over time. You are either compliant or non-compliant. Our
> voting process establishes what compliance is - and redefining it changes
> it at a future point.
>
>
>
> Your suggestion of "not violating the BRs" is also not consistent. It
> would be a violation of the BRs - but the suggestion is that it can be
> informed through the CA/Browser Forum's consensus process whether that
> violation is material to the stated principles and criteria. That is very
> different than what you suggest, but a subtle and important distinction
> worth reiterating :)
>
>
>
>
>
>
> ---------- Forwarded message ----------
> From: "Devon O'Brien via Public" <public at cabforum.org>
> To: "CA/Browser Forum Public Discussion List" <public at cabforum.org>
> Cc:
> Bcc:
> Date: Tue, 26 Sep 2017 03:11:32 +0000
> Subject: [EXTERNAL][cabfpub] Google Chrome's stance on CAA algorithms
> Hello CA/B Forum,
>
> In advance of the conclusion of Ballot 214’s voting period, we’re writing
> to share with the CA community Google Chrome’s stance regarding permissible
> CAA algorithm usage.
>
> We consider the CAA checking algorithm specified in Erratum 5065 to be
> superior to the one specified in RFC 6844 and therefore are granting
> immediate dispensation for all CAs to issue certificates following the
> algorithm specified in either RFC 6844 or RFC 6844 as amended by Erratum
> 5065 when performing the mandatory pre-issuance CAA checks.
>
> It appears likely that there will be a follow-on Ballot to 214, specifying
> a transition timeline for CAs to move to Erratum 5065’s algorithm. If and
> when such a ballot passes, CAs will be required to transition to the
> updated algorithm in accordance with the updated Baseline Requirements
>
> Thanks,
> Devon O’Brien
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170926/b6958274/attachment-0003.html>