Re: [Jsdsi-users] ACL and AuthCert
Status: Pre-Alpha
Brought to you by:
sajma
From: Sameer A. <aj...@gm...> - 2004-08-26 16:52:09
|
Dav, You're on the right track. But unfortunately, JSDSI has not integrated AclEntries into its Prover process. But you can hack a basic version of this yourself: The AclEntry contains the "root of trust", e.g., it might have an entry that states that Alice has read access to the webcam and can propagate that access. Alice is the subject of that entry. Alice can then grant access to her family using an AuthCert. Alice is the issuer of this cert, and the subject is a name "Family" (the cert has probably no propagate bit). Presumably, Alice has also issued NameCerts that define which principals belong to the group named "Family". (all these AuthCerts and NameCerts are in your CertStore) When Bobby (Alice's brother) attempts to access the webcam, the access controller (a process) attempts to prove an AuthCert that starts from the principals in the Acl entries and ends with Bobby. Here's a simple hack to make this work: For each AclEntry, create an AuthCert whose issuer is some fake principal, like "root", and whose subject, tag, propagate bit, and validity are as given in the AclEntry. So in the example, you'd create an AuthCert whose issuer is root and whose subject is Alice, etc. Add these Certs to your CertStore. Now just attempt to prove the AuthCert, "root grants webcam-read-access to Bobby". If a proof is found, then Bobby has access. Sorry the support for this isn't better! Sameer On Thu, 26 Aug 2004 09:30:02 -0700, Dav Coleman <dav...@gm...> wrote: > I'm making progress on my JSDSI app. I can create keypairs, name > certificates and auth certificates so far. There's a GUI interface > that uses the file system for persistence (serialized unencrypted > HashMap for the KeyPairs at the moment, and a directory of > jsdsi.Certificate.toSequence() .certificate files created with > jsdsi.ObjOutputStream). > > I'm a little confused with how jsdsi.Acl and jsdsi.AuthCert work together. > > Is the idea that the AclEntry is the 'base' for all authorizations? > > Is this scenario compatible with the design intentions? : > > I want to grant a permission to access my webcam to the principal I > call Alice and her family. > > 1) I create a jsdsi.Tag that represents the webcam access. Say a > StringTag with the value "WEBCAM-READ" > 2) I create a NameCert that binds Alice's public key to the local > namespace name "Alice". I then wrap this in a jsdsi.Certificate and > store it in my CertStore. > 3) I create an AclEntry that associates the StringTag with Alice and > gives propagate permission. > 4) I store this in an jsdsi.Acl object. > 5) The jsdsi.Acl object is persisted to disk and should be encrypted > to avoid tampering. > > 6) Somehow (application-responsibility) communicate to the holder of > the Alice keypair that she has access to something represented as a > StringTag named "WEBCAM-READ" at some host. > > here's where I start getting really confused.... > > 7) Alice creates an AuthCert that delegates access to the StringTag > "WEBCAM-READ" to people bound to her local namespace as Family. This > is the only place where an AuthCert comes into play, when delegating a > Tag that was defined in someone else's Acl? > > 8) Alice wants to access the resource, so she creates some sort of > request JSDSI object that specifies > - the StringTag she is requesting access to > - A signature generated with her private key > .....what does this request look like? > > 9) When I receive this request, I have to verify that it comes from > Alice (using the Signature) and that Alice has access (using the Acl). > I assume that there are jsdsi facilities for doing this (probably > CertPathValidator or Prover I guess), but I haven't got this far yet > so I don't really know. > > 10) I'm even more confused as to how her family members create their > requests, although I assume if I can figure out how to complete a > circuit for Alice then I'll start to see how her family can do it. > > Am I on track at all here? I know this is probably a case of RTFM, but > there's so many different manuals, and frankly I don't trust that all > of them are consistent with the current JSDSI since some are for SPKI, > some are for SDSI (before the merge), some are for the old Java > implementation, some are for implementations in other languages.... > Whenever I get this working I'd like to write up some sort of online > article about how to use JSDSI in addition to publishing the demo code > so it would be a little more clear for other java app developers. > > I leave for Burning Man in two days, and then FOO Camp is three days > after I get back. I sort of don't think I'm going to have anything > ready to demo, but I'm still trying to make it happen. If I can get to > the point where I can complete an authorization/request circuit with a > couple of days left to spare then I might be able to build enough of > an example on top of that to at least demo the concept if not an > actual beta app. > > Thanks in advance for any advice! > > -- > Dav Coleman > http://AkuAku.org/ > > ------------------------------------------------------- > SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media > 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 > Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. > http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 > _______________________________________________ > Jsdsi-users mailing list > Jsd...@li... > https://lists.sourceforge.net/lists/listinfo/jsdsi-users > > -- Sameer Ajmani http://ajmani.net |