> The first issue is whether the Mozilla (really, NSS) CA certificate list > should include only true self-signed root certificates; in other words > we should not include CA certificates issued by some other CA. > > I know Nelson and other have commented on this issue in the past, and > may want to do so again. As I recall I had three major concerns in this > regard:
CASE1: > > * If we included only true root certificates, this could presumably > cause problems in cases where Mozilla didn't get a complete certificate > chain. The question then is whether this would be a relatively common > occurence. As I understand it, technically this would be considered an > error under a strict reading of the relevant specifications (e.g., a > misconfigured web server might cause this); however if the number of > misconfigured sites is relatively large then arguably we should consider > a more liberal policy of including non-root CA certs as well. > > Otherwise people will just blame Mozilla for their not being able to > connect to sites. We'd also arguably have increased security risks for > typical users by forcing them through more potentially unnecessary > certificate dialogs, with the attendant possibility of having them get > things wrong and/or get into the bad habit of blindly clicking "yes" to > dialog questions. The problem with including intermediates is your cert list suddenly grows exponentially. If the problem of misconfigured sites persists, we should come up with an alternative solution. CASE2: > > * If we included only true root CA certificates, how does this affect > handling of trust bits in cases where, for example, one CA under the > root issues only SSL server certs, and another issues only email certs? > Presumably we can't set trust bits on the lower-level CAs (because we > don't have their certs pre-loaded), so we have to set trust bits on the > root CA cert for both SSL certs and email certs. Is this correct? There is already a mechanism for handling this. CAs can put special extensions that restrict the privelleges of intermediate certs. And in some cases CAs need to add extensions to their intermediates to have the privelleges carry through. This mechanism has existed since the introduction of intermediate CAs. > > * If we included only true root CA certificates, would it still be > possible to install and use CRLs for lower-level CAs not in the CA > database? This isn't an issue for typical users (since Mozilla doesn't > install and use CRLs by default) but I'd still be interested in the > answer. (I'm presuming the workaround for "power users" would be to > import the lower-level CA's cert and then install the CRL.) Julian would have to verify this, but I believe we have late evaluation of the CRL. > > The second issue is as follows: Assuming that we do decide to include CA > certificates that are not true self-signed roots, do we adopt the > criterion you propose: That approval of including a lower-level CA > requires approval of including its root CA, and (conversely), if we > remove a root CA cert (e.g., because it no longer conforms to our > criteria) then we have to also remove any lower-level CAs under that root. Hopefully we can nip this at the bud and either say 1) we will never include intermediate CA's or 2) if we include them, they will never have any trust bits set on them by default. We can address both of your issues, if necessary, without resorting to including intermediate CA's (and openning the can of worms of "well you include all of Verisign's intermediate, why don't you include ours?" issue). In either case only CASE 2 requires putting trust on those certs, and that case is already handled in the current (and pre-existing) code bases. bob _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
