[e-lang] RE: [cap-talk] The KeyNote Trust-Management System (fwd)

[Karp, Alan H]

> -----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 
> computational
> > 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
nicely avoids.  

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
subsetting. 
> 
> > 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
file system.

> -Angelos
> 

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Karp, Alan H.vcf
Type: text/x-vcard
Size: 433 bytes
Desc: Karp, Alan H.vcf
Url : http://www.eros-os.org/pipermail/e-lang/attachments/20050829/2a2daff1/KarpAlanH.vcf