On Fri, Jun 20, 2008 at 5:44 PM, Eddy Nigg <[EMAIL PROTECTED]> wrote: > This boils down to either of the two other options. If NSS isn't able to > choose the DigiNotar root or treat the cross-signed certificate as > revoked, than the email bit of Entrust should be set to off until the > issue is solved in a different way. Incidentally Entrust failed to make > sure that certificates signed by them adhere to their own policies > (assuming that they themselves validate email addresses - don't remember > now from memory) or that of the Mozilla CA policy. > > *** Which leads me to suggest once again that CAs should sign an > agreement and/or acknowledgment of the Mozilla CA policy as a binding > document. Acceptance into NSS should imply adherence to the requirements > of Mozilla and nothing less than that ***
I tend to disagree. I think that Mozilla needs to grow enough balls to boot out anyone who doesn't continue to adhere to the standards for inclusion after approval. This CANNOT be a one-time requirement. Otherwise things like this will simply continue to happen -- and it's the users who Mozilla seem to think rely on Mozilla to protect their security that lose. Mozilla's afraid of losing marketshare? How about putting something in NSS to inform the users of a previously-trusted certificate why it's been removed? A warning dialog saying something like "For your protection, this email certificate's trust has been revoked because: this CA has delegated its full trust to another CA which has been shown to not adhere to the same level of identity verification for email certificates. We cannot guarantee that the person who sent this is the person that the certificate states that it was issued to." would be very useful here. The system as it stands only works as long as all parties behave... and there isn't anywhere near enough of a means (or desire :P) to enforce the rules when they don't behave. This, more than anything, is what this thread is about. This, more than anything, is what needs to be resolved. As well -- is there any system, at all, in place for reviewing changes to CPSes to included roots? Or do those changes slip through without review (like Thawte's v1 to v2 to v3 CPS updates seemed to)? Auditors always audit against the last-issued CPS. That we know that they passed an audit with an acceptable CPS and continue to pass their audits is not enough. If the CPS updates aren't evaluated and negative changes acted on, the system is easily subverted -- and with over 120 trust anchors in the store, that is far too many entities to trust not to try to subvert the system for their own or their shareholders' gain. -Kyle H _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto