At 11:22 AM +0200 6/9/08, Jean-Marc Desperrier wrote: >Paul Hoffman wrote: >> [...] >> Sure, but that's not the model most CAs have with their customers. I >> would bet that if a CA sent out a message saying "we're revoking your >> cert tomorrow, here's a new one" to all of its affected customers, fewer >> than 95% would have the new cert installed correctly. The remainder >> would be screwed, and the customer support lines (and I use that term >> very loosely) would be jammed. > >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 assert that the end users with credit cards are screwed by the domain that has had its key compromised, particularly if the CA has tried to contact the domain. I assert that if the CA preemptively revokes a certificate, the domain is screwed by the CA. However, given that a CA cannot know whether or not a domain has been compromised, a CA that tries to save the customer by revoking the possibly-compromised domain's keys is overstepping its responsibility. The public key is still associated with the domain; it might be associated with Mallory as well, but that's unknown. If it becomes known to the CA that the key has been compromised, the CA's CPS might (cough cough) give it guidance about whether or not the CA can revoke the key without the domain asking. > > A better mechanism would be for the CAs to send out repeated letters >> saying that the keys are probably compromised and the certified party >> really really really should do an update. If they don't, it is now the >> responsibility of the certified party. > >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". There may be CPSs that say that; I haven't studied them enough to know which do and which don't. >What conclusion should they reach if it's OK >with that party if their connexion is not secure ? No conclusion at all. >The argument against revocating all those certs I would think of as >strong is more that it would break the CRL system. >If there are tens of thousands of certs to revoke (and there's all >reasons to think it's in that size range), the CRL become simply >unmanageable at every level. Users would take ages to download and >process it, and the providing site could no more handle the load. See .gov and .mil. >But if, as suggested, Firefox gets a list of the broken public keys, and >reject them directly, it solves that problem. They keys are not "broken", they are "trivial to break if an attacker wants to". That's an important difference, and one that needs to be made in any warning we give to a user. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
