Although not actually on-topic for this thread, the following is
still relevant to the overall issue of approving CA certificates.
My apologies for not responding earlier.
Earlier this month, I went to a secure Web site where the site's
certificate was issued by Comodo, which did not yet exist in my
Mozilla 1.7.2 database (now upgraded to 1.7.3). I downloaded and
added the necessary Comodo CA certificate -- Comodo Class 3
Security Services CA -- because it is on Mozilla's "approved but
pending" list at
<http://www.hecker.org/mozilla/ca-certificate-list/>. But I still
had a problem. It turned out that the Comodo certificate was
signed by the GTE Cyber Trust Global Root certificate, which I had
disabled (but not deleted) because GTE Cyber Trust is not on the
WebTrust list.
I'm sorry, I'm confused: I just checked the Comodo certificates I've listed on my CA certificate list at
http://www.hecker.org/mozilla/ca-certificate-list
and all three of them (AAA..., Secure..., and Trusted...) appear to be true self-signed root certs, with no mention of GTE Cyber Trust. Are you referring to some other CA's certificates?
But in any case your general point is worth considering and responding to.
This adventure illustrates two issues that need to be addressed,
partially in the Mozilla CA Certificate Policy and partially in
Mozilla's practices.
1. When a CA certificate was issued and signed by a different CA,
it should not be approved and included in the Mozilla database
unless the certificate for that other CA is also approved and
included. If the latter CA does not meet the criteria for
inclusion, the former CA should issue and sign its own
certificates. But what impact does that have on site certificates
already issued by the former CA and signed with the defective CA
certificate?
I think there are at least two separate issues here.
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:
* 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.
* 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?
* 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.)
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.
Someone with more knowledge can correct me here, but I think that our policy here depends on the exact way NSS and Mozilla implement "trust" of CA certificates. I presume the threat model here is as follows: If a root CA "goes bad" then they could fraudulently issue certificates either to end entities or to new lower-level CAs. If we are only including the root CA's cert in Mozilla then the logical response is to remove the certificate or turn off the trust bits. This then prevents us from validating certs issued by existing lower-level CAs that still meet our criteria, since we have to validate all the way up to a root cert with trust bits set on. (And even if we did pre-load the lower-level CA's cert then the validation rules still force the root CA cert to be present and trusted.)
If the above is the case then it pretty much forces the policy, in the sense that we don't have the option of retaining a lower-level CA's cert in the absence of its root CA cert. However as far as I'm concerned it also makes it more difficult to take a hard line on removing root CA certs, given the potentially large effects of doing that, including "collateral damage" to lower-level CAs that may still be operating in a perfectly proper manner.
I think in practice we'd have to take the line I suggested in the metapolicy: Treat this case like other security vulnerabilities, and make an informed judgement as to the real risks, leaving open the possibility that the risk is such that doing nothing is the best option.
2. If the ownership of a CA changes, what steps should be taken to
ensure that the practices by which its certificates were approved
for inclusion in the Mozilla database still prevail? It is NOT
unknown for criminals to buy out legitimate businesses. Does
WebTrust periodically re-evaluate CAs? For CAs approved by Mozilla
through its own evaluation, should not Mozilla re-evaluate at least
each time ownership changes?
Stephen Davidson answered the WebTrust question, although that still leaves the question of how we find out about a change in WebTrust status. In general I'm not sure we're always going to know when ownership changes, since I doubt the CAs in question are going to be sending us emails. So I think this reduces to a question about how often we should re-evaluate CAs. I'm running out of time right now so I'll respond to this later, probably in response to Ian Grigg's post on a related topic (review of existing CAs).
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
