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