Re: Certificate proposal
At 10:04 AM 10/9/95 EDT, Carl Ellison <cme@TIS.COM> wrote:
I don't understand this whole discussion. A certificate is a signed binding of a key and a unique name, right? It depends on how you define certificate. If you define it this way, then I'm proposing the elimination of certificates (because I'm eliminating the unique name as something different from a key).
If you define certificate as I do -- as a bound statement of some attribute of a key, then it should become clearer. It's just that the attribute I'm binding is not some unique person-name -- rather something like permission to spend money from a bank account.
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. #--- # Thanks; Bill # Bill Stewart, Freelance Information Architect, stewarts@ix.netcom.com # Phone +1-510-247-0664 Pager/Voicemail 1-408-787-1281 #---
Bill Stewart <stewarts@ix.netcom.com> writes:
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? Hal
hfinney@shell.portal.com writes:
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?
If we exchange keys on a face-to-face basis, then I really don't see much of a MITM threat, unless somehow the MITM has perverted my original key and I for some reason can't figure that out. Now, as long as you communicate with me via the public key I've handed you, we should be as safe as PKE can make us. If we are forced to exchange keys remotely, then perhaps some sort of "proof" techniques could be used to establish to some level of assurance that the remote entity I *think* is you is really you. Or you could provide me with a key, and then I could poll a list of references to inquire as to the "goodness" of the key. This seems to me to be subtly different than a certificate procedure, because I'm not asking about the goodness of a relationship to the key, but rather about the key itself. Maybe I'm missing something. What is there to trust in a more "traditional" certificate scheme? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 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 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
hfinney@shell.portal.com writes:
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?
If we exchange keys on a face-to-face basis, then I really don't see much of a MITM threat, unless somehow the MITM has perverted my original key and I for some reason can't figure that out. Now, as long as you communicate with me via the public key I've handed you, we should be as safe as PKE can make us.
Ah, but you're being sucked in by the True Name game. Suppose the Medussa in the middle is the one who meets you. What is he/she going to do, whip out a passport that says "Pr0duct Cypher" across it? The only way to prevent that is if the nym has a public identity, and a way to prove a link to that identity. The only reason to meet in person is to verify a True Name[tm]. If I want people to know that I trust Pr0duct Cypher, I can encrypt my signature to the PC key with PC"s public key, that I already know is his because that's what he sends out with his source code. The information is only useful to the holder of the key, that being PC. I am, though, relying on the MITM to not be all-powerful. Mitch in the Middle could have intercepted all Pr0duct Cypher messages and put in his/her own key. As long as the real PC is unaware of the fake PC, or is unable to raise the alarm, there is NOOO way of detecting PC having been isolated by Mitch. As I said, what are you going to ask for, besides something relating to a key published along with reputation-building material.
If we are forced to exchange keys remotely, then perhaps some sort of "proof" techniques could be used to establish to some level of assurance that the remote entity I *think* is you is really you. Or
So who is Pr0duct Cypher then? And why should I have to produce ID saying my name is Don, unless I'm proving my Real Name[tm] is Don.
you could provide me with a key, and then I could poll a list of references to inquire as to the "goodness" of the key. This seems to
But there's no way to prove that there's no MITM. But "middle" is a subjective term. If Mitch has become sophisticated enough to meet in person with a magic ID, and write cryptocode on the spot, I'm no longer dealing with Medussa In the Middle, I'm dealing with someone pretending to agreeing with me, when really they are opposed to my beliefs.
me to be subtly different than a certificate procedure, because I'm not asking about the goodness of a relationship to the key, but rather about the key itself.
Maybe I'm missing something. What is there to trust in a more "traditional" certificate scheme?
Don
Don M. Kitchen writes:
If we are forced to exchange keys remotely, then perhaps some sort of "proof" techniques could be used to establish to some level of assurance that the remote entity I *think* is you is really you. Or
So who is Pr0duct Cypher then? And why should I have to produce ID saying my name is Don, unless I'm proving my Real Name[tm] is Don.
Right. If we're forced to exchange keys remotely, I just have to deal with the possibility that I'm being spoofed.
you could provide me with a key, and then I could poll a list of references to inquire as to the "goodness" of the key. This seems to
But there's no way to prove that there's no MITM. But "middle" is a subjective term.
Yes, that's why I put "proof" in quotes. I guess I meant "demonstrate to a personally sufficient level of satisfaction". ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ | 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 | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Mike McNally <m5@dev.tivoli.com> writes:
Don M. Kitchen writes:
If we are forced to exchange keys remotely, then perhaps some sort of "proof" techniques could be used to establish to some level of assurance that the remote entity I *think* is you is really you. Or
So who is Pr0duct Cypher then? And why should I have to produce ID saying my name is Don, unless I'm proving my Real Name[tm] is Don.
Right. If we're forced to exchange keys remotely, I just have to deal with the possibility that I'm being spoofed.
You could take out a personal ad in a newspaper and print this: 9D AF 6D 4D 8E 64 43 FC D5 CB 9C 7A 36 C7 6D B9 (Pr0duct Cypher's key fingerprint). That would mean that you could at least help Pr0duct Cypher determine if there was a man in the middle. If there was a MITM, once Pr0duct was aware of this, P.C. could make efforts to change service provider, or find novel entry points into public internet forums, and different entry points in to the remailer net. For the other direction, as a nym, if newspapers accepted anonymous personal ads, an ad posted from a large city postal mail to the newspaper, would be a reasonable assurance that the identity of the person would be unkown. Or you could try paper mailing some one your instructions with cash to pay for the advert. It is likely that a randomly picked cypherpunk would do this for a nym. You could even take out two simultaneous ads in two independent newspapers which were secret split in two with XOR and a random number, if you were really paranoid. Now the MITM is reduced to denial of service attacks, by posting similar keys, and saying "no that nym is an imposter I'm the real nym". Denial of service is preferable to a MITM. Adam
participants (5)
-
aba＠dcs.exeter.ac.uk -
Bill Stewart -
Don M. Kitchen -
Hal -
m5＠dev.tivoli.com