Eddy Nigg (StartCom Ltd.) wrote, On 2008-06-09 15:23: > Nelson B Bolyard: (quoting Paul Hoffman, quoting Jean Mark Desperrier) >>>> 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? >> >> It is for assuring the certified binding of name and key. When that >> binding has no more assurances, the certificate becomes a false statement of >> assurance. > > For once I must slightly disagree with you, Nelson. (it doesn't happen a > lot though :-) ) > > Responsibilities are shared (at least) or sometimes the full > responsibility of the subscriber. If the subscriber insists on creating > his own key and this is his perfect right, then he bears the > responsibility for it. Most subscriber agreements and CA policies > clearly define that.
It may be reasonable for a CA to assume that the subscriber has taken due care to generate a good key pair at the time that the certificate signing request is received, but at such time as the CA has evidence that the key is compromised (especially public evidence), then there can be no further true assurances for the binding, and the CA is responsible to act, IMO. >>> 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. > > How? There are many ways. One of the most powerful is for someone who has come into possession of the compromised private key to stand in the doorway of the CA, hold up the key copy, and say "See here in my hand, I have the public key for a cert that does not bear my name, a cert issued by this CA. I will give a copy of this key to anyone who wants one." > Shall CAs now be in the business of trying to crack their > subscribers keys? Just because there is now one popular and know flaw > out there? Do you believe it's the only one? For which bugs and flaws > shall the CA look for? Eddy, the issue here is not that CAs don't have omniscient knowledge of all compromised keys. The issue is their responsibility after the guy has waved copies of the compromised keys in their faces, especially if they've identified the certs bearing the compromised keys. >> The keys in question are not "possibly compromised". They are compromised. >> Period. Only the degree to which the compromised key has been exploited >> may be unknown. > All keys are compromised? In this case, the guy held up a bag of ~96 thousand private keys and said "See, here are 96 thousand private keys that I possess. Anyone can have a copy of them." I can't imagine better proof of key compromise than that. > For which possible exploits shall the CA look for? Perhaps you know > exactly for which flaws and bugs should be scanned.... I'd say CAs should not ignore the guy handing out copies of the compromised keys, when he's doing it on their doorstep. >> The keys ARE compromised. A CA who refuses to timely revoke a cert with a >> known compromised key abrogates any public trust. > > Yes, once it's known to the CA it should revoke it immediately. No question. >> 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. > > The banks door locks are excellent, but the key to the safety deposit > box was lost by the customer. Once the customer informs the bank that he > lost his key, the bank will certainly replace the lock of the deposit > box. It doesn't require the customer. If I walk into the bank and say "See here in my hand, a copy of the key for Eddy's deposit box, exactly like the copies that I just gave to all those people in the bank lobby", the bank shouldn't need any more evidence or customer approval before acting. _______________________________________________ dev-tech-crypto mailing list dev-tech-crypto@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-tech-crypto
