[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: bootstrap of key-centric binding of person to key
good to hear from you.
At 17:40 3/4/96, Mark S Feldman wrote:
>Would not the same applet have trouble holding a persistent
>certificate? If an applet doesn't want to be smart, it can require
>both cert & CRL and toss both if either expires. It's a virtual
>"short-validity cert model" without having to deal both with CRLs and
The CRL is potentially large and a second signed object to check. A
short-life cert is a single thing to check and requires no search.
The two methods [with CRL or without] are precisely equivalent, in terms of
meaning, but differ in performance depending on the behavior of the
validating application. I plan to write this up more formally, shortly.
>> After enough
>> messages, that key is now charged and can lend impression [knowledge,
>> reputation, trust] to other messages signed with it. That is, all the key
>> does is link together messages from the same source and let those messages
>> influence the way I interpret other messages from the same source.
>Without some sort of out of band check, either directly (face to face
>meeting) or indirectly (certification hierarchy), there is no
>verifiable binding. Let's take your USENET news example. Let's say
>that your site receives its news feed from my site. I can edit and
>place signatures on any articles. I might set up software to
>automatically add a signature or replace an existing signature on any
>article from firstname.lastname@example.org. Then, after a while, you would
>believe messages so signed to be from email@example.com. I could
>then substitute my own thoughts and sign them so you would believe
>that they were Frank's, and more strongly than if nothing were ever
In other words, you can become a plagiarist. If you do it on a USENET
newsgroup, then I'm going to see my words under someone else's signature
and get a bit upset. You might not be forced to admit your transgression,
but you can't get away with it undetected -- not for long.
>> There is no difference between that process and what happens in real life,
>> when you first meet someone and carry that first conversation through to an
>The difference is that in real face to face meeting you can usually
>see the person's lips moving and know that the sound you're hearing is
>authentic. The electronic exchange does not convey as much.
That person whose mouth is moving could be a plagiarist. The word was
invented before digital communication.
What you can not do is attribute words to my key which were not mine.
Meanwhile, if the channel between us is encrypted after being signed, you
can't achieve your plagiarism. If the source material is in the clear,
however, it's wide open for you to copy and attach your own name to.
That's always been true -- but thanks for pointing this out again. It has
nothing to do with identity-certificates. A clear-signed message signed by
a key with an identity certificate can still provide fodder for plagiarism.
This suggests that all communications should be encrypted from point of
origin. I don't know yet how to do newsgroups that way, but it's an
>> The real issue is how keys get injected into the system in the first place.
>> For USENET News or e-mail, the method is clear [as outlined above]. For
>> things in which authority is being granted, then the source of that
>> authority generates a certificate granting the authority.
>It's not authority, it's identity. You or someone must know who I am
>before I am granted any authority. And that identity must not be
>spoofable, else the authority is also spoofable.
That's the beauty of key-centric identity. The act of signing a message is
like an interactive proof. In this case, you are proving that you have
access to a private key.
All mechanisms of using digital signatures, whether identity-certificate
based or key-centric, must assume that the owner of the private key is the
only one capable of exercising it. If that assumption is relaxed, then the
whole mechanism becomes meaningless. Therefore, we must assume that a
private key is well controlled and in the hands of only one person.
Once you have that assumption, then the key-centric approach binds a key to
one person far more strongly than any identity-certificate. So, it solves
the identity binding -- only not in ways related to a person's given name.
As long as what gets attached to that key [e.g., permission to open a door,
security clearance, ...] is attached directly to it through an attribute
certificate, one never needs to deal with an identity-certificate. If the
people who "meet" that one person, meet him/her only digitally, then that
key becomes the best means of identifying the person. The given name
becomes a minor item -- to be ignored, if the communicating parties wish to
|Carl M. Ellison firstname.lastname@example.org http://www.clark.net/pub/cme |
|CyberCash, Inc., Suite 430 http://www.cybercash.com/ |
|2100 Reston Parkway PGP 2.6.2: 61E2DE7FCB9D7984E9C8048BA63221A2 |
|Reston, VA 22091 Tel: (703) 620-4200 |