For my part, a "duff cert" is one which is used for fraudulent activity. That's a somewhat circular definition, indeed - but I wasn't thinking in terms of the risk or otherwise from the policy changes.
It's also an "after the fact" definition, and of course here we're having to make decisions before the fact, based on hypotheses on what is likely to happen in the future. Not a straightforward task.
We're in essence saying that use of SSL in e-commerce and financial applications is our primary concern, that the risks associated with SSL in such applications require us to adopt as stringent a set of rules as we can, and that all other uses of SSL have to play by the same rules, whether they make sense in other contexts or not.
This rather falls out of the current binary security UI. (I should say that I'm very sceptical that it's possible to change that; this is merely an observation.)
Fair enough. So let me ask a specific question: If the level of cert assurance is the key issue, do you believe that the binary security UI in combination with potential threats of phishing attacks justifies rejecting CAs that issue "domain validation only" certs, and removing any such CAs' root certs from the current default set? If so, how would you justify doing this? (By which I mean, what is the detailed argument that would lead to this conclusion, expressed in terms appropriate for publicly justifying such a policy to everyone who might be affected by it?)
A couple of other notes on the "binary security model" issue: First, it's possible that some root CAs in the current default set have multiple subordinate CAs underneath them, where one subordinate CA issues "identity-validation" certs and another subordinate issues "domain-validation-only" certs. This is something we'd have to look into, since in removing root CA certs we might face the choice of disabling more than just "domain-validation-only" CAs.
Second, as a future point we *do* have two independent products now, Firefox and Thunderbird, with two separate application domains, and even if we have a binary security model in terms of any given product it's not out of the question that we could have different models for different products, e.g., have a different default set of CA certs for Firefox than for Thunderbird. This might help address the issue of separating the HTTP/SSL use cases from email-related SSL use cases (e.g., IMAP/SSL), at least in a gross way. But of course like many other suggestions this too depends on future product changes that we'd have to find developers to implement...
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
