On Sat, Dec 21, 2019 at 11:30 AM Nick Lamb <[email protected]> wrote: > On Thu, 19 Dec 2019 10:23:19 -0700 > Wayne Thayer via dev-security-policy > <[email protected]> wrote: > > > We've included a question about complying with the intermediate audit > > requirements in the January survey, but not a more general question > > about exceptions. I feel that an open-ended question such as this > > will be confusing for CAs to answer, and moreover I don't want to > > create the impression that Mozilla grants exceptions for policy > > violations because, as a general rule, we don't. > > As a general rule you don't grant exceptions, and so exceptions are > let's say, an exception to that general rule? Hence the name. > > Nope. The point is that we have no systematic process for handling exceptions, and to the best of my knowledge no list of granted exceptions exists. It's not even clear what constitutes an exception. Is any policy violation an exception? Does a certificate that was misissued 23 months ago but not revoked constitute an exception? Are the Symantec subordinates that are allow-listed exceptions? Is an exception something that a Mozilla representative interpreted for a CA as being permitted? Is an exception narrowly defined as something that Mozilla agreed to in writing?
We may have been more liberal in making exceptions in the past, but I have hopefully been consistent in stating that it is the CA's responsibility to decide what to do and inform us rather than ask for permission. So, to the same end as my original proposal, I recommend instead that > Mozilla personalizes any CA survey sent out to a CA which they believe > currently benefits from any such exceptions - setting out what those > exceptions to its rules are for that CA. And in all communications the > text should be clear that any exceptions the CA believed were in place > are in fact spent as far as Mozilla is concerned unless they are > enumerated in this communication. > > This is challenging because no list of exceptions exists and because I'm not aware of a way to perform this type of customization in our survey system (I'll confirm with Kathleen). In the event there are in fact NO exceptions, that's just one small > tweak to the text. > > But potentially a very confusing tweak, unless we define what we mean by an exception. I suggest that we modify question #1 to require CAs to attest that they intend to FULLY comply with version 2.7 of the policy and if they won't fully comply, to list all non-conforrmities. In other words, define an exception as anything that isn't compliant with the current policy rather than something we granted in the past. In the event that one or two CAs benefit from some minor exception > which still has force, it's a little bit of work, and in the process a > firm reminder to both Mozilla and the CA of the ongoing price of such > exceptions. > > Not to mention a good argument that exceptions are unfair. And in the event that it's actually dozens of exceptions across many or > most CAs I hope the realisation of the effort involved will cause Wayne > to reconsider his previous claim that "as a general rule, we don't". > > I agree that it would be valuable to know if this is the case. One valuable opportunity from m.d.s.policy is for CAs to learn from > each others mistakes and in doing so avoid making the same or similar > mistakes themselves. But Mozilla has opportunities to learn from > mistakes here too, and I feel as though the mismatch between Kathleen's > expectation (that a situation should have "resolved" since 2016) and > the CA's understanding (that this constituted an indefinite exception > to Mozilla policy) is such a mistake. > > I agree. > Nick. > _______________________________________________ dev-security-policy mailing list [email protected] https://lists.mozilla.org/listinfo/dev-security-policy
