If the CPS doesn't define it as "compromised" in that circumstance, then the CA with that CPS has no business being trusted by me.
Yet, I'm never given a choice. Not unless I go through each and every single entry in the root list and apply my own criteria to it. Better, for me, to not have to deal with the fact that someone I never gave fiduciary permission to has taken it upon itself/himself to make fiduciary decisions for me. Better, for me, to have a browser with zero trust anchors embedded. Because then at least I could take it on myself. I'm seriously starting to think that this is something I'll have to sue the Mozilla Foundation over, since it seems to be completely unresponsive to the feedback that I've left over the years. -Kyle H On Tue, Jun 10, 2008 at 1:55 PM, Paul Hoffman <[EMAIL PROTECTED]> wrote: > At 7:50 PM -0700 6/9/08, Nelson B Bolyard wrote: >>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. > > You have conflated two things. We agree on the definition of a key > compromise. Where we disagree is the "and the cert bearing it" part, > which is the only part that the PKI part of Mozilla has control over. > > The certificate is not compromised when the key is *unless the CPS of > the CA says it is*. It doesn't matter what Nelson or Paul thinks: the > CPS trumps all. Otherwise, what is the value of Mozilla spending so > much time evaluating CPSs against our standards? > > Now, it is fine if Mozilla wants to change our standards and say "all > CPSs must have a clause that says that in the case of a key > compromise, the CA will revoke the certificate". That's perfectly > within our rights. > > Saying "they should already be doing that" is bogus. If we wanted to > say that, we could have said it long ago. We didn't. We can now. > > >>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? > > That the named party asserts that they hold unique control over the > private key. That's the way many CPSs are written. Again, if you > don't like that, get Mozilla to change their requirements for > acceptable CPSs. > >>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? > > Typical? > >>Of what value is it? > > Little, of course. > >> > 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. > > Note the "should be". In the real world, it is just one aspect. > Here's a hint: how may of the dozens of CAs that are in the Mozilla > TA pile have acted yet? 50%? 10%? Any? How does your "should be" > stand up to such a low response rate? > >>It's value to subscribers >>is directly a function of the number of relying parties who trust it. > > For some value of "trust". > >>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) > > Yes... > >> and finds few subscribers. > > No. I'm sorry, but I do not see how you can look at the competition > in the CA market and say that perceived value is at all proportionate > to the trust in the CA. It is probably safe to say that fewer than 1% > of Mozilla users even recognize the names of more than 10% of the TAs > in the pile. Saying that they "trust" them is just silly. > > They trust *us* to pick the TAs for them. > >>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. > > Sure. But essentially none of the relying parties in the world have > any level of trust in the vast majority of the TAs in the pile, so > this argument is specious. > >> > 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. > > Kumbaya! Now we are talking about walking the walk, not telling > someone else to do so. > >> >> 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. > > Erm, I said "user". I meant "user". > >>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. > > We agree here. But that's not what I asked. > >>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. > > I am sometimes in that camp, sometimes not. > >>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. > > So far: nothing. No discussion of it in the PKI world. > >>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. > > Have you figured out how many of the TAs in the pile actually have > OCSP responders available? And, of those that do, how many have > revoked any of the certificates that have trivial-to-break keys? > Those numbers would be valuable to make or refute your argument here. > >> > 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. > > Sorry, I don't see it. You keep advocating for CAs to revoke the > certificates. I am advocating for Firefox to fix the problem by > looking for bad keys first, then changing our policies about > acceptable CPSs. > >> > 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. > > We disagre. To me, that means acting on information that we know, > namely that "this cert I'm seeing has a weak key". > >>A fear of enforcing policies (or having weak policies) due to >>fear of lost market share, ultimately undermines trust in PKI. > > ...that has, as you yourself argue, already been mostly undermined. > _______________________________________________ > dev-tech-crypto mailing list > dev-tech-crypto@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-tech-crypto > _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
