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

[Eric Mill]

On Wed, Sep 27, 2017 at 11:49 AM, Kirk Hall via Public <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]
> *Sent:* Tuesday, September 26, 2017 10:01 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: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.
>
> _______________________________________________
> Public mailing list
> Public at cabforum.org
> https://cabforum.org/mailman/listinfo/public
>
>


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