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-boun...@cabforum.org] On Behalf Of Ryan Sleevi via 
Public
Sent: Monday, October 9, 2017 6:40 AM
To: Gervase Markham <g...@mozilla.org>; CA/Browser Forum Public Discussion List 
<public@cabforum.org>
Subject: Re: [cabfpub] BRs, EVGLs, and "latest version"

 

 

 

On Fri, Oct 6, 2017 at 12:07 PM, Gervase Markham via Public 
<public@cabforum.org <mailto:public@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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

_______________________________________________
Public mailing list
Public@cabforum.org
https://cabforum.org/mailman/listinfo/public

Reply via email to