Robin Alden wrote: > Perhaps my problem then is understanding the process at all. You seem to > suggest that once our application for EV status is approved we somehow > become immune to changes in your CA policy. Why do you feel that Mozilla > has no control over the CAs other than at the point of approval of a change? > The CA Policy says otherwise. > Or are you saying that your (collective) influence over CA policy is not > what you might hope for but that you can get concessions from individual CAs > at the point of approval? > > If I agree to accept a restriction on a product of ours, can you explain the > method that propagates that restriction to the other CAs?
Let me clarify some more from a Mozilla Foundation point of view, since it's our policy, and I'm the one implementing it. (I may be responding here more to some of your earlier comments, I'm beginning to lose track of all the posts about this topic.) 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.) 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. 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. 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. Frank _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
