At 2:56 PM -0700 6/9/08, Nelson B Bolyard wrote: >Paul Hoffman wrote, On 2008-06-09 09:41: >> At 11:22 AM +0200 6/9/08, Jean-Marc Desperrier wrote: > >>> Aren't the people who send their credit card number on an https >>> connexion where the private key of the server is public knowledge >>> already screwed ? >> >> Yes, of course. The question for this thread is: who is responsible >> for each screwedness? > >I beg to differ. The question is: for what is the CA responsible?
That's not much of a question, because it is answered in each CPS. Mozilla has reviewed each CPS. >It is for assuring the certified binding of name and key. Fully agree. >When that >binding has no more assurances, the certificate becomes a false statement of >assurance. If that's what the CPS says, sure. But if the CPS doesn't say that, then no. > > However, given that a CA cannot know whether or not a domain has been >> compromised, > >A CA can know that a key has been compromised. Whether an actual >exploit of that compromise exists for any user at any specific time >may be unknowable, but is not the only factor in determining the CA's >responsibility to the relying parties. Fully agree, if the CPS lists more responsibilities (I have only read a few, but all of those did). > > 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. >Only the degree to which the compromised key has been exploited >may be unknown. Of course. >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. b) Does revoking a certificate inform a relying party of anything significant? For better or worse, revocation is a giant one-bit club. c) What responsibilities does a CA have to relying parties? I have never signed a contract with any of them. 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. > >> Isn't the entity the users trust when they see a certificate foremost >>> the CA that emitted it ? >> >> Yes. That trust hasn't been broken, unless the CA said to the users >> "and we will revoke the certificate if we suspect that the key could >> likely be compromised". > >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? > > They keys are not "broken", they are "trivial to break if an attacker >> wants to". > >They are compromised. There is no reason to believe that only the named >subject holds the corresponding private key, (since I also hold it :). Understood. > > That's an important difference, and one that needs to be >> made in any warning we give to a user. > >It's the difference between "Your drawer in the bank vault has been robbed" >and "the bank vault door lock is now broken and the door is wide open". >Both situations demand action. Yeah, right. Trust in SSL certificates is like a "bank vault". Not in this universe. 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? Why rely on the CAs, who have repeatedly shown themselves to be half-hearted at best? _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
