> In terms of getting "concessions" from individual CAs: In the past we > have held up approval of CA requests until we could be satisfied that > CAs were in compliance with specifically-called-out requirements of our > policy. For example, in a number of cases it wasn't clear at all from a > CA's CPS what kind of applicant validation they did for given types of > certificates. IIRC in at least one or two other cases we had CAs that > had verification procedures that didn't appear to meet our bare minimum > requirements, and we asked them to make improvements as a condition of > approval. (An example would be a CA that issued individual certs usable > for S/MIME email, but did not appear to actually verify that the > individual controlled the email address named in the cert.) [Robin said...] Fair enough. > > I don't consider the above to be asking for concessions, I see it as > simply asking CAs to do what pretty much any CA should do, in order to > meet the explicitly called-out requirements of our policy--requirements > that I consider consistent with standard CA industry practices. [Robin said...] That's fine. We are keen to comply with the CA policy because we want our CA requests to be approved. > > There are other cases where CAs engage in practices concerning which we > didn't or don't have explicit policy requirements. Past and present > examples include issuing end entity certs directly from roots, issuing > multiple classes of certificates under a single root's hierarchy, having > too many roots (for some definition of "too many"), issuing DV certs > with lifetimes that are too long (for some definition of "too long"), > issuing wildcard DV certs, having subordinate CAs that aren't externally > audited, and so on. Lots of Mozilla community members (not just Eddy) > have argued one way or the other on these issues, including claiming > that one or more of these practices are security risks, urging that we > deny particular CA requests on that basis, advocating that we change our > policy to outlaw these practices, and so on. > > My opinion is that resolution of these issues is better done outside the > context of any particular CA request, as part of a more general > discussion of revisions to our policy. Then we can look at the issues in > the context of the CA industry as a whole (not just commercial CAs, but > any CA whose root might be preloaded into Mozilla, including government > and nonprofit CAs), and make better decisions about what if anything our > policy should say about the practices in question. [Robin said...] We are quite happy to keep the issues raised under discussion past the point that our current rounds of CA requests are accepted. None of the issues raised are spurious. Our main current objection to them is on grounds of maintaining a level commercial playing field among all CAs (in the Mozilla root program).
> However these individual CA reviews have proved useful for turning up > new issues we should consider, and I think they're worthwhile for that > reason alone, in addition to the other purposes they serve. Also, as I > think Eddy noted, there are few if any other open public forums for > looking at CA-related issues like these that are of potential interest > to any developers and users who rely on CAs in one way or another. Maybe > in the future the CAB Forum will evolve into an organization open to all > interested parties (e.g., like the standards bodies that exist in other > areas), and then we can move these more general discussions and lobbying > efforts to that forum. But until that happens we (Mozilla in general) > can't simply hash things in private discussions in the CAB Forum or > elsewhere; we're a nonprofit organization with a public benefit purpose, > and public participation is key to the way we operate. [Robin said...] I acknowledge the value of the process. Is there anything remaining which would now hold up approval of our CA requests? Regards Robin _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
