Frank Hecker: > I'll let Eddy speak for himself, but I believe he's thinking of a > scenario where we (Mozilla) or the user (a power user, to be sure) would > decide that we trust CA Foo to issue EV certs, but we or the user think > they have unacceptable practices on non-EV certs (like issuing wildcard > DV certs, for example, which Eddy objects to). Then Eddy's idea is that > we (or the user) would configure Firefox et.al. to accept EV certs from > the hierarchy rooted at CA Foo's root, but to reject any other (i.e., > non-EV) certs issued in the same hierarchy. > Bingo! Please note that it has nothing to do with wild card certificates or the current evaluation of Comodo. We simply could determine that CA Foo doesn't conform to the Mozilla Ca policy for non-EV certs, but their EV issuance are perfectly in line with the Mozilla CA policy (and the CAB EV criteria). In this case we should enable EV, and not allow non-EV certs for this root as you explain below correctly. > I'm not proposing we do this, but consider the following: We have a new > "EV SSL trust bit" to accompany the existing SSL trust bit and the > existing EV policy OID mechanism. For a given end-entity SSL > certificate, we do path processing and checking of any policy OIDs > present, and determine whether the cert is a valid EV cert or not. If > it's an EV cert then we check to verify that the EV SSL trust bit is > on., and reject it if not. If it's a non-EV cert then we check the > regular SSL trust bit instead. > > Frank > >
-- 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
