On 2/10/2008 7:00 AM, Kyle Hamilton wrote: > 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
You raise some very valid points. However, reducing the present backlog of requests to include new certificates appears to have priority over reviewing certificates already in the NSS store. Periodic audits of CAs are required by WebTrust to maintain their seal of approval and should thus be required by Mozilla for continued inclusion in the NSS store. The "Mozilla CA Certificate Policy" focuses mainly on approving new certificates. The small portion regarding removing certificates in section 4 should instead be part of a separate policy that focuses on keeping and deleting existing certificates. I suggest that such a policy provide for retaining existing certificates until there is substantive evidence of misfeasance or malfeasance by the CA; that is, instead of re-approving certificates as standard operating procedure, they should be disapproved and removed by exception. When I wrote bug #333272 -- which resulted in the list at <http://www.mozilla.org/projects/security/certs/included/> -- I requested that the list flag removed certificates or that such certificates be moved to a separate list. Yes, I support the idea of removing certificates when their CAs misbehave. However, I think that merely warning a CA that its certificates are in danger of being both removed and listed as removed -- with the reasons for removal -- would be sufficient to induce a CA to reform. If the CA refuses to reform, then definitely removal and publicity about that removal would be most appropriate. However, all of this discussion is now generalized well beyond the scope of WISeKey and bug #371362. -- David E. Ross <http://www.rossde.com/> Go to Mozdev at <http://www.mozdev.org/> for quick access to extensions for Firefox, Thunderbird, SeaMonkey, and other Mozilla-related applications. You can access Mozdev much more quickly than you can Mozilla Add-Ons. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
