On Feb 10, 2008 3:28 AM, Eddy Nigg (StartCom Ltd.) <[EMAIL PROTECTED]> wrote: > > Kyle, even so part of your argument might be correct, you are doing a great > injustice to some of us here, specially to the ones which bother to review > the CAs. Also Frank and Gerv invest quite some time into getting this right, > starting from reviewing the bugs, keeping track of all the CAs respective > statuses and so forth (see > http://www.mozilla.org/projects/security/certs/pending/ for example). The > handling of everything related to CAs has reached levels, I believe Frank > never envisioned. There is a huge amount of work to be done and in this > respect I suggest that instead of ranting you lend a hand and start to > influence the process.
I perhaps do an injustice to those who do a lot of work in attempting to fulfill the current policy requirements... and I am in full agreement that there is a lot of work to be done. I am certainly not going to dismiss the work done -- it is a huge amount of work, to be certain, and I feel it has been well-done thus far -- and as far as it goes, thus far. However, the process itself is broken. The set of requirements are broken. The only weapon which can be used -- decertification -- is never (and will never, based on the Foundation's view of user convenience as trumping user security) used. This puts Frank into a position (posited earlier in this thread) where the only remaining option is to nag the CAs in question -- nagging which can never be seen as having any enforceable weight. My griping is to expose the flaw in the design of the process. Not to defame the excellent work of those who are administering the process as it stands. > This might perhaps surprise you, but I know of CAs which are already > rejected or pending for various reasons at the bug level and aren't even > considered for inclusion (of course they all have the chance to correct > and/or provide whatever is missing). And just last summer a few CAs were not > included after the comment period because I submitted an extensive review of > the CAs in questions, backed up with facts and arguments. This isn't > "pseudointellectual masturbation" (so I liked this phrase...I had a good > laugh)! I am not surprised by this. The vetting process is superb, for what it is -- and I am not complaining about that at all. The problem that I'm complaining about, as I've said, is that once a root is in the store it's politically impossible to get it removed. Once this is possible, I will withdraw ALL of my objections to the way the situation exists. But, user convenience trumps user security. This is the Way Things Are, and until it's fixed, the security which the vetting process is supposed to be able to ensure is unensurable and untrustable. > However there must be valid reasons and objections which must brought > forward at the latest at the comment periods in order to prevent an > inclusion of a CA which shouldn't be included. This comment period is very > unique and I learned to appreciate the fact that the community has a chance > to review the CAs put up for inclusion, before actually doing so. > Conclusion: Pick on the CAs up for inclusion, read the CP/CPs, check the > auditors and audits submitted, check out the root certificates, read the > comments in the bugs and make your arguments. -- and then after the audits are done, and the CAs included, they can do whatever they want in flagrant disregard for anything they said they did, and there is no accountability for them. THAT is the problem, not the initial vetting. There is no process by which a CA which has already been included to have a "CPS violation complaint" filed against them. Yes, there's a comment period before the root is included -- but there's no way to open a comment period after the root is included when known examples of violations are found. THAT is my complaint. There is no policy in place to review them, and even if they are reviewed the political considerations are simply too powerful to delist the root if they refuse to cooperate. > Concerning CAs which are already included and you suspect fraudulent > behavior, non-adherence to the Mozilla CA policy or other issues, you should > provide the information and make your voice heard. I'm not aware that you've > done so lately... I have not. I must point out, though, that Frank has essentially stated that it's impossible to remove an already-vetted CA. I feel that the word of the administrator is appropriate evidence of the issue. Everything you have stated thus far looks solely at the pre-flight inclusion checklist. I'm looking at the fact that Mozilla, which accepts trust statements on behalf of its users, refuses to take any action to remove trust from CAs which, once accepted, are then operated in violation of those trust statements. I see that Thawte has updated its CPS several times since I made my initial complaint. Why is there no requirement that a certificate include the version of the CPS used when it is certified? Why do I, the user, have to keep fighting to view the (very difficult to see, incidentally) Subject on every website I go to to see if it's an SSL123 certificate or if it's a higher-validation certificate? (oh, wait, that's "chrome", and it can't be changed. :P) And is a bug automatically opened when a CPS changes, to re-vet the revised CPS against the Mozilla policy? Is it a policy that the CA must inform Mozilla when a CPS change is proposed? when a CPS change is approved? when a CPS change is implemented? And who enforces this? What is the enforcement? What is the action that can be brought? What is the action that is politically allowed to be brought? And why, for the sake of all the gods, is the best place to discuss this on the dev-tech-crypto list? This is not a development issue, this is a policy issue. (Also, Frank: You state that the concept of 'artificial scarcity' could be used to abuse oligopolistic positioning. The problem, though, is that once a root is in the store, that root can completely misbehave. The sheer number of conflicts of interest involved makes it very likely that a root is going to violate its CPS at some point just to be able to do something business-related, like 'maintain cash flow' or 'pay employees'. With the sheer number of roots, the chances are that much higher. Until roots can be properly and appropriately constrained, the current vetting policy doesn't do anything more than cause problems. EV certs help, but nowhere near enough.) -Kyle H _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
