From: m5@dev.tivoli.com (Mike McNally)
Date: Mon, 9 Oct 95 14:47:55 PDT
To: Hal <hfinney@shell.portal.com>
Subject: Re: Certificate proposal
In-Reply-To: <ac9ea8f3010210049f44@[205.199.118.202]>
Message-ID: <9510092146.AA28192@alpha>
MIME-Version: 1.0
Content-Type: text/plain



hfinney@shell.portal.com writes:
 > >3) You can set up some sorts of communications tests to "probe" for a
 > >MITM situation, perhaps by passing through "seeded" information (data
 > >taggants?).
 > 
 > I will agree that there are alternatives to certificates.  

I'm a little confused, I guess.  What is it about certificates that
you'll trust with such confidence?  How do you know that the guarantor
of a certificate wasn't spoofed by an MITM attack?  How do you know
that the certificate itself wasn't spoofed?

 > >I don't think it is irrelevant, I just think it's orthogonal to the
 > >issue of whether a certificate for a key<-->entity relationship is
 > >considered to be the key or an adjunct to the key.  I could be wrong,
 > >of course.
 > 
 > The POV I am really arguing against is the one that defines identity to
 > be a key, that states that in communicating with a key you are by
 > definition communicating with the person you have in mind.  The man in
 > the middle attack does not exist because from your point of view the
 > entity at the other end of the communication channel is just the MITM
 > plus the person you think you are talking to.  

I think it's more correct to say that the MITM attack is acknowledged
to be possible, but realistically no more of a threat than in a
certificate model.   And note the "I think", and this warning that I
could be wrong.  (Or I could be an MITM...  bwahahahaha!)

 >                                                    This idea has been
 > expressed many times by other people in this discussion, and it is this
 > which I think is fundamentally flawed and even dangerous because it
 > encourages the use of untested keys.  In fact it seems to define away
 > the question of whether a key is real or fake.

Oh now wait a sec here; I don't think anybody's advocated using
"untested" keys.  It's still perfectly reasonable to establish
networks of reliable information focused on a key.

If I electronically "encounter" Alice and decide to begin a secure
conversation, we initiate a key exchange.  I can then go to as many
already-trusted entities as I like in an attempt to verify that as
many attributes that are claimed to be associated with the key are
really there as I desire.  If Alice wants to buy a widget from me, I
can ask other businesses whether they've ever had problems collecting
from that key.  If I want to buy a widget from Alice, I can ask
friends whether they've gotten good widget from that key.  If I'm
interested in a little e-hanky-panky, I can ask around the sleazier
corners of the net to see whether Alice is the kiss-and-post type.

Somebody's going to have to explain to my thick skull how it is that a
certificate system makes this process any different, fundamentally.  I
mean, it may be that there's more superficial security, but I don't
see where there's any additional risk truly introduced by using the
key itself as a "True Name".  Maybe the real question is, how does a
certificate system give me the confidence that there really is an
"Alice" according to some definition of "really" that satisfies me?

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
| Nobody's going to listen to you if you just | Mike McNally (m5@tivoli.com) |
| stand there and flap your arms like a fish. | Tivoli Systems, Austin TX    |
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~