Paul Hoffman wrote, On 2008-06-09 18:31 PDT: > At 2:56 PM -0700 6/9/08, Nelson B Bolyard wrote:
>>> a CA that tries to save the customer by revoking the possibly-compromised >>> domain's keys is overstepping its responsibility. >> >> The keys in question are not "possibly compromised". They are compromised. >> Period. > > Until we see any evidence of this in the real world, we disagree. I think we have different definitions of compromised. I define it as: when the named party no longer has exclusive control over the corresponding private key, then the public key (and the cert bearing it) is compromised. The relying parties then have only false assurances of the bindings. >> A CA who informs it relying parties that it can no longer assure the binding >> that it once certified is fulfilling its responsibility, not exceeding it. > > a) Let's be careful with our assertions. The CA can still assure the > binding of the name to the public key; what they can't assure is the > unique control over the private key. I claim that the binding of a name to a public key REQUIRES that the named party holds unique control over the private key. What other definition is meaningful? What good is it to assert that "When you encrypt with this public key, you can be confident that the decryption will be performed by the party named in this cert OR any of millions of others." ? What kind of "binding" is that? Of what value is it? Similarly, what good is it to assert that "When you verify a signature with this public key, you can be confident that the signature was generated by the party named in this cert OR any of millions of others." ? What kind of "binding" is that? Of what value is it? > b) Does revoking a certificate inform a relying party of anything > significant? For better or worse, revocation is a giant one-bit club. Yes, it causes relying parties to stop relying on the no-longer assured binding (if their software recognizes the revocation, which FF3 does, and FF2 can if enabled). > c) What responsibilities does a CA have to relying parties? I have > never signed a contract with any of them. A CA's responsibility to offer REAL assurances to its relying parties should be motivated by its own self interest. It's value to subscribers is directly a function of the number of relying parties who trust it. Analogous to broadcasters who measure the value of their airtime to advertisers by the number of "eyeballs" that watch their content. A CA who is not trusted (by virtue of not being in popular products) offers little value (in some markets) and finds few subscribers. Relying parties who find they can no longer trust the certified bindings of a certain CA stop trusting that CA. A CA whose base of relying parties is diminishing is a CA in decline. > To be frank, browser vendors have more responsibilities to relying > parties than CAs do. That's why the browser vendors carefully check CPSs > and enforce rules about them. Agreed, and part of the discussion here is: is it acceptable to Mozilla to continue to "trust" certs from CAs who don't revoke timely in the presence of evidence? I hope not. Such CAs provide only "security theater", IMO. >> The keys ARE compromised. A CA who refuses to timely revoke a cert with a >> known compromised key abrogates any public trust. > > "Any"? Do you really think that a typical Firefox user, even when > this is all explained to them, would be as strident as you are here? Actually, I think most of them already ARE more strident about this than I am. There is already HUGE distrust of CAs among the Mozilla community, especially developers. For a decade now there have been ongoing calls for Mozilla to ship a browser with an empty trusted CA list. There are STILL calls for removing Verisign certs from the trust list because of the issuance of some bogus Microsoft certs some years ago. The number one impediment to the acceptance of EV by the Mozilla community was that it was initially promoted by the very CA they most despised. There are repeated calls for Mozilla to adopt an SSH-like KCM strategy of "trust and store any cert, regardless of issuer, on first sight (if there is not already a cert stored and trusted for that host name), and complain when any host offers a cert different than that offered in the past." That is the number one most frequently repeated request in Mozilla mailing lists (private and public), newsgroups and bugs for years and years now. There is a significant percentage of Mozilla leaders who are sympathetic to that view. Many of them subscribe fully to the view that certs from any OpenSSL user are just as trustworthy as certs from any institutional CA. Of course, the Achilles-heel of KCM is absent revocation. The recent Debian debacle has resulted in the creation of a 3 MB (compressed) key revocation list (KRL) that people now propose to carry forward in perpetuity in all software. That monstrosity offers CAs an opportunity to demonstrate some real differentiation and value here, the value of revocation, something that KCM will never offer. I believe the 3MB KRL that resulted from the Debian debacle is the stake that the PKI community can finally drive through the heart of KCM, if it has the will to do so. CAs can use this as an opportunity to say "Users of PKI with our certs don't need to carry around 3MB Key revocation lists. They don't need new software. They just use the OCSP revocation that is already built in to FF3 and IE7, and they're covered, because the CAs will do a competent job of revocation for them." That's real value that any Debian user can see. Any CA who, in light of this opportunity, chooses to demonstrate a desire to "put his best foot forward" and "save face" for himself and his subscribers, rather than showing his commitment to proactive revocation, discredits himself (and perhaps the whole PKI community) to the people who most want to see PKI fail and be supplanted by KCM in Mozilla products. > But, if you feel that way, why don't you get the people who the > relying parties trust most, the browser vendors, to fix the problem? That's actually what motivates me to participate in this thread. > Why rely on the CAs, who have repeatedly shown themselves to be > half-hearted at best? The browser vendors can fix the problem by really enforcing trusted cert policies that really protect their users. That means putting pressure on CAs. A fear of enforcing policies (or having weak policies) due to fear of lost market share, ultimately undermines trust in PKI. Regards, /Nelson B _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
