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 #---