Hi Kyle, I always believe that creative ideas are useful, even if they are not implementable, because they may lead to something that is. But here my short reply:
Kyle Hamilton wrote: > I am not party to the CAB Forum guidelines, and in fact wouldn't have > any idea where to find them. That said, though, I would suggest that > EV be an attribute of the trust anchor (ie, like the SGC attribute > used to be in older versions of Netscape Navigator). I am not > entirely certain it doesn't make sense to create a specific magic > trust anchor for Mozilla to directly create chained certificates from, > with a CA depth of 2, and all CAs granted EV validation signed by this > cert. The admittance and upgrade of CA roots to roots that are recognized as EV enabled is effectively that "trust anchor". Without it, they will remain just regular CAs or not at all. So NSS is like as if Mozilla has issued the certificate ;-) The problem I'm seeing perhaps is, that once a root is enabled as such it can currently issue X intermediate CA certificates. Tracking that is impossible. I don't know if NSS can override the path length which is in the CA root. But it's an interesting idea ;-) > > This would allow EV validation to be limited to those certs (the path > length constraint would prevent the validated CAs from issuing > workable sub CA certs). That would be correct. > Since the certificate to do this would be in Mozilla Foundation's > hands, an argument could be made that the normal requirement of a > webtrust audit would be unneeded (since without it it would be limited > to client-modifiable flags in the cert db, and the browser vendor is > already ultimately-trusted anyway). Since I believe that overriding the path length isn't possible - and also not feasible if the same CA root issues also other certificates than EV, the only way to get some control is, to admit only the subordinated CA and mark it as EV enabled. It should have path length 0. Sounds like a big headache? In the beginning I thought it is, but actually how many EV enabled sub CAs does a typical CA have? One, maybe two? So the effort we are investing right now to enable all those roots would be the same. Just that sub CAs have usually a shorter life time and we'd have to do that again in ten years perhaps...but that's what control is about. > > Just tossing the possibility out on the table. Good! Just tossing back :-) -- 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 [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
