Kyle Hamilton wrote: > 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. >
Kyle, first of all I believe that it depends a lot on the severity and it's not a position per se of MoFo or Frank, but rather the preferred approach. I agree (with Frank), that if the issue at hand can be solved by dialog with the CA in question and it doesn't directly and severely impact the users security, this to be the right approach. Nevertheless, if the severity of the issue has a direct impact on the users basic security, the CA root in question will be immediately and expressly distrusted and an update of the affected products published. See also bug https://bugzilla.mozilla.org/show_bug.cgi?id=413375#c8 which Nelson is working on currently. > -- 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. Absolutely not! > > 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. Sorry? Are you saying you don't know where and how to complain against a CA? Don't make me laugh... This mailing list is one way, the other by opening a bug report. > There is no policy in > place to review them, Yes, there is *one* Mozilla CA policy which governs the CA inclusions and the reversal thereof. If you've found a CA not conforming to the CA policy of Mozilla (and there indeed might be some) I'm sure, that after reviewing the information provided by you, which proved to be correct, the members of this community will support your call for action. Of course, again it depends on the severity of the violation as stated above. > and even if they are reviewed the political > considerations are simply too powerful to delist the root if they > refuse to cooperate. > Since I'm not aware that ever such a case was brought forward in a serious manner and fashion, your statement above is simply a myth. > > I have not. I must point out, though, that Frank has essentially > stated that it's impossible to remove an already-vetted CA. Did Frank say that? I don't think so...rather other members like Nelson said very clearly, that any such claim against a CA should be brought forward and if proved correct, such a root might be yanked. > > 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) > Just a year ago I made a call for improving the way certificate details are displayed. I haven't received sufficient support for it...Nevertheless in FF3 it has been improved somewhat - not enough for my taste however. > 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? > No, but you can suggest it. > 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. > Is dev-security better or do we need a different channel for it? Policy issues are handled on this mailing list on a regular basis. And bug reports are opened accordingly each time... Not sure, but I don't see a problem here. -- 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
