From: Bill Stewart <stewarts@ix.netcom.com>
Date: Tue, 10 Oct 95 00:22:09 PDT
To: Hal <hfinney@shell.portal.com>
Subject: Re: Certificate proposal
Message-ID: <199510100721.AAA20956@ix.ix.netcom.com>
MIME-Version: 1.0
Content-Type: text/plain


At 09:46 AM 10/9/95 -0700, Hal wrote:
>>This doesn't necessarily eliminate certificates - while you have a signed
>>statement from Alice's key that she uses Bank Account X, and a signed
statement
>>from Alice's key authorizing transfer of $D from Bank Account X to Bank
>>Account Y,
>>the Bank, or a customer, may refuse to accept the request unless there's 
>>a signed statement from the Bank's key that Alice's key uses Account X.
>>None of these need Alice's name, or for that matter the Bank's, as long as
>>there's
>>also a signed attribute statement from the Bank's key that it's a bank, etc. 
>>The meaning of the certificates changes a bit, but there's still a certificate
>>from the bank binding Alice's Key to Alice's Bank Account.
>
>I can see using keys with attributes in this way, for credentials or as
>other forms of authorization.  But what about for communications privacy?
>What is the attribute that tells you that using this key will prevent
>eavesdropping?

What I was trying to get at with this post was that the assertion that key-
centered communications probably won't require certificates is incorrect.

As far as privacy goes, this set of keys and certifications lets you create
private communications (using signed DH, etc.) with the entity that owns
the private key for Bank Account X.  No, you don't know if that entity
is really Alice or really MITM; in fact you don't know Alice's name, if it's
done right.  You just know that the Bank says it will honor requests for money
from Bank Account X (assuming you know where to find the Bank, which is a
separate
but similar problem.)  So assuming you're selling politically correct
widgets and not
pharmaceuticals or financial privacy consulting services, you probably don't
care too much about who's on the other end - the person who's giving you
the money is the person you want to be talking to.

I'm not trying to define away the MITM problem - I think there _are_ times you
want to know for sure who you're talking to - but I think there are also a lot
of times that you really don't care, as long as you have continuity and
access to reputations of long-persisting identities, where the key is often
enough identification.

In the case of the Bank, the reason you trust the Bank isn't that you know
them physically (though it was interesting when I started dealing with a
local bank where the tellers knew me by name after only two or three visits);
knowing your local Savings and Loan by name doesn't guarantee you can get any
money out of them if there's a bank run, nor does it really guarantee that they
won't embezzle the funds and head for Argentina.  The reason you trust them
is that they (in this case the "they" identified by their key) are doing
business
dealings with a lot of people and it's more profitable not to abscond.
And the reason you know it's really the Bank and not MITM is that they've
always identified themselves by their key from the beginning.
Just like the credit card who's owner we've been calling Alice has.
And because you've successfully withdrawn money from the Bank before,
and because you're clearing Alice's credit card transaction reasonably promptly.

Checks and credit cards are especially good examples for this - the current
systems need your name on them, because your name and signature are the
closest they have to an authentication system.  However, with digital
signatures,
the fact that you can sign a document verifiable by the public key is
all the authentication that's needed; your name isn't.  If the card has an
account number for convenience, and Alice substitutes Carol's account number
for hers on a statement, her signature won't match the public key the bank
wants on the request, and it'll bounce.  (In this case, the certificate
from the bank would probably include the account number as well as the key,
but it's not critical for on-line systems, just more efficient.)
#---
#                                       Thanks;  Bill
# Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com
# Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281
#---