Nelson B wrote: <snip>
While everyone else has been off having fun conversations (like in bug 286107) I've been distracted by work and family stuff, and (among other things) forgot to respond in more depth to your reply addressing my detailed set of questions to you re your concerns (or potential concerns about the proposed CA cert policy). My apologies, I'll try to remedy that (at least partially) now. (And BTW, thanks for answering the questions!)
I consider a duff cert to be any of the kinds of certs that have caused me (and the NSS group) trouble over the years, including (but not limited to) these:
1. certs with technical flaws, e.g. - duplicate issuer names and serial numbers. - invalid public keys (e.g. DSA cert with 2kbit primes, RSA certs with public exponent == 1). - incorrect extensions (e.g. SSL certs that exclude SSL usage, or authority key IDs that include BOTH the key ID *AND* the issuer's issuer name and serial number. - invalid dates - ASN.1 DER encoding errors.
CAs issuing technically incorrect certs could be addressed by the proposed clause 4 of the policy, allowing rejection/removal of CAs in cases where including their certs would "cause technical problems with the operation of our software." I could even include a list like the above as examples of such problems, although such a list might be more appropriate for an accompanying FAQ.
However "technical correctness" can be a bit of a slippery concept at times; more on this below.
2. Certs with false (and therefore inadequately verified) information about the identify of the party to whom the cert is issued, info that was verifiably false at the time of issuance.
First, determining whether information was "verifiably false", in the sense that a CA should have known better than to issue the cert, is IMO potentially a subjective determination. It's always easier in hindsight to say something was "verifiably false", because we typically have more information now than the CA would have had at the time, or we might be evaluating the truth or falsity of information using means that go beyond what the CA's policy actually calls for.
(To use a contrived example, the CA's policy might determine the name of an applicant based on presentation of a driver's license, but that information was verifiably false, as the CA could have determined if it had bothered to take fingerprints and a DNA sample and match that against a central government-maintained database.)
So I think your test in practice would at least have to be modified to read something like "info that was verifiably false at the time of issuance, based on the means of identification called for in the CA's policies."
Another issue (at least as far as the policy is concerned) is that we can't know in advance whether a CA is going to issue "verifiably false" certs or not, so it's hard to use this as a criteria for evaluating CAs unless the CA has a public track record of problems in that regard. In that case we could use such a history of problems as grounds for denying a CA's application based on clause 4 of the proposed policy, "where we believe that including a CA certificate ... would cause undue risks to users' security". If we happen to approve a CA for inclusion and then they later start having problems, we can use the same clause 4 language was grounds for removing the CA's cert.
3. Certs with NO INFORMATION about the party to whom the cert is issued, except an email address or a domain name, or other info that doesn't identify the party. [see "binary UI security model" below for more on this.]
See my comments below about this case.
4. (recent addition) certs used with phishing, including:
- certs with names confusingly similar to other domains, e.g.
paypal-security.com
- certs with IDN/punycode names that look like well known names
but aren't exactly.
Someone correct me if I'm wrong, but I think we've determined based on prior discussions that CAs are not currently called upon to police instances of misleading names, and cannot necessarily be expected to enforce such rules in the future.
(Among other things, it's perfectly possible that different corporations in different countries might have similar names, e.g., "First National Bank", so, for example, we might have a "firstnationalbank.com" vs. a "firstnationalbank.co.uk" or "firstnationalbank.co.au", with all of these being different entities even though a naive user might take them to be the same entity. In the US we might even have "firstbankofmd.com" vs. "firstbankofca.com" -- not to mention "firstbank.com", which is a real bank with branches in Virginia.)
As a result I am reluctant to have language in the policy calling for rejection or removal of CAs based on this "misleading names" criterion, until/unless the present situation changes.
All these problems were present in the certs at the time they were issued. A CA who does adequate technical validity checking and adequate due diligence about the requestor's credentials will pass all these tests.
I disagree with your point here. Some of these tests are arguably out of scope for CAs, like policing misleading names. Others of your tests lead to possible inconsistencies. For example, let's take the case of a CA issuing "control of domain" certs or "domain-validated certs" (what I called them in my original message), i.e., SSL certs where the CA simply verifies that the cert subscriber controls the domain for which the cert is issued, and does *not* do detailed vetting of subscriber identity. (For example, they don't require that you fax in your driver's license, or your business license, or whatever.)
Should such a CA include information in a "control of domain" cert beyond the domain name itself? If they don't include such information then they fail your test 3 ("duff certs" include "Certs with NO INFORMATION about the party to whom the cert is issued, except an email address or a domain name"). But if the CA does include such information in the cert, then they potentially could fail your test 2 ("duff certs" include "Certs with false (and therefore inadequately verified) information"), since they would be including information (e.g., a contact name from the whois database) that is not explicitly checked as part of the certificate issuance process, and therefore might be "verifiably false".
Similar issues arise with email certs that are issued based on control of the corresponding email account and for which the CA does not require presentation of identity documents. I'll leave as an exercise for readers coming up with "verifiably false" names that cert subscribers might submit as input for the CN in this case.
History: The model has not always been binary. In Netscape Navigator 3, the browser used a key icon that had 3 states: - broken - short, with one tooth - long, with two teeth. Two teeth meant "good enough for banking", and one tooth meant "better than nothing, but not good enough for banking".
A minor correction, but IMO a pertinent one: one tooth actually meant "encrypted using a 40-bit symmetric key" and two teeth meant "encrypted using a 128-bit key". Equating that distinction to "not good enough for banking" vs. "good enough for banking" was an after-the-fact interpretation, an interpretation that was to some extent subjective. And in any case the question of key length was orthogonal to the question of "high assurance" certs vs. "low assurance" certs.
There are a variety of ways that this problem could be solved in the UI. The UI could:
a) go back to a iconic model that has clearly 3 or more states, which are OBVIOUS to users in the chrome of the MAIN WINDOW, without the user needing to click or move the mouse to see the info,
This is the model I proposed in my middle-of-the-night strawman proposal for SSL UI changes. I think the pros and cons of that proposal have been adequately discussed in the relevant thread, so I won't comment further here.
b) go to a model that identifies the CA, and allow the user to decide for him/her self whether the CA is high or low assurance. The CA could be identified by text (a name) and/or a "FavIcon" as web sites are now. The browser could help the user remember his decision, and allow him to change it.
This is the "CA branding" model as proposed by Ian G and others and implemented by Amir Herzberg and Ahmad Gbara in their TrustBar extension (to name but one example). The pros and cons of this have also been discussed elsewhere, so I won't comment further here.
The second method requires the users to grow their awareness of CAs (of which they know nothing today). It also requires more window real-estate. But it keeps MF out of the judgment business, which is a business that MF seems particularly loath to do.
I think you're mischaracterizing the MF position (which is really not the MF's position, at least not yet, but rather mine). I am not averse at all to having the MF make judgements. My position is rather that the judgements have to be based on some reasonable set of criteria that a) can be justified in terms of reducing security risks to users; and b) reflect the reality of how CAs operate today and are likely to operate in the future.
Most of the problems with technically erroneous certs have come from the CAs that are free, mostly users of OpenSSL, many from universities. The CAs with money don't have these problems, not very often.
As I stated above, we're perfectly free to reject/remove CAs that issue "technically erroneous" certs, and I'm happy to have the policy say that more clearly than it already does. I only ask that we have some clear criteria on what sort of things we consider to be "technical errors", and why. In particular, there are possibly certain things which might be invalid according to RFC XYZ but are in practice commonly done, and not just by "OpenSSL CAs"; if so, we'd want to take this into account.
(As one example, do we really want to disallow CAs that use CN for domain name instead of subjectAltName in SSL certs? Would this break existing CAs already in our list?)
In the last month, I have seen certs from one free CA that: - had an invalid key - had NO name but the DNSName, which technically belongs not in the cert subject name, but in the "subject alt name". Had that DNSName been where it belonged, the cert's subject name would have been empty!
As a point of interest, for a "control of domain" cert (as defined above) with the domain name in subjectAltName, what would you want to see in the subject name? Information from the whois entry for the domain? What if that information were "verifiably false" (e.g., the domain was listed as registered to "Mickey Mouse", to use an example from Ram A M)?
Now, I want to summarize this. IMO, it turns out that COST has been the only factor responsible for the apparent success of PKI, having kept the issuers of duff certs out, and having allowed the issuers of good certs in. It wasn't the WebTrust criteria that kept them out, it wasn't the ETSI TS 101, it wasn't nosy auditors, it was cost.
This is a perfectly legitimate argument IMO: Costs artificially imposed by browser vendors (e.g., requiring payments for inclusion, or requiring costly audits) have been barriers of entry to the CA market that had the effect of keeping out potential entrants who were judged inferior in some way (did't know how to issue technically correct certs, didn't follow good practices, etc.).
I think the one hole in the argument is that incumbents in the market are now motivated to offer products like "control of domain" certs that are issued according to less stringent policies. (Because after all commercial CAs are businesses, not charities, and they have to grow the business in order to satisfy shareholders and continue to pay for all those experienced professionals, CA audits, etc.) And this in turn reduces the perceived gap between such incumbents and the other CAs.
Perhaps cost has also kept out some potential issuers of good certs. That is unfortunate. But in the security business, I think we have to err on the side of caution, on the side of security. This isn't "innocent until proven guilty". This is "untrusted until established as trustworthy". The only value that PKI/crypto offers is trustworthiness. If we lose that, we've lost the war.
Existing CAs already issue "control of domain" certificates that don't involve strong identity checking, and IE, Firefox, etc., already "trust" those CAs and certs. So is the war lost, or not?
If you eliminate cost as a barrier, you MUST erect another barrier that will be as good as cost in keeping the duff issuers out (while the binary model remains).
Will Draft 11 keep out an issuer of certs with names empty except for DNS names? Will draft 11 keep out issuers of certs with invalid keys?
If you define "certs with invalid keys" as technical errors then, yes, clause 4 of draft 11 would keep them out.
As for certs with names empty except for DNS names, you have to provide some clarification: Are SSL certs using CN for the domain name a "technical error" for which we should invoke clause 4 to reject the CA? What about SSL certs using subjectAltName for the domain name where the CN value is not separately verified (e.g., it's taken directly from whois data, or as submitted by the subscriber)? Is this a "technical error", or rather a case where for non-technical reasons you believe CAs should not operate using such a policy?
> 1. I suspect that adding the other criteria (X9.79 and ETSI TS 101 456 > and 102 042) is not at issue,
Certainly those criteria are no weaker than WebTrust. Maybe even stronger. But will they keep out issuers of certs with invalid keys, with empty names? with invalid combinations of cert extensions?
Does WebTrust do this? I suspect not. So the bottom line is that the specific set of criteria listed in the proposed policy is not an issue, your issues are with other parts of the policy.
> 2. Permitting "non-traditional" evaluation of CAs is certainly something > that one could imagine increasing risks, if the people doing the > evaluation don't do a good job.
Doing a "good job" has to be defined in such a way that a good job keeps out duff issuers. I'm less worried that a non-traditional evaluator will be dishonest than that he will not know what to look for to keep out the duff. Certainly no financial auditor would.
A minor point, but: Is a "financial auditor" going to be able to discern technical correctness of issued certs, e.g., that subjectAltName should be used in preference to CN, or that certs should not have "authority key IDs that include BOTH the key ID *AND* the issuer's issuer name and serial number"? I think we can rely on CA auditors (e.g., as in the WebTrust for CAs program) to verify that CAs operate in accordance with their policies, and that those policies are in accordance with the relevant criteria, no more and no less.
>> If you do believe that permitting non-traditional evaluations would > increase the risk of "duff certs" being issued, what would you recommend > we do? Tighten the requirements on when we'd allow such evaluations? Or > drop the idea entirely, and require that all evaluations be done by > authorized auditors and test labs?
Well, my first goal is: keep duff cert issuers out.
Now, if we can accomplish that by tighter requirements (and I think that is possible), then that seems very desirable. That would be my first choice.
It would be my first choice as well. But I think the key is separating out cases where you might object to a CA on "technical correctness" grounds vs. cases where you might object to a CA based on their policies. I think criteria for "technical correctness" can be well-specified and applied in a (relatively) non-controversial way, but policy-related criteria are more difficult.
In some of your discussion of "duff certs" I think you are conflating technical correctness issues with policy issues. For example: whether CAs should stuff the domain name into CN vs. subjectAltName is a technical issue. On the other hand, whether CAs should issue "control of domain" certs or not is a policy issue. (And if CAs with such policies are acceptable, and if technical correctness dictates that such CAs put something into CN other than the domain name, then we have the possibility of the resulting cert containing unverified and hence potentially false information.)
If we cannot or are unwilling to take that approach, then yes, I'd advocate continuing to require that all evaluations be done by authorized auditors and test labs. We'd be falling back on the old tried and true method of keeping duff issuers out. But that's not my first choice.
Nor would it be mine either, so let's forget the second choise for now and continue to see if we can make the first choice work.
> 3. Regarding requirements on CA validation of their customers, I > certainly don't have any such requirements in my current "WebTrust or > equivalent" policy, so in that sense the proposed new policy is more > stringent than the old policy.
Somewhat, yes.
> Did Netscape have such requirements?
No, they required $$$$. Ever notice how the supply of PSM developers ended at about the same time as the trusted CA money stopped? Hmmm.
Are you suggesting that the MF charge CAs money and use it to hire PSM developers? :-)
And on that (somewhat discordant) note I have to conclude this reply and go get ready for work. But I hope I've at least addressed the key points in your message.
Frank
-- Frank Hecker [EMAIL PROTECTED] _______________________________________________ mozilla-crypto mailing list [email protected] http://mail.mozilla.org/listinfo/mozilla-crypto
