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

[Kirk Hall]

You are forgetting one important factor – the immediate translation of BRs enacted by Forum members into WebTrust/ETSI audit requirements (including Effective Dates) that are then applied to Forum members automatically.

WebTrust/ETSI take what we say as Holy Writ and then audit us to it.  For this reason, only the Forum (which passes the BRs) can correct a bad ballot and “instruct” the WebTrust guys on what is, and what is not, non-compliance leading to an audit qualification.  Even if the WebTrust team is sympathetic to their CA clients and understand the problem, they generally don’t have discretion to ignore violations of the BRs.  No one else can fix the problem of a bad ballot for us – not the browsers, not the auditors themselves.  And most of us don’t want a qualified audit just because of an error in the drafting of a ballot that passes.

In this way, the Forum is different from ISO and other standards bodies, as I don’t think ISO standards go directly to an audit organization for immediate application to ISO members.

We appreciate Google granting permission in this case to violate the BRs, but that won’t have any impact on what the auditors do in interpreting and auditing us to the BRs as amended by Ballot 214.  That’s why it would be appropriate to include retroactivity clauses in remedial ballots, as I have suggested.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Monday, September 25, 2017 10:51 PM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org>
Subject: Re: [EXTERNAL]Re: [cabfpub] Voting has started on Ballot 214 - CAA Discovery CNAME Errata

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<mailto: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<mailto:sleevi at google.com>]
Sent: Monday, September 25, 2017 9:53 PM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>>
Cc: CA/Browser Forum Public Discussion List <public at cabforum.org<mailto:public at cabforum.org>>; Tim Hollebeek <THollebeek at trustwave.com<mailto:THollebeek at trustwave.com>>; Jacob Hoffman-Andrews <jsha at letsencrypt.org<mailto:jsha at letsencrypt.org>>; Doug Beattie <doug.beattie at globalsign.com<mailto: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<mailto: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<mailto:sleevi at google.com>]
Sent: Monday, September 25, 2017 6:22 PM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>>; CA/Browser Forum Public Discussion List <public at cabforum.org<mailto:public at cabforum.org>>
Cc: Tim Hollebeek <THollebeek at trustwave.com<mailto:THollebeek at trustwave.com>>; Jacob Hoffman-Andrews <jsha at letsencrypt.org<mailto:jsha at letsencrypt.org>>; Doug Beattie <doug.beattie at globalsign.com<mailto: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<mailto: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<mailto:public at cabforum.org>>
To: "CA/Browser Forum Public Discussion List" <public at cabforum.org<mailto: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/d6d7c295/attachment-0003.html>