Hi Robin, Robin Alden: > > [Robin said...] > 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? >
Robin, this is a very good question, I'm glad you asked and let me explain. Please note, that this is now somewhat off-topic to your inclusion request and concerns more the internal "affairs" of Mozilla. As of today, never has a CA root been removed from NSS, not even ones which aren't in use anymore. A policy is being defined just now, which would give certain powers to developers in order to remove roots which are simply not needed anymore or have an obvious flaw. The approach of Mozilla (through Frank) has always been to work with CAs to address the issues (if any), something I completely support! However there is a psychological barrier perhaps which would make it very hard to remove a CA root which has been approved in the past. Specially a root of a CA your size, is realistically almost untouchable thereafter (this is a real world point of view, not a policy). Not even legacy roots which could be viewed as problematic were ever touched or considered for a review. Just now this opportunity arrived with the upgrade request for EV (which too affects only some CAs). It's much easier to deny inclusion to NSS for new CA roots and smaller CAs (and/or request changes to the affected bits of said CA), then having a CA root from a major CA removed from NSS. > The CA Policy says otherwise. > This is correct and Mozilla certainly has the authority to do so. However this would have to be a very sever issue in order that such an action would be even considered, certainly not for issues such as I have touched here. It doesn't makes it right, it's just a fact. > 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? > Yes, there is something to it. For various reasons, including (I think) because of lacking manpower, CAs are reviewed on an individual basis as they come up for inclusion. Therefore the best chance to insist on a certain quality of certificate issuance by said CA, is when they are considered for inclusion (and/or upgrade to EV). There were already issues in the past, which weren't explicitly mentioned in the Mozilla CA policy, but nevertheless affected the decision for inclusion (making the requests pending to more reviews on the matter and/or pending changes to the CPS of the affected bits). > 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? Yes! Supposed that because of my objections and issues I've raised, Comodo commits to changes to its policies and implementations, I could take this as a precedent for other CAs and insist and apply the same changes as well **. This is specially true because of the size of your CA and market share, this would give it extra weight as I see it. Let me assure you, that I'm very much seeking first and foremost your cooperation on that matter. I very much prefer a dialog than dictate. But the fact, that I did object for the reasons I stated and supposed you accept certain restrictions on your products, this would be the best tool for me, to have them evenly applied to all other CAs, not to mention a possible update to the Mozilla CA policy. ** Disclaimer: This wouldn't happen at day one, but during a reasonable period, CAs could be approach and the changes could be applied upon all CAs affected. In such a case I would commit myself to review CAs which potentially could be affected by that and make Mozilla aware of it and request said changes. -- Regards Signer: Eddy Nigg, StartCom Ltd. <http://www.startcom.org> Jabber: [EMAIL PROTECTED] <xmpp:[EMAIL PROTECTED]> Blog: Join the Revolution! <http://blog.startcom.org> Phone: +1.213.341.0390 _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto