Sorry for jumping in and if I make arguements already discussed sufficiently.
No need to apologize. It's useful to have comments from more people than just those who've commented thus far. Thanks for taking the time to read the documents and respond.
11. ... We have to deal with the world as it is, not as it might be or as we might wish it to be
I disagree. We're here to *change* the world, aren't we? ;-)
Yes, but... I think there's a limit to how much we can change the world at one time. For example, as I noted in the metapolicy, many people have proposed that Mozilla move away from a CA-based model (i.e., for SSL-enabled servers, S/MIME email, and signed code) and move to a SSH-like model of self-signed certificates. Regardless of whether this would be a good idea in theory or not, IMO it's certainly not a change we can make in the near term, for lots of reasons. (Among other things, we don't have an agreed-upon design for the UI and underlying code, nor do we have anyone committed to implement such a design.)
If the Mozilla person assessing the CA gains deep insight into the processes of the CA, e.g. by speaking with the CA people, being physically onsite, being virtually onsite by being allowed to access and check their servers (using a user/guess account over SSH), and he gains confidence in the CA as a result, and documents that publically as far as possible (not all of the above may be possible to publish), and bases his decision partially on that confidence, would that satisfy your rule or conflict with it?
Yes, IMO this would satisfy the requirements of the proposed policy. It would obviously be nice to have as much documentation as possible, but at a certain point you have to trust the evaluator's judgement. (This is assuming of course that the evaluator has a good reputation as someone whose judgement you can trust.)
If a company has proven to be ruthless, I don't want their certs to be in Mozilla by default, no matter how many independent audits they passed. Hypothetical case: If Microsoft was a CA, would you include them, if they formally passed our criteria? If a company has a track record of issuing bad certs or even having their root cert stolen, that's reputation, and IMHO very relevant.
I wasn't proposing to ignore the CA's track record specifically as a CA, I was referring instead to the CA's general reputation as a business. To answer your hypothetical question: if Microsoft acted as a CA, and if Microsoft properly did the things one would expect a CA to do, then why should their root CA cert not be included? Whether Microsoft is a "good" company or "bad" company in terms of other non-CA-related business practices (for example, the sorts of things that got them in trouble with the US and EU) is IMO of little or no relevance.
However a CA's certificate should be removed only if there is adequate reason, not just in the form of increased risk
So, if I'm a CA: start nice, or even just pretent to be nice, and when I am included, I can get sloppy or evil?
Yes, the certificate holders of a CA have a reasonable expectation to not have the certificate be draw from under them, and this should be considered when removing CAs.
But I wouldn't state it *that* explicitly in the policy, so it would be perceived as a right to stay in the root. I'd rather word it as "consider", not "should not" or 'increased risk is not a reason'.
The text you're quoting is from the meta-policy, not the policy itself. The policy itself simply states that "The Mozilla Foundation reserves the right to discontinue including any CA certificate in Mozilla, at any time and for any reason." The policy details FAQ expands on this a bit:
http://www.hecker.org/mozilla/ca-certificate-faq/policy-details/#discontinue
The language I included in the meta-policy is more of a statement about the practical difficulty of removing root CA certs that are relied upon by a lot of Mozilla users.
<http://www.hecker.org/mozilla/ca-certificate-policy/>:
the actual criteria themselves will be included in another document, most likely the FAQ on policy details, not in the policy itself.
I'd say the actualy criteria *are* the policy, so should be part of it. You already have a meta-policy, with this you make that a meta-meta-policy.
This is really a question of what text should go where. Initially I wanted to keep the policy document itself short, and put the more lengthy details in a separate document. Now I'm thinking about extending the policy document to put the most important items, namely the risks, threats, and criteria, as a second section after the current content.
CAs should send an email message to [EMAIL PROTECTED]
It should be mandatory policy to inform interested users of new root CAs after decision, and before decision for people who want to take part in the discussion.
That's partly specified in the policy details document:
http://www.hecker.org/mozilla/ca-certificate-faq/policy-details/#request-process
See item 5. What I forgot to include was a step to publicly announce decisions about new CA certs being included. I think the best way to handle this is to announce decisions first in n.p.m.crypto, and then also to include information about this in release notes for milestones.
(I'd also like to have a page on the mozilla.org web site where we include links to information about the root CAs whose certs are included. This would include links to public documents referenced in the evaluation decision, as well as links to the relevant Bugzilla bugs. Of course, someone -- presumably me -- will have to find the time to put this together. I'd be happy to see someone else volunteer for this task.)
<http://www.hecker.org/mozilla/ca-certificate-faq/policy-details/>
For example, a given CA might issue relatively few certificates, but those certificates might be issued to particular web sites used by a large number of Mozilla users.
I'd rather add the actual certs, not a root cert. Much smaller risk.
Someone else can comment here, but I think there's been a long-standing policy of adding only CA certs to the default cert list, not certs for web sites or other servers ("end entity" certs, to use the PKI jargon). Besides, "relatively few" in this context could mean at least a few dozen certs; that's a lot of certs to add individually and mark trusted.
Which risks and threats are you concerned about in connection with certificates and CAs?
The answer doesn't really show the cases we consider problematic. Most controverse is probably: Do we trust governments? I don't. This implies that I don't trust Verisign either. You may argue that I'm paranoid, but many governments (incl. US and Germany, unfortuantely) are snooping on their citizens, even innocent third-parties, so I'd argue that this is some risk even for average users.
It's hard to fight governments, but there are some things which can be done to migitiate that risk (e.g. not blindly accept a *changed* certificate), which could be considered, if we acknoledge that risk.
I don't really understand exactly what you mean here. What is the specific threat that you're concerned about here, and how specifically would you propose to mitigate it? (Also, what additional criteria would you propose to add to the policy relating to this issue?)
(This check can be thought of as providing additional security against DNS spoofing beyond what is present in the DNS itself.)
DNS provides security? ;-)
Well, though I'm not a DNS expert by any means, I thought there was at least some ongoing work aimed at improving DNS security. But maybe I'm wrong.
First, recall that we are co... Next, given these assumptions we need to...
I'd strike these paragraphs. Don't fit, and almsot anybody interested in root certs knows that, I'd guess.
I presume you're talking about the first two paragraphs in
http://www.hecker.org/mozilla/ca-certificate-faq/policy-details/#criteria
I respectfully disagree that these paragraphs are redundant (though it's an open question whether they should be moved elsewhere). In fact, at least in my own mind these points are absolutely critical to creating a reasonable set of criteria.
First, in order to assess potential threats for a typical Mozilla user you have to specify what that user's likely security settings are going to be and how you anticipate the user will behave in security-relevant situations; that's what the first paragraph provides.
Second, in order to determine the value of various criteria for CAs, you have to determine how conformance to those criteria might or might not actually mitigate risk for a typical user. My claim is if a CA conforms to a particular criterion, and that conformance in fact has no effect on the behavior of Mozilla as experienced by a typical user, then you have to question the value of including that criterion in a policy intended to benefit typical users.
(Of course the criterion might be useful to non-typical users, in which case we would make a judgement call as to whether it's worth including the criterion anyway. CRLs and OCSP are good examples here: At present they appear to provide no benefit to typical users as defined, because they aren't enabled by default; thus one could question the usefulness of including criteria related to CRLs and OCSP in the policy. However CRLs and OCSP do provide benefit to non-typical users who know about them and turn them on, and CRLs and OCSP might provide a benefit to typical users if Mozilla were changed in the future; based on that it would arguably make sense to include criteria in the policy related to CRLs and OCSP.)
The second paragraph thus attempts to describe the ways Mozilla might behave differently in various situations involving the use of CA-issued certificates, so we can "test" the criteria to see how criteria conformance or nonconformance might affect this behavior.
Also, does the CA vet the certificate field
typo?
You think that "vet" is a typo? No, it's the word I meant, though I could use another one. (Also I should change "field" to "attribute" I think, and of course "displaed" in that sentence really is a typo.)
Should there be rules wrt to malware, i.e. abuse of rights when running software signed with the cert? If an extension comes with a signature with mozdev as root CA, I bet almost all users (actually including me) expect that the software doesn't do anything evil.
I know that this would probably be against CA standard policy (we just certify the name, not the holder or content), but runs *totally* against most user expections.
You're right that most users would expect this. I suspect this arises from the common (mis)perception that CA's are providing a sort of "Good Housekeeping Seal of Approval" (sorry, US-centric reference) for their customers.
I don't have any good thoughts at the moment as to whether it makes sense to try to police CAs in the manner you suggest.
Criteria:
Given the long documents, the actual concrete criteria are very vage and weak.
Yes, you're correct that the criteria are sketchy. This is because they are still being written. I left the criteria for last because IMO before looking at criteria we had to settle various issues regarding the context in which the criteria would be used. Thus, for example, we had a lot of discussion about whether we should pay attention to legal risks, and whether or not the criteria should address those issues. We had other discussions about whether risks varied from country to country, and how that might change the criteria. The metapolicy was/is my attempt to address all these preliminary issues and prepare us to focus on the criteria in a single specified context.
Is there a minimum requirement *how* the server name, email address or real name (for person or company) must be determined. In particular, I think (might have misunderstood it) there are several "classes" of certificates you can get for email - Class 1 checks only the email address, but does not have your real name, Class 2 checks your real name using passport?, there's also a Class 3. Even with GPG, it's generally expected that you check the real name against the passport, in person, before you publically sign a key. The policy here doesn't mention *any* of that. If I find a company name in a certificate, signed by any CA, can I rest assured that the CA actually checked the records, in a secure way, to assure that the name in the cert matches the holder name? That the actual person/computer holding the cert is allowed to act on behalf of that company?
This is an open question that we need to discuss; see my post at
http://www.google.com/groups?selm=c57v2e%24fvi2%40ripley.netscape.com&output=gplain
in particular the three paragraphs beginning "There's another criteria-related issue...".
What about CA security? How does the CA ensure that the root CA is not stolen, the server rooted (virtually or physically), that no man-in-the-middle attack is taking place during signing up? I'd personally say it's minimum requirement that the server is physically safe from access and guarded, and I would *not* count datacenters of hosting services in that, it should be guarded by people of the CA. I'm pretty sure that my servers at home are safe, but I don't know if anybody accesses my dedicated server at the hosting company. Similarily, securing a server virtually is a very hard task. As a basic rule, I'd say that the CA server should have no other functions (esp. no FTP server, CVS server etc.), no known remote holes etc..
We need to discuss yours and other's suggestions about criteria relating to CA key protection. Again, I left this unspecified because I wasn't yet sure what to include.
However I will make one general point here: I would like to have the minimum set of criteria that will accomplish our purpose. We could spend all day and night thinking of things we'd like CAs to do or not do, but we need to evaluate whether those things belong in the policy, based on cost/benefit trade-offs and other factors.
What is the process by which our request will be evaluated and a decision made?
The answer is nice, but as said earlier, that should be part of the actual policy, and should include announcement of positive decisions of inclusion.
I agree with you; see my earlier comment.
The module owner and other interested parties will discuss the request in Bugzilla (/not/ in the newsgroup and mailing list)
Sure? Bugzilla is totally inadequate for longer discussions.
Yes, but at least a bug provides a single point of reference, as opposed to trying to follow a set of newsgroup threads to determine why particular decisions were made. In reality longer discussions will probably spill out to the newsgroup(s) anyway, but I'd like to keep discussion on the core issues in bugzilla.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
