I would NOT agree that it is *inappropriate*. All the questions I asked
had to do with being trustworthy, and for that reason, I deem them all appropriate, since that is the central issue here.
Trustworthiness is not a single metric. You cannot point to an entity and say "they have a trustworthiness of 5 units." Trust is the granting of the ability to break one's security and is always in the context of a security model. One does not trust an entity outright, one trusts an entity to do or not do certain things.
One can declare Fred trustworthy to not permit issuance of fraudulent certs and one can declare Tom trustworthy to supervise one's children. Risks associated with leaving one's children in the care of Fred are inappropriate for evaluating Fred's trustworthiness for inclusion in the built-in CA list, as there are no known childcare related weaknesses in the browser security model.
So we must first determine what the relevant security model is, then consider those factors that affect a listed CA's ability to break the security model.
The key threat is that an attacker is able to present a cert signed (possibly indirectly) by the CA's private key and containing a fraudulent value in a field that the user of the browser relies on. Which fields those are is debatable, but the key fields are definitely the server DNS name and S/MIME email address.
Most of your criteria address the CA's resistance to this threat and are thus appropriate.
Another threat would be that evaluating a cert issued by the CA could cause Mozilla to malfunction. A CA that has malfunctioning or overly fragile OCSP responders would pose such a threat.
Fraudulent revocation does not obviously relate to the browser's security model. It relates to a server administrator's security model, but to the browser that is as relevant as babysitting.
_______________________________________________
mozilla-crypto mailing list
[EMAIL PROTECTED]
http://mail.mozilla.org/listinfo/mozilla-crypto
