Nelson B Bolyard: > > Note that, when it sends the http get request to fetch the cert, it has > not yet validated the cert from which it got the http URL, so it doesn't > know if that URL is legitimate or from some hacker. It blindly fetches > whatever the server at that URL sends it. Quite a few people view this > as a security vulnerability and/or as a privacy vulnerability. That may > well be a reason that FF3 doesn't use it.
I don't think so, because if the CA certs it fetches doesn't chain up to a trusted root and the EE certificate is in effect issued by the fetched chain (there can be quite a few CA certs in a chain), the chain can't be built and the EE cert remains effectively issued by an unknown root. Their might be an issue concerning privacy, however CAs are usually bound to some privacy policy (and audited accordingly), so the privacy issue is here somewhat under control. > Some server products check at startup that they have complete cert chains > to send out, and inform the admin if they don't. I gather that most > servers do not. Neither Apache not IIS do that AFAIK. > I'd say it's a deficiency of the server admin > tools they're using that don't inform them that the job's not done. Yes, there is something to it... > It's there in 3.12, and has been for quite a while. It gets tested > continuously in NSS QA tests. What hinders its implementation? This issue comes up every while. FF3 implemented the caching of intermediate CA certificates once it gets them, which is a great step forward, fixing this issue would be really cherry on top :-) This and the fetching of CRLs (in case there is no OCSP responder or OCSP validation is disabled). -- Regards Signer: Eddy Nigg, StartCom Ltd. Jabber: [EMAIL PROTECTED] Blog: https://blog.startcom.org _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
