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.
I'm not alone? Interesting. So, maybe add a "for now" to that meta-rule? <http://bugzilla.mozilla.org/show_bug.cgi?id=211498>
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.
Agreed about the near term.
But if really so many people believe in that model, we should consider moving to it or at least fully supporting it, right now it's not possible *at all* in practice, not even for advanced users, because of bugs like 211498 <http://bugzilla.mozilla.org/show_bug.cgi?id=211498> (I was upset about the treatment of that bug). This goes in scope far beyond the policy. <http://bugzilla.mozilla.org/show_bug.cgi?id=211498>
why should [Microsoft's] root CA cert not be included?
One reason would be that I/we don't trust them, and CAs are all about trust.
the risks, threats, and criteria, as a second section after the current content.
I don't think you need to put the general risks and threats in the concrete policy, but I'd expect the verifyable criteria (CA does this and that to verify cert holders, does this and that to ensure security, does not do this and that etc.) to be in there. If there is any step-by-step process as guideline to evaluate CAs, it should be part of the concrete policy, too.
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.
A n.p.m.announce.security would be a good fit, but we don't have that yet (we should have it).
(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.)
The beef of that page would be the concrete information about each CA, and that can be done while evaluating the CAs, not? Then you probably also know what information makes sense to put there (I wouldn't know that).
Besides, "relatively few" in this context could mean at least a few dozen certs
Ah, I thought 1-3.
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.
I don't really understand exactly what you mean here. What is the specific threat that you're concerned about here
Let's say your enemy (the one you want to protect yourself from) is not any competing company, but the government. E.g. you are a Chinese dissident or like to criticise the US policy or have information that's interesting for the government in some way or are just friends with such people. You are scared that the government may read certain information or pretend to be one of your allies to make you do things (e.g. come to a certain place) or break into your computer and use your own webcam for surveillance. Or maybe you have information on your computer that could threaten your life in some way (e.g. possibility to be abused, with that abuse leading to your death), if it falls into the wrong hands. Or maybe you just want to be sure that nobody (apart from you and the addressee) can read your love letters, really *nobody*.
Let's say you exchange sensitive emails with Arthur Friend <[EMAIL PROTECTED]> in these circumstances via S/MIME. The US government indeed wants to read your mails. It can just create its own certificate for Arthur Friend <[EMAIL PROTECTED]>, walk into the VeriSign office, ask them to sign it, and then start to pose as A. Friend towards you or just intercept the mails, read them, maybe alter them, and forward them. As I understand it, PSM/NSS will currently accept new certificates signed by trusted CAs, even if a *different* certificate is already known for that entity (I think even if the CA mismatches). Mozilla would show the lock / pen icon as if everything were OK and you'd never notice that you're now talking with the US government, unless you check the cert fingerprint, which you are unlikely to do for every mail.
Similar threats exist for signed software.
So, in the current model, you are vulnerable to governments (actually anybody) which control root CAs.
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?)
You asked about threat models, and that's mine ;-).
There's probably not much we can do in the policy (the typical SSL model is probably (intentionally) inadequate to protect against that). Maybe it will make a difference in practice during CA evaluation in one case or the other, maybe we can't do anything in practice (in the policy). But I personally think we should acknowledge that risk, be concerned about that, and state so.
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.
There was an attempt a few years before to put crypto signatures into DNS, but that hasn't gone forward, largely due to .com (Verisign and ICANN) not cooperating. I don't know of any current efforts. As-is, it seems to be relatively easy to make a certain victim go to your server instead of mail.yahoo.com, but IIRC it involves active attacks (or of course controlling part of the infrastructure). Given that DNS *could* be safe by principle, it's quite unsafe.
Also, does the CA vet the certificate field
typo?
You think that "vet" is a typo? No, it's the word I meant
Nod. I just didn't know that word, and my dict said 'a doctor for animals; treating or examining an animal'. Another dict I just used says 'check thoroughly', I guess that's what you meant. I just had a hard time to make make sense of the sentence, but because it's my lacking English knowledge, ignore my comment.
Yes, you're correct that the criteria are sketchy. This is because they are still being written.
Ah, I thought it is supposed to be almost done.
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.
FYI, I completely agree with the current policy on that.
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.
I see. I didn't know that these meta-criteria were so much of an issue.
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
I think these criteria are critical to the well-functioning of the whole system. The criteria I mentioned are things I would expect as a *matter of course* from all default CAs. If they are not followed, I'd consider the whole system to be broken. I probably didn't even include everything I consider necessary. Basically, because the whole security model stands and falls with the CAs, I think the criteria for the CA's own security can hardly be too strong (as long as they are still doable). And weak verifying of certs by one CA means practically weakening it for the whole system, because all CAs are treated equal.
Yes, the system is rendered useless, if getting individual certs is prohibitively expensive (or has unacceptable requiements bound to it). But I don't think we should allow people to just add a CA to a server that (to give an extreme example) already carries a large HTTP server with lots of scripts, FTP server, CVS server, DNS, mail, mailing lists, shell accounts etc.. Running a CA requires dedication and a lot of time, it's IMHO nothing you can just add to your larger list of services.
Sure? Bugzilla is totally inadequate for longer discussions.
In reality longer discussions will probably spill out to the newsgroup(s) anyway
Full agreement.
_______________________________________________ mozilla-crypto mailing list [EMAIL PROTECTED] http://mail.mozilla.org/listinfo/mozilla-crypto
