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

Kirk Hall Kirk.Hall at entrustdatacard.com
Wed Sep 27 04:40:37 UTC 2017


Just to clarify, Ryan – the “standards” (here, RFC 6844 and the following Errata) have nothing to do with the Forum, and are set by the IETF.  As you know, many RFCs are adopted, but then never applied by the community.

Here, the problem is that the Forum chose to apply the first version of the IETF’s RFC 6844 to the activities of its CA members, and made it mandatory on CAs as of September 8, 2017 via Ballot 187 last March, now encoded (by us) in our own BR 3.2.2.8.

Sadly, RFC 6844 was deeply flawed, which we only discovered this month.  It would be very strange if the Forum now lacked the power to modify its own previous ballot that made CAA checking mandatory (using what we now realize was a flawed RFC) to a different, corrected mandate that is applied retroactively to the date of the mandate.

The Forum is not trying to modify the RFC 6844 “standard” – the standard sits on its own at the IETF.  Instead, the Forum is considering common sense changes to the rules the Forum itself adopted to make RFC 6844  mandatory on CAs, in order that CAA record checking will actually work and CAs won’t fail their WebTrust audits for no good reason.

Certainly we have the power to do this, and it has nothing to do with IETF or standards setting bodies – it is related instead to the Forum’s original choice of best practices for itself from all the possible standards out there, in a way that can then be checked by WebTrust and ETSI auditors.  We created this requirement for ourselves, so we certainly can modify it now.

From: Ryan Sleevi [mailto:sleevi at google.com]
Sent: Tuesday, September 26, 2017 5:43 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



On Wed, Sep 27, 2017 at 1:01 AM, Kirk Hall <Kirk.Hall at entrustdatacard.com<mailto:Kirk.Hall at entrustdatacard.com>> wrote:
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.

Hi Kirk,

This wasn't forgotten - rather, it's not accurate :)


WebTrust/ETSI take what we say as Holy Writ and then audit us to it.

Not quite. WebTrust and ETSI both audit members to Principles and Criteria derived from the Baseline Requirements, using their professional judgement to render an opinion on the matter as well as determining whether issues of non-conformance are material to the findings. As you know from your participation in the WebTrust Task Force discussions as Chair of the Forum, and as a CA, you are fully aware that WebTrust and ETSI do not comprehensively examine every individual aspect of the Baseline Requirements, but rather require CAs to demonstrate controls reflective of the principles and criteria.

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.

This is also not correct, and has been repeatedly discussed in the Forum. Please let me know if you'd like me to dig up the minuted discussions of this.

The findings of the Forum serve as secondary input, along with the primary input of the AICPA, with respect to the materiality of non-compliance to the principles and criteria of trust service providers. In this respect, the Forum serves much like browsers do, in providing input with respect to industry consensus and 'best practices'

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.

Luckily, the numerous factual inaccuracies in this render this argument moot. I do hope you can follow up with Jeff, Don, and the rest of AICPA in discussing your understanding of both the role and relationship of the Forum. As has been discussed over the past two years - and in particular, as browsers seek to better understand and appreciate the limits of audits and the ability of CAs to have non-compliance while not having it as a material finding, there is a degree of separation and independence from the Forum that establishes both WebTrust and ETSI as independent assessment criteria, informed by the discussions and decisions here, but neither bound to them nor driven by them.


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 is correct. And it will always be so.

That’s why it would be appropriate to include retroactivity clauses in remedial ballots, as I have suggested.

As explained above, this is operating on a significant misunderstanding of the role and relationship of the Forum, and as such, your suggestion is not only unnecessary, but actively detrimental to the relevance and respect of the Forum. It is important to consistently and immediately highlight these inaccuracies, lest the constant repetition of the suggestion lead it to being adopted through exhaustion.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170927/caa00b6c/attachment-0003.html>


More information about the Public mailing list