[cabfpub] BRs, EVGLs, and "latest version"

[Ryan Sleevi]

You're thinking https://aka.ms/auditreqs , Section B, I believe.

But if that is the issue, then surely a simpler solution is discussing that
with Microsoft, rather than proposing that all root programs adopt a stance
that actually ends up creating significant loopholes.

On Mon, Oct 9, 2017 at 10:27 AM, Ben Wilson <ben.wilson at digicert.com> wrote:

> Ryan,
>
> One issue with the qualified audit,  as was expressed during the
> face-to-face meeting, although I haven’t been able to  find it, is that
> Microsoft apparently requires the WebTrust seal, which is based on an
> unqualified audit.  If anyone can point me to the  requirement, I’d
> appreciate it.
>
> Thanks,
>
> Ben
>
>
>
> *From:* Public [mailto:public-bounces at cabforum.org] *On Behalf Of *Ryan
> Sleevi via Public
> *Sent:* Monday, October 9, 2017 6:40 AM
> *To:* Gervase Markham <gerv at mozilla.org>; CA/Browser Forum Public
> Discussion List <public at cabforum.org>
> *Subject:* Re: [cabfpub] BRs, EVGLs, and "latest version"
>
>
>
>
>
>
>
> On Fri, Oct 6, 2017 at 12:07 PM, Gervase Markham via Public <
> public at cabforum.org> wrote:
>
> During the CAB Forum face-to-face in Taipei, it was noted that the BRs
> currently state something which implies something which is not true in
> practice.
>
>
>
> Gerv,
>
>
>
> I think it's useful here to distinguish between things which are expected
> and things which are audited. As has been discussed in the Forum for years,
> the audit criteria naturally lag behind the adoption of the BRs - depending
> on when a ballot is adopted, this can be as short as a few months, or as
> long as a few years.
>
>
>
> I can think of a number of problems your proposed language would
> introduce, and on that basis, would have difficulty supporting, so it might
> be useful if you could articulate the problem you are trying to solve.
>
>
>
> For example, it seems you might be trying to solve what you view as "the
> CAA problem". However, I think it's worth noting that the CAA problem was
> self-inflicted - the Forum had been discussing CAA since 2012, had
> specifically been concerned about potential gotchas and thus introduced the
> simple mandate to require disclosing CAA practices (allowing CAs to gain
> experience with CAA without any risk of BR violations, by virtue of
> allowing CP/CPS flexibility), and then put a CAA requirement 6 months in
> advance of the actual deadline. The issues only manifest because a
> "deadline" was taken as an "implementation date" - that is, all of the
> flexibility was rejected and deprioritized by CAs, and they waited until
> the last minute.
>
>
>
> However, it also seems to be operating on a misguided - and I would argue
> dangerous to the ecosystem - belief that qualified audits represent a fatal
> state. We know, through similar lengthy discussions in the Forum on the
> nature of audits, that not every failure necessarily represents a
> qualification (as it relies on the auditor's opinion as well as the nature
> of the principles and criteria), but we also know that disclosure through
> audit is far better for the ecosystem than relentlessly chasing a 'clean'
> audit. Indeed, Mozilla's own efforts have been to underscore that point -
> that a qualified audit is not fatal - so I admit, it seems somewhat
> surprising to see you suggest undermining both security and the quality of
> audits in pursuit of unqualified audits.
>
>
>
> Could you elaborate on whether there are goals or context that I have
> missed - and the relative value of those goals compared to the ecosystem
> value? In doing so, I'd be happy to elaborate how your proposal would
> result in less security and less transparency, and the ways in which it
> could be gamed or unintentionally overlooked, in a way that would be
> detrimental to the ecosystem.
>
>
> Best,
>
> Ryan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171009/d35362fe/attachment-0003.html>