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.
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.)
3. It is possible to have policy language addressing the question of whether CA's vetting of subscribers is "good enough", but it likely will prove to be impossible to completely eliminate subjectivity in the implementation of such policy language (i.e., in determining whether a particular CA passes the test or not).
4. Any policy language needs to take into account and separately address the possible use cases and the relevant threats for those use cases. For this policy we have three overall categories of use cases -- for email certs, SSL server certs, and object signing certs -- and then multiple use cases within those overall categories (e.g., for SSL server certs we have HTTP/SSL for web sites vs. IMAP/SSL for email servers).
Now let's see if I can crank out the next message right away, and not keep you all in suspense :-)
Here I am again. Now for the hard part, proposing particular policy language to flesh out the points above. Rather than ramble on in an attempt to come to a conclusion, I'll present my conclusions first and then explain my motivations afterward.
So, without further ado, if we do have policy language on vetting CA subscribers I think it should look as follows (I'll propose more detailed language in a future message when I have time, but this will have to do for now):
* For SSL server certs the requirement should be something like "the CA must take reasonable measures to verify that the entity owns the domain associated with the certificate" and "the CA must not knowingly issue certs to entities who do not own the associated domains". (The language also has to address the question of agents who are authorized to get certs on behalf of the someone else; we'll skip that for now. We'll also postpone for now the issue of what is "reasonable" and what is not.)
* For email certs the requirement should be something like "the CA must take reasonable measures to verify that the entity controls the email account associated with the certificate" and "CA must not knowingly issue certs to entities who do not control the associated accounts". (Again, we'll skip for now the issues of agents and what is "reasonable".)
* For object signing certs the requirement should be something like "the CA must take reasonable measures to verify the identity of the entity associated with the certificate" and "CA must not knowingly issue certs to entities whose identities are different than those of the entities named in the certs". (Again, we'll skip for now the issues of agents and what is "reasonable".)
(Note that I'm ignoring for now the issue of CAs issuing certs that might be confusing to users, e.g., an object signing cert for a company "Micros0ft Corporation". One can of worms at a time is quite enough for me, thank you very much.)
Why did I choose these particular requirements? Let's take each of the cases in turn:
SSL server certs
Here the primary threat of interest is clearly phishing, and if CAs and SSL are to protect against phishing at all then at a minimum there must be some assurance that only the owner of a domain can get a cert for that domain. Otherwise having the user compare the domain name in the address bar and the domain name in the status bar (as recommended for Firefox) is of no use, since if someone can spoof the address bar domain name then they can trivally get a cert to match the spoofed name.
Why not go further and require definitive proof of identity? Arguably this is a) a secondary consideration, b) not necessarily possible in some contexts, and c) overkill for some use cases. Taking these in turn:
Identity of the domain name owner is arguably a secondary consideration, because our primary consideration is ensuring that the "cert owner" (i.e., the entity possessing the private key associated with the cert) is the same as the domain owner, and you don't necessarily need to use identity per se to confirm that. (For example, you could verify that the cert applicant both possesses the private key for the cert and also controls the email account listed in the whois registry as being associated with the administrative contact for the domain.)
Second, as noted previously identity documentation and ways of evaluating it can vary from country to country. It's possible in some cases that verification of identity, and trying to prove "cert owner" = "Foo" and "Foo = domain owner" would be less useful and straightforward than trying to prove "cert owner" = "domain owner" more directly (as in the example above). (Unlike identity, we do have a single global system for domain name registration, however poorly people may feel it works sometimes.)
Finally, proof of identity is arguably overkill for some legitimate and relevant use cases. For example, we've previously discussed the use cases involving IMAP/SSL, SMTP/SSL, etc., where the relying parties (i.e., the people with IMAP/SMTP mail clients) would have a prior relationship with the cert applicant (i.e., the entity running the IMAP or SMTP server) and you wouldn't necessarily need strong identity checking by the CA. If strong identity checking is always required for SSL server certs then it would have to be extended to cover this use case as well (for reasons discussed earlier), and this might negatively impact this use case, by "raising the bar" for operators of IMAP, etc., servers.
Requiring strong identity checks for the IMAP/SSL use case "raises the bar" because it means operators of IMAP/SMTP servers either have to pay more for CA certs to cover the costs of additional identity checking that is arguably not needed for this use case, or they have to operate their own CAs, which is not a trivial task. The net effect is that this discourages the adoption of IMAP/SMTP, etc., over SSL, and thus negatively impacts typical users who might benefit from their email service providers adopting SSL for use with email protocols.
Email certs
Here again the primary threat of interest is phishing, and if CAs and SSL are to protect against email phishing attacks at all then at a minimum there must be some assurance that only the person controlling an email account can get a cert for that account. Otherwise having the user (or the email client) compare the email address in the "From" field and the email address in the certificate is of no use, since if someone can spoof the From field then they can get a cert to match the spoofed from address.
Why not go further and require definitive proof of identity of the person or entity associated with the email account? Because as with SSL server certs this is arguably a secondary consideration, not necessarily possible in some contexts, and overkill for some use cases.
In the Internet identity per se has never been tightly coupled with email accounts and email use. I communicate (every day it seems :-) with entities like "Nelson Bolyard", "Ian G", "Gervase Markham", "Duane", etc., without having ever met them or having the least idea if their real-life identities match their online identities. (Well, I did meet Nelson once IIRC, but I certainly didn't check his drivers license or passport, so I have no idea if I was meeting the real Nelson or a false one.)
As with the IMAP/SSL use case, IMO there are perfectly legitimate and relevant email use cases, like communication among friends, where requiring strong proof of identity would arguably negatively impact typical users in the context of those use cases. (Again, this is because requiring strong identity checks requires potential email cert users to pay more for certs to cover the additional checks, to go outside the CA system -- e.g., by using PGP-style systems -- or to use unsecured email.)
Object signing certs
With object signing certs we are also concerned with the possibility of phishing in the sense of tricking users into installing unwanted and potentially malicious software based on the users' perception that the software is from a known and trusted source. Unfortunately in the object signing case we have no independent mechanism for which the cert is serving as a cross-check (as the SSL cert domain name does for the address bar, and the email cert address does for the From field). The only thing the user has as information is what's in the cert itself.
(I've previously proposed that at least for MF-distributed software we consider providing such an independent mechanism, by tying MF-owned object signing certs to MF-controlled domains. Thus, for example, we might have Firefox accept a MF-signed FF extension for installation only if it has been downloaded from the updates.mozilla.org site. However this is not applicable to object signing in general, at least as practiced today. See also my comments below regarding related proposals.)
Since the user has to rely solely on information in the object signing cert, arguably that information needs to be as correct as possible. At a minimum this means providing strong assurances of the identity of the entity distributing the software (who might not necessarily be the developer of the software).
It's also possible to imagine some CAs going beyond that and issuing object signing certs tied to a particular software object being distributed, e.g., as identified by a SHA-1 hash (or should I say SHA-256 or even 512? :-) (Among other things, this would match practices for SSL certs, where each domain requires its own cert.) Alternatively object signing certs could contain a "authorized download site" list which could be used as an additional check. But this is not general practice today, so policy can't assume it.
That's it for now. I have to go off to my real job now, so can't immediately address the question of actual policy language to implement my suggestions above. But before doing that it's better to get comments anyway, so feel free to comment on my last two messages and the general approach I'm outlining here.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
