[e-lang] RE: [cap-talk] The KeyNote Trust-Management System (fwd)
Karp, Alan H
alan.karp at hp.com
Mon Aug 29 20:46:59 EDT 2005
> -----Original Message-----
> From: Angelos D. Keromytis [mailto:angelos at cs.columbia.edu]
> Sent: Monday, August 29, 2005 5:38 PM
> To: Karp, Alan H
> Subject: Re: [cap-talk] The KeyNote Trust-Management System (fwd)
> Karp, Alan H wrote:
> > Thanks for the pointers. I'm working my way through the
> papers, and I
> > thought it best to ask questions while they are fresh in my mind. I
> > read DisCFS first because I'm most familiar with that
> example. You did
> > things very much like the way e-speak used SPKI certificates.
> > The paper doesn't discuss how the administrator knows
> Alice's public key
> > or how Alice comes to know Bob's. That's not really critical, but
> > sometimes seeing how things bootstrap helps me understand the steady
> > state.
> Admin->Alice happens when Alice first becomes a user of the system.
> Alice to Bob happens independent of the protocol/system (i.e., it's
> Alice's problem).
> > Let's assume that the appropriate public keys are known. There's
> > another way to use this infrastructure that reduces the
> > burden. The administrator creates a one off key pair, creates a new
> > credential for it, and sends the credential and the private
> key to Alice
> > encrypted with Alice's public key. Revoking that private key
> > invalidates the credential, solving one problem.
> > Alice can delegate that authority to Bob by sending him the
> private key
> > and the credential encrypted with Bob's public key. Bob
> now has those
> > authorities. He can submit his request along with this credential
> > signed with the one off private key he got from Alice and
> encrypted with
> > the administrator's public key. No matter how many links in the
> > delegation chain, the server only needs to decrypt one message and
> > verify one signature. The only time the chain of credentials gets
> > longer is when someone wants to delegate a subset of the
> authorities in
> > the credential.
> Except that now you have no accountability: Alice and Bob are
> indistinguishable from the perspective of the system. Furthermore,
> Bob has exactly the same privileges as Alice, since they have the
> same credential and private key. If Alice wants Bob to only have
> access to a subset of her files (e.g., the photos from Bob's party),
> she's out of luck.
Accountability only makes sense if the administrator knows who Bob is.
That's a problem of distributed identity management, something KeyNote
If Alice wants Bob to have only some of her authorities, then she'll
create a new key pair and delegate a new credential with that subset to
Bob. That's why I said the number of checks grows longer only with each
> > I'm concerned about the way the the resource is named. Although you
> > show a small integer, you do state that it needs to be
> globally unique.
> > You don't say how you propose to do that. Simply picking a
> big random
> > number should work, but you often run into collisions.
> (UDDI has found
> > GUID collisions when merging private repositories, and one big
> > supercomputer cluster wouldn't come up because two Ethernet
> cards had
> > the same MAC address.) You could use the public or private key of a
> > pair, but that's pretty computationally expensive. I think
> one way to
> > provide unique handles is to make the handle a use once
> counting integer
> > and make the administrator's public key the uniquifier. The
> > administrator will need a different key pair for each file
> system, but
> > that's not a big deal.
> It needs to be unique for the specific file server; admin
> public key +
> integer is a good way of doing this.
As long as the admin remembers to use a different public key for each
Virus Safe Computing Initiative
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Size: 433 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/e-lang/attachments/20050829/2a2daff1/KarpAlanH.vcf
More information about the e-lang