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

Ben Wilson ben.wilson at digicert.com
Mon Oct 9 14:27:57 UTC 2017


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.




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 <mailto: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




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.



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171009/805b0051/attachment-0003.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4974 bytes
Desc: not available
URL: <http://lists.cabforum.org/pipermail/public/attachments/20171009/805b0051/attachment-0003.p7s>

More information about the Public mailing list