Frank Hecker wrote:<snip>"CA knows otherwise"
This case is also pretty straightforward to craft policy language for; the key is the "knowing" nature of the CA's actions, which in this case would presumably be disclosed in the Certificate Policy or Certification Practice Statement. (Otherwise the CA would be acting contrary to the CP/CPS, and should not be able to pass an audit/evaluation.)
Well, you might be lucky in that the audit/evaluation would pick it up, but I wouldn't rely on that. For some large proportion of cases, if the CA operates in this mode, it will also keep it from the auditor/evaluator.
Actually I was thinking about a case where the "knows otherwise" policy would be enshrined in some sort of official policy, as in the hypothetical "intranet SSL MITM proxy" I discussed. I realize that CAs could do this behind the backs of us and the auditors, and no one would be the wiser.
However we'll go an extra step and assume for the sake of argument that the CA in question issues "real" certs of interest to typical users, in addition to the "fake" certs described here. If we still wanted to reject including this CA cert (and I presume we would, based on the phishing-related concerns) then we'd need either "catch all" language as I've previously described (i.e., to allow rejection based on general security concerns) or a specific policy provision applying to the "CA knows otherwise" case.
One problem with this whole discussion is you are trying to predict a future case, *and* you are assuming that someone is up to no good, so your conclusion is that once found out, it is easy to deal with. Shaky ground.
No, actually I'm not assuming people are up to no good, I'm addressing the hypothetical loophole of a CA that deliberately issues misleading certs per its own published policy, and is able to pass a WebTrust or other audit based on the CA's conformance to that policy. This is to address the criticism that WebTrust and maybe other audit regimes could in theory allow CAs to engage in this practice and others of similar controversy as long as the legalities and formalities were satisfied (e.g., appropriate language in policies, relying party agreements, etc.).
It's somewhat analogous to the case of a software vendor purveying what some may consider "spyware", where the vendor is relying on people to simply click through the EULA ("5. User privacy rights. Without limitation or restriction, all your base are belong to us.") without reading or understanding it.
I think it's unlikely that any CA would seek to exercise this loophole in practice, and IMO we'd have sufficient other policy language to justify rejecting their request, but if the policy can have greater clarify on this point then I think it's worth looking at.
Yes, consider the Verisign conflict of interest with respect to their usage of the Lawful Intercept Service:
http://www.financialcryptography.com/mt/archives/000206.html http://www.financialcryptography.com/mt/archives/000332.html
In that situation, one can say that Verisign could engage in fake cert issuance knowingly. And we can pretty much guess that the auditor would fall into line here.
I agree that this is an interesting "corner case" that it would be fruitless to try to address in a policy like this. In fact, after thinking about it I may just not try to address the "knows otherwise" case explicitly, but just have it subsumed under policy language addressing the "knows nothing" case. (Basically, something like "CA must take reasonable care to ensure that ...")
I think as a technical cryptographic issue, the purpose of the cert is to establish the domain name. This was the pure crypto reason for its existence, as this closed the alleged MITM hole, whereby some bad Mallory would sit at another place and pretend to be both endpoints.
So, if the domain name is not being checked as controlled, then the cert is no longer performing a cryptographic role. This does seem to be at least something to pay slightly more than lip service to.
Is that included in your "CA knows nothing" case? Or does the CA literally hand out certs for Amazon.com to whoever asks?
My "knows nothing" case was in fact intended to cover the case of a CA that hands out certs for "amazon.com", "paypal.com", "ebay.com", or any other possible domain name, to anyone who asks. Think of a test CA instantiation that accepts arbitrary input in a Certificate Signing Request and simply returns a signed certificate with whatever CN, O, OU, etc., were provided in the original request.
As far as phishing is concerned, even if the CA knows nothing, the cert gives that all-important relationship hook.
I'm sorry, I'm not sure what your point was in this sentence. (If it's a minor point that I would probably agree with, don't bother explaining.)
Given the implications for phishing, one could argue that we should also reject a CA whose policies permit "knows nothing" issuance of certs.
No, not at all. With classical phishing, the key to defence is to map the real cert against any other cert. Just the change is enough to base a warning on. If MinimalCA issues an amazon look-alike, then the browser still detects it as being different.
Yes in theory, but AFAIK the browser does nothing about this change, at least in the current implementation. But this is really a question for our friendly NSS developers: Assume a domain www.foo.com and an SSL cert issued for that domain by a CA "Bar", with a user surfing to that site on a regular basis. Assume then that someone manages to get the user to resolve www.foo.com to another site (e.g., through DNS spoofing or whatever) and that second site presents a "www.foo.com" SSL cert issued by a separate CA "Baz". Do NSS and/or PSM in any way detect this change? If so, do they do anything about it?
But, there are two phases in browsing, and they are both distinct:
1. Introduction 2. Repeat visit.
Phishing is primarily a weakness in 2, and this can be addressed with techniques of comparing one cert already known against another not known.
Again, such techniques AFAIK are not currently implemented in Firefox et.al., but in any case I don't think that affects the conclusion I think you're anout to come to.
Yet, if there exist MinimalCerts for given domains, the Introduction, phase 1., is now wide open to an MITM. That's not as serious as fixing phishing, but I can't see the point in winding back the model so far that Mozilla transparently permits anyone to pretend to be anyone.
(Such certs are logically equivalent to self-signed certs. There is nothing wrong with self-signed certs, as long as they are presented to the user for what they are. "This cert is not signed by anyone important!" So in a sense, there is no point in permitting MinimalCerts, because those are self-signed certs and we already have those.)
My understanding here is that you agree that for purposes of our policy we can and should go ahead and include some sort of language re vetting of SSL cert applicants to verify domain ownership, secure in the knowledge that we would not be ruling out any use cases of likely interest. (As you say, we already have self-signed certs for people who want to go that way.)
Are there other possible "CA knows nothing" use cases that at least some people might consider both legitimate and of interest to typical users, and that a policy might have to allow for? Again, I don't know, but I'll assume for now that the answer is "no", and that having the policy specifically address the "CA knows otherwise" case is desirable, although doing so is not as straightforward as in the "knows otherwise" case. So on to the final case...
There are huge untapped security usages for MinimalCerts:
* all of email should start out using MinimalCerts, because most email users already know each other and already have as much trust in each other as they are likely to ever want or can get. * code signing can quite happily use MinimalCerts just to protect downloads from external hacking attacks (a known and rare but actual threat). * anyone putting together a test or low volume site can use a Minimal Cert and later upgrade if it is shown to need any additional protection.
(I'm using the term MinimalCert there to encompass all three levels of certs discussed, interchangeably.)
I'm sorry, now I'm confused: If by "MinimalCerts" you mean certs issued by a CA without subscriber vetting of any kind, then I thought that above you were saying that any legitimate use case involving such certs could be just as easily done using self-signed certs.
For example, in the case of email it seems that your goal above could be accomplished by implementing something like the following: 1. Have Thunderbird automatically generate a self-signed S/MIME cert upon installation. 2. By default send a signed message with this cert for any email sent to people in your address book. 3. Automatically accept self-signed certs received in response to such signed messages. As you note, introducing CAs into this scheme would just complicate it for no obvious benefit.
So, to summarize, here's the lines along which I'm thinking at the moment:
1. It is desirable and possible to have policy language allowing rejection of CAs with "knows otherwise" policies and practices.
OK. Just hypothetically, if we want to go down that path, are you then prepared to proceed given the example I gave above? Is everyone?
As noted above I think I'm not going to try to explicitly address the "knows otherwise" case, but rather have implicitly addressed by language addressing the "knows nothing" case.
2. It is desirable to have policy language allowing rejection of CAs with "knows nothing" policies and practices, with the exact language depending on how we approach the "not good enough" case. (Since the instant that we say "CAs must vet subscribers" then we immediately raise the question of which types of vetting are "good enough" and which are not.)
I think I would say that logically, based on the cryptographic security properties of TLS, there should be the case where each CA does enough to show the domain as being controlled in some minimal sense at least. The only reason for this is that if we don't do this, there is no crypto point in having CAs at all.
Agreed.
Now, that is a completely distinct point to whether a CA does check the domain with high reliability. I'm not saying anything towards the question of whether the controls are good enough or otherwise, and in fact, I think the browser has to be capable of defending itself against exactly that, because as this debate shows, we cannot figure out a way to reliabily control what the CAs do in every case.
I think in terms of policy language my inclination is to express this in terms of a general requirement that CA's "exercise reasonable care" or "take reasonable measures" to, e.g., verify domain ownership. Anything beyond that and I'm concerned with foreclosing on legitimate use cases and different but reasonable ways to accomplish vetting.
Of course this is subjective but as I noted I think this is unavoidable past a certain point.
Anyway, thanks for your comments. I now need to go back and create some draft policy language to reflect my comments above and in previous messages.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
