On Feb 12, 2008 6:53 AM, Eddy Nigg (StartCom Ltd.) <[EMAIL PROTECTED]> wrote: > Short reply... > > Kyle Hamilton wrote: > > However, if someone can put an EV cert in and mark it as such, then > > that arguably causes more security issues for users. Thus, my > > suggestion that Mozilla create a magic trust anchor to issue > > EV-certified CAs from. > > > I think that MoFO doesn't want to build and maintain a PKI with all what > it entails. That's why I ignored the idea and compared NSS as that trust > anchor. Instead only including the EV issuing CA certificates could be > an option for limitation. However I suspect that there won't be many > supporting this, even if it would be the right thing to do...not sure if > there are any other feasible alternative ways in that respect.
Um... I can understand this, except for one major point. MoFo has already built and maintained a PKI. In fact, their software is part of what makes up the infrastructure for the use of public key cryptography. What MoFo hasn't done is built any CA. Without having the CA, anyone who has local access to the certificate DBs on client machines can directly edit the trust settings on any certificate in the DBs. Without having the CA, there's no way to know that a particular string of bits was approved by someone who actually has a clue as to the validation and auditing of a particular certifier. Without the CA, the file-as-distributed is the only way to verify any of that. Since this is a VERY security-critical situation, such a CA should be created. There is no operational reason why the creation or maintenance of such a CA would need to be a long and drawn-out affair. Users already use the MoFo trust list without the benefit of anything other than the code-signing key. All this would do is make it possible to ensure that the only certificates used as extended validation certs are the ones that MoFo (personified by Frank) have verified as meeting the criteria for extended validation. (It would also make it possible to 'de-list' an extended-validation CA's EV capability through a separate action, not a simple bit-fiddling in the trust list. As well as preventing people from claiming EV in any circumstance who haven't been approved for it.) > > > > Path length 1. It needs to be able to create host certs that would > > have path length 0. > > > I think you just misunderstand the path length. It refers to CAs in the > chain, it's part of the basic constraint attributes of certificates. A > CA certificate with path length 0 can't issues another sub ordinated CA > certificate, it issues only end user certificates. I'll look at PKIX and see what it has to say. It's entirely possible that I'm wrong, but I thought that that was only the case if the CA:yes extension existed in the certificate. > > Ideally, I'd like to see EV roots create time-limited rolling CAs -- > > maybe 2 years in length, certify with it for a year, then after one > > year create another time-limited CA valid for 2 years, certify with it > > for only a year... the 2 year lifespan would allow for the expiration > > of the 1-year certs made by it at the end of the first year. > > > That idea would have been useful during the discussion on the EV > guidelines last year, I guess it way too late now. Also EV CAs are > allowed to issue EE certs for up to 23 month (if nothing changed in that > respect since the draft version). But one year is for me the ideal > validity of any EE cert! Gee. Maybe someone should have, you know, announced it to the people who had any kind of stake in it. (Oh, wait, they did -- 'the certifier operators' and 'browser vendors' being the only ones who were viewed to be stakeholders.) I've said it before and I'll say it again, X.509 is absolutely absurd, and the CA business even more so. From information leakage vulnerabilities to not recognizing that the roles and relationships that we have are as valid as our legal information (or more valid than such, in some circumstances) as identities, it's completely out of touch with what people actually need. Regards, -Kyle H _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
