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

[Ryan Sleevi]

On Wed, Sep 27, 2017 at 1:40 PM, Kirk Hall <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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20170927/75a3a008/attachment-0003.html>