[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Private keys and the emperor's clothes -Reply
>>> "Brian M. Thomas" <bt0008@entropy.sbc.com> 06/21/96 03:01pm >>>
>Bob:
>I think that all of your arguments are valid, and right on the money. However,
there are two things that may put a little different spin on them.
Thanks, Brian. In part, that message represented sort of an epiphany for me, for I confess that
prior to coming to Novell and being immersed in a client/server culture for the first time, I might
have tended to favor the personal workstation view of the world as well.
>First, the CA may be regulated and contractually obligated and all
kinds of neat stuff, and I may have legal recourse if he misbehaves,
but in the final analysis I don't have actual control over his
behavior; I do over mine. Laws mean little to terrorists, or spies, or
criminals. If it's important enough to me, I will do all of the
necessary things that you mention in generating my keypair; if not, I
don't care what the CA does, as you say. But I get to say, not someone
else, however legally bound they may be. My real objection to
government key escrow was not primarily distrust for government, but
the dependence on unreliable, deceivable, bribeable humans for the
final layer of security.
Excellent point, and I completely agree with you. Unreliable, deceivable, bribeable, bored clerks are
always going to be a problem, in any such arrangement. But whereas a bank or privately owned CA
would be forced to make restitution if they screw up, my concern is that the Government would claim
sovereign immunity and let the whole matter drop with a Waco/Ruby Ridge-like "Oops, sorry 'bout that,"
leaving the user twisting slowly, slowly in the wind.
>Second, the CA's reliability and trustworthiness seems to me to affect
primarily the relying party, who has choices as to whether or not to
trust a particular CA. Just because I choose to go with Joe Bob's
Discount CA and Shoe Shine Parlor (Steve Kent put me on to him:->)
because he's cheap doesn't mean that anyone in his right mind will
trust his certifications. This was partly your point, I believe, but
it points out that in a properly run infrastructure, a CA can't really
do this kind of damage to a subscriber, only to a relying party, or
ultimately to himself, because the spoofed party can always present the
duplicate certificate as proof of the CA's unreliability, and he's up
the river or at minimum out some bucks for breach of contract, depending
on the legal arrangements.
Well, now, let's think about that. Out of the blue I get sued by someone who claims to have my
digital signature on a document, with a certificate signed by a CA I never heard of. I claim,
"That isn't my signature, nor my certificate, and in fact I never heard of this purported CA."
The CA rejoins, "Unfortunately, we had a fire which destroyed the written copy of the
acknowledgment you signed when you accepted the certificate, but we insist that you
did in fact request and were issued a certificate signed by us that contained that public key.
The fact that you have a certificate from another CA proves nothing, for we don't have a
rigid naming hierarchy or monopoly to impose a discipline as to which CA you can request a certificate from.
You merely got two certificates from two different CAs with the same subscriber's name, and
because we decided not to make use of a global X.500 directory, such behavior was even not detectable,
much less prohibited. Besides, you said that you were concerned about your privacy, and therefore you
requested that we not publish your certificate in any directory. Instead, you would distribute your
certificate by e-mail to the user's you wanted to have it. We were just following your request, and if it
weren't for that darned fire we would be able to prove it. Now, how much did you say you were willing to
spend in legal fees trying to prove that we are wrong? And by the way, do you like your kneecaps they
way they are now, or would you like us to rearrange them for you?"
Of course that only addresses the issue of digital signature validation. If someone else posts an invalid certificate
and someone diverts your mail, they can read information which only you were supposed to be able to read, and you
never even know that you missed it. Or, having read it, they could forward the signed copy on to you, encrypted in
your public key, and you would still be none the wiser.
(Maybe there is a moral here for e-mail protocol designers. Perhaps both the name and address of the recipient,
together with the certificate information (issuer and serial number), should be included in the signed portion of the
message, so that this kind of man in the middle attack could be detected.)
>I feel that for those reasons it is still highly preferable to have keys
generated by the owner, and of course, best of all in hardware, and you
are the first I've seen to mention the problem of controlling what got
presented to a hardware crypto engine to be signed.
Best of all in hardware controlled by the user. I'm reasonably security conscious, but "pond scum"
would probably be a reasonable representation of my own home computer security environment,
and would almost surely be applicable to the vast majority of unsuspecting users of this brave
new world of technology.
>Brian Thomas - Distributed Systems Architect bt0008@entropy.sbc.com
Southwestern Bell bthomas@cdmnet.com(or primary.net)
One Bell Center, Room 23Q1 Tel: 314 235 3141
St. Louis, MO 63101 Fax: 314 331 2755
Bob