Frank Hecker wrote:
> <p>This is the official Mozilla Foundation policy for CA certificates > -that it distributes with its software products:</p> > +that we distributes with our software products:</p>
"we distributes" reminds me of the old Popeye cartoons. :) Popeye talked like that.
OK, ok, you know I'm *usually* pretty good about keeping typos out of these drafts :-)
Two questions about this draft:
1. Does this floor address the "Click Yes to continue" phenomenon? Should it?
I'm guessing you mean what was previously discussed about misleading names in certs, in object signing certs in particular IIRC. I'm hesitant to try to craft policy language on this; exactly how would one "legislate" against this particular practice?
2. Recently I encountered an SSL server cert from a low-assurance CA in which the cert's entire subject name consisted of the "Common Name" which was the server's domain name. There was no other information at all about the person/organization behind that cert. That seems like something mozilla's policy ought to address in its floor. IMO, that's not good enough for an SSL CA in mozilla's CA list. Agreed?
No, I respectfully disgree: IMO this is a legitimate use case. If the domain in the cert matches the domain as requested, and if the CA has verified that the "cert owner" is the same as the "domain owner", then the basic anti-phishing protection has been provided. Beyond that one might justify additional identity verification using something like Gerv's argument ("we need names and addresses so we can track down phishers and hold them accountable"), but IMO this is likely to be ineffective in practice against real phishers (due to the relative ease of creating fraudulent ID documents) and imposes verification requirements (and consequent costs) that are arguably overkill for various legitimate use cases involving SSL server certs (e.g., password-protected "friends and family" personal sites).
What I included in the draft policy is meant to be a true "floor", i.e., absolutely minimum requirements that are compatible with all possible legitimate use cases. The policy is not meant as a "best practices" recommendation.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
