[...] 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.
I have several issues with that statement of a threat model.
1. As I mentioned in another post in this group, a cert is a signed statement from a cert issuer, certifying the binding of a name or names to a public key. The statement is either true or false. if any part of it is false, then the statement is false. I would not say that the statement contains a fraudulent value. The presentation of such a false statement is (or may be) an act of fraud.
2. I would add a crucial phrase to your "key threat" statement. (As an aside, let's not use the word "key" except when describing a cryptographic key. Let's use "crucial" when that is what we mean.)
I would restate that statement as follows:
A crucial threat is that
(a) an attacker is able to present, to a relying browser (or email) user,
a cert, verifiably signed (possibly indirectly) by a trusted CA's
private key, containing a binding of names to a public key, and
(b) the attacker is able to demonstrate that he holds the private key
that complements the public key in the certificate, even though he
is not the rightful holder of the names in the cert, and
(c) the relying browser user is unable to detect the false presentation
of this cert through various channels of communication of certificate
revocation information from the cert's issuer, with the result that
(d) the browser/email user relies on the false presentation to his
own detriment.I would add a second statement.
A second crucial thread is that
(a) a relying browser/email user receives a true and proper presentation
of a certificate and cryptographic proof of the presenter's private
key ownership, but
(b) the relying user receives false information concerning the revocation
of the certificate via the channels of communication of such
revocation information, falsely indicating that the certificate has
been revoked, with the result that
(c) the relying email/browser user rejects the truely presented cert,
and does not rely on the information, to the relying user's detriment.For example, the user could be harmed if he did not believe the true statement "get out now, killers are coming for you" because it appeared to be unverifiable due to revocation of the signer's cert.
Another form of this second threat could occur when sending an encrypted
email. If one cannot encrypt an outgoing message because the recipient's
cert has been falsely revoked and therefore one cannot send the afore
mentioned dire warning, then the would-be sender (who is relying on the recipient's cert) may be harmed by the news of the death of the recipient.
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.
OK. Such a threat statement agrees with the view that proper operation of revocation channels, and conveyance of the correct revocation information is also a threat to the relying user.
Fraudulent revocation does not obviously relate to the browser's security model.
It relates to the relying user's security model. The user may be just as harmed by rejecting true information as by accepting false.
Your original statement of threat model seems to speak only to falsification of information at the time of cert issuance; that is, to the issuance of a cert continaing a false binding. But clearly (e.g through key compromise) events can make the cert presentation false after the fact.
The user who receives the cert presentation relies as much on the accuracy of the cert revocation information after the issuance as on the accuracy of the information placed in the cert itself.
Hence both aspects of CA operation (pre and post issuance) are worthy criteria for CA selection, IMO.
/Nelson
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
