I'm sorry, I thought this had actually been cc:ed to the main list. My apologies (and thanks, Eddy, for pointing it out!)
-Kyle H ---------- Forwarded message ---------- From: Kyle Hamilton <[EMAIL PROTECTED]> Date: Feb 11, 2008 4:06 PM Subject: Re: Reassessment of sub-ordinated CA certificates To: "Eddy Nigg (StartCom Ltd.)" <[EMAIL PROTECTED]> 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. 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). 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). Just tossing the possibility out on the table. -Kyle H Sent from my iPhone On Feb 10, 2008, at 17:33, "Eddy Nigg (StartCom Ltd.)" <[EMAIL PROTECTED] > wrote: > Frank Hecker wrote: >> Eddy Nigg (StartCom Ltd.) wrote: >> <snip> >> >>> ... _I'm requesting >>> hereby and now to have thorough review of this situation and >>> reassessment_ of the Mozilla CA policy concerning everything >>> related to >>> sub-ordinated CAs. >>> >> >> This is a good discussion to have, and I agree that it's a timely >> issue. > > Frank, in addition to that I would suggest that you examine > immediately > if to stop any processing upgrades for EV (and inclusion requests) > until > we decide what we are going to do exactly in regards of sub-ordinated > CAs, specially concerning EV. Because after I visited bug > https://bugzilla.mozilla.org/show_bug.cgi?id=376853 which David > mentioned earlier, I found something even more surprising than I > expected: > > Network Solutions has a server certificate issued by "Network > Solutions > EV SSL CA". Ever heard of this CA? Well, it's chained like this: > > "AddTrust External CA Root" from Sweden and belongs to Comodo from the > United Kingdom -> > "UTN-USERFirst-Hardware" from the US -> > "Network Solutions Certificate Authority" from the US -> > "Network Solutions EV SSL CA" (Surprise!) -> > "www.networksolutions.com" > > Now, I have no clue how this is going to work and perhaps Nelson can > give us some more information....example: If AddTrust is going to be > upgraded to an EV root, is any sub ordinated CA potentially an EV CA? > Apparently Network Solutions have a relevant CPS published at their > web > site, but were they audited according to the WebTrust EV criteria? I'm > not saying anything about what they are and what they did, since right > now I'm not investing my time in it to find out, but supposed they > were > not audited accordingly, then this would raise for me the alarm bells. > > Perhaps somebody knows to explain how this technically will work and > how > the criteria and CAB Forum guidelines are meant to be. I was very much > under the impression and it was stated again and again as an > argument in > favor of a positive vote at the CAB Forum, that for EV all CA > certificates issuing EV certificates will be audited accordingly (and > not by proxy of some parent root CA). Another argument which was given > here, that NSS will be able to pick only CA certificates which are > really EV and confirmed as such, but suddenly I've got the feeling > that > we are going to repeat a well known story once again...?? > > Of course this was one of the reasons why I called for a > reassessment of > the Mozilla CA policy concerning sub-ordinated CAs, but right now I > wouldn't know what the rules in that respect are (and going to be) in > order to judge such an upgrade or inclusion request. I'm looking at > the > certificate details of Network Solutions and have no idea how to > handle > that. In short we need to lay down the rules urgently and I suggest in > the meantime stop all other work in regards to inclusions and upgrades > until we've solved this problem. > > -- > 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 _______________________________________________ dev-tech-crypto mailing list [email protected] https://lists.mozilla.org/listinfo/dev-tech-crypto
