[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Any more comments ...
At 4:56 AM 4/25/96 -0400, Carl Ellison wrote:
>At 03:24 PM 4/24/96 -0700, Bill Frantz wrote:
>>It seems to me that there are two uses for certificates. I suspect we want
>>to support both of them.
>>
>>(1) Certificates as Capabilities. In this use, I would expect that the
>>entity (person or program) who wanted to exercise some capability would
>>pass the certificate giving it the authority along with the request to
>>exercise that authority. There would be no need for directory lookups
>>except those needed by the entity to organize the certificates it had been
>>given. In addition to having several certificates, the entity might also
>>have several key-pairs, where only it knows that they represent the same
>>entity.
>
>Yes -- this sounds like a good summary.
>
>>(2) Certificates as Identity Attributes. This is basically the X.500/X.509
>>directory lookup problem. You have some kind of unique name for an entity
>>and want to get a public key. Or perhaps you have some kind of attribute
>>and want to fetch the certificates which contain that attribute. This use
>>of certificates can use third-party signers, to validate the data, and
>>perhaps some standards about the attributes (or unique name) to make
>>searching system usable. (N.B. A unique name is an attribute which is
>>guaranteed to be included in only one certificate in this model.)
>
>One of the things I am trying to point out is that case (2) is a subset of
>case (1). That is, the Meaning of a case (1) Capability cert can be "I
>attest to this key's belonging to the person I know as Carl M. Ellison".
>
>...
>
>However, you appear to see (2) as significantly different from (1). I would
>like to know in what way they are different for you.
I must be engaged in my bad habit of not making myself clear. I do not see
a fundamental difference, except in the historical path of their invention.
The only reason I can think to look up a certificate by "true name" is
because I want to send an encrypted message to that "true name". For
example: Suppose I find that a Carl Ellison, from CyberCash is going to be
in the SF Bay area and I want to invite him to a surprise party for my
wife. I want to send him an encrypted message because I don't want my wife
to accidentally come across the message and ruin the surprise. For this
purpose, I would be quite happy with a name=="Carl Ellison" key signed by
CyberCash. If there were two "Carl Ellison's at CyberCash, I would try
using information in Carl's web page to determine which key was his. Or
else I would send the invitation to both Carl Ellisons and ask them to get
it to the correct person.
>Following up my previous message --
>
>when the (name,key) advocates speak, they usually wave their hands about the
>usefulness of those names. Some speak of ACLs [Access Control Lists],
>sithout going into any details on how those lists are managed securely.
I have said before, I consider using ACLs for protection in computer
systems to be dangerous. This is because of the fundamental fact that
people are not actors in computer systems, only programs are. Programs
have different loyalties than people. One simple example is copy
protection. Another is a Trojan horse.
Now for people to use computer systems, they must have a proxy program they
trust. It is quite reasonable for that proxy to use some form of "real
person" identification to make sure that it is not abusing that trust by
accepting orders from another person or program. Otherwise authority
should be mediated by capabilities.
Regards - Bill
------------------------------------------------------------------------
Bill Frantz | The CDA means | Periwinkle -- Computer Consulting
(408)356-8506 | lost jobs and | 16345 Englewood Ave.
frantz@netcom.com | dead teenagers | Los Gatos, CA 95032, USA