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

Wed Sep 27 18:11:08 UTC 2017

Eric – root program decisions (such as excusing compliance with something) do not affect the auditors application of BR requirements through the BR WebTrust audit.

The auditors generally must follow what the BRs say, as incorporated in their audit standards.  (After all, we have only gotten permission to violate the BRs from three browsers, but there are other browsers and applications that require full BR compliance to remain in their root program.)

That is why the best way to avoid possible audit failure on this issue is to further amend the BRs to what we all want them to say, effective as of Sept. 8, 2017.

From: Eric Mill [mailto:eric at konklone.com]
Sent: Wednesday, September 27, 2017 10:12 AM
To: Kirk Hall <Kirk.Hall at entrustdatacard.com>; CA/Browser Forum Public Discussion List <public at cabforum.org>
Cc: Ryan Sleevi <sleevi at google.com>
Subject: Re: [cabfpub] [EXTERNAL]Re: Voting has started on Ballot 214 - CAA Discovery CNAME Errata

On Wed, Sep 27, 2017 at 11:49 AM, Kirk Hall via Public <public at cabforum.org<mailto:public at cabforum.org>> wrote:
Now you have me confused – Google (and later Microsoft and Apple) have published messages to CAs saying, in essence, “it’s ok for CAs not to comply with Ballot 187 and BR Version 1.4.3”, but you are saying it’s not ok for the Forum to do the same thing by a new ballot that applies back to the effective date stated in Ballot 187 (Sept. 8, 2017).

That makes absolutely no sense – the two situations should be treated the same, and in fact I would say the Forum has the greater ability to excuse non-compliance with BR 3.2.2.8 than the browsers do via a new ballot.

For what it's worth, this makes sense to me. The Forum sets the standards, root programs ask auditors to audit to those standards, the auditors opine on whether the standards were met, and then root programs evaluate any gaps or findings.

Many of the root programs already just indicated how they would evaluate those findings, so there should be no issue here. For the Forum to make things retroactively compliant would be doing what root programs are supposed to do. I'm not sure why it's so urgent to have the Forum to try to do something that ultimately, only the root programs can do.

Root programs could just ignore the results of such a ballot and penalize CAs at their discretion anyway. As folks here are fond of saying, the Forum doesn't bind browsers, only CAs, and a retroactive ballot would seem like it's going in that direction.

-- Eric

From: Ryan Sleevi [mailto:sleevi at google.com<mailto:sleevi at google.com>]
Sent: Tuesday, September 26, 2017 10:01 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>>
Subject: Re: [EXTERNAL]Re: [cabfpub] Voting has started on Ballot 214 - CAA Discovery CNAME Errata

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

Sure, but this is not relevant or germane to the discussion :) I'm afraid you've greatly misunderstood the concerns here, but I look forward to working with you so that we can end up on the same page and with a shared understanding of the problems with your suggestions.

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.

Specifically - and I think this is an important point that was previously mistated - it is not Ballot 187 that marks adoption, but rather, the publication of BRs 1.4.3 at the completion of the IP Review period. The completion of the Ballot does not represent a binding until the IPR has completed and a new version published.

This is perhaps more easily demonstrated by the fact that 1.5.0, 1.5.1, and 1.5.2 are all currently under the IP Review, which means that the 'in-force' version is 1.4.9

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.

No, it's not strange. I am telling you that is exactly how it works. Which is, incidentally, why I have repeatedly raised concerns with the problem of "we'll fix it subsequently" - that fails to address the meaningful concerns, and leaving ambiguous text in the BRs (with interpretations offered on the list) is actively hostile to non-participants and detrimental to the Forum's efforts of being a productive venue for discussion.

The Forum adopted something with good intentions, but with a flaw - and these things happen. We can - and should - correct the language in an unambiguous way to resolve this. However, because the Forum adopted the flawed ballot - we are absolutely bound by it. That means that CAs that issue such certificates are non-compliant with the BRs.

To the extent this results in a qualified audit is, of course, dependent upon individual auditors, and their evaluation of the CA's controls relative to the trust service principles and criteria. The Forum cannot declare something as immaterial, no more than the Forum declares a finding material - it provides input to the auditors as a secondary source relative to their professional and ethical obligations.

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.

Indeed, and we are fully supportive of those efforts going forward.

I am, however, highlighting that the Forum modifying the BRs does not provide the ability to redefine past non-compliance as compliance. I want to make sure this is clear and unambiguous, as unfortunately, despite repeated efforts spanning years of discussion, this is still a routine suggestion of yours.

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.

I'm afraid you've greatly misunderstood the concern, and look forward to working together to adopt a better understanding. I fear this misunderstanding has significantly detracted from the core objection, which I reiterate here:

1) The Forum cannot redefine non-compliance for the past. It can only speak to the future.
  - Any attempt to try to grant retroactive 'immunity' - to redefine past-non-compliance as compliance - is unacceptable, both as a matter of policy and to the legitimacy of the Forum.
  - If it is not immediately and completely obvious, then again, I reiterate the risk that the same logic applies to

2) While such decisions of the Forum can inform and support the work of WebTrust and ETSI, those documents are themselves independent of the Forum's Baseline Requirements. That is, they build upon the principles and criteria captured within the BRs into forms appropriate for auditing. That is, they are independent of the BRs - and the BRs are not their One True Source.

3) Qualified audits are not the end of the world. Auditors absolutely should be noting matters of non-compliance, and as to whether they determined said non-compliance to be non-material (and if so, the facts surrounding such determination and whether said facts are fairly stated by management)

These principles apply regardless of the specific ballot. The Forum cannot, and must not (to maintain it's legitimacy), attempt to pass a ballot that states something is retroactively compliant.

_______________________________________________
Public mailing list
Public at cabforum.org<mailto:Public at cabforum.org>
https://cabforum.org/mailman/listinfo/public

--
konklone.com<https://konklone.com> | @konklone<https://twitter.com/konklone>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170927/a32e619a/attachment-0003.html>