Re: [Jsdsi-devel] [Fwd: Re: Proposal]

[Sean R. <sra...@ae...>]

On Wed, 2004-02-11 at 17:08, Sameer Ajmani wrote:
> -------- Original Message --------
> Subject: Re: Proposal
> From: "Sameer Ajmani" <aj...@cs...>
> Date: Wed, February 11, 2004 5:07 pm
> To: <sra...@ae...>
> 
> Comments inline:
> 
> > 1. Fixed a few bugs / added umimplemented features.
> Cool -- which?.

I'll have to get back to you on those. As mentioned in my earlier email,
I'll get the latest JSDSI and diff it with my stuff. Then we can agree
what bits (if any) should be migrated across.


> > 2. Added a new Tag type (FilepathTag which is to specify a Principal's
> > access rights to a file hierarchy)
> 
> Shouldn't this just be a combination of SimpleTags, SetTags, and
> PrefixTags?  For example:
> (file-access (*set read execute) (*prefix /home/ajmani))
> would grant read and execute permision on any files under my home
> directory.

One would think so. However at the time there were some issues in doing
this for the particular application (which is a bit of a playground
app)... The one I can think of at present is:

(file-access read /home/ajmani/ant/)
implies
(file-access read /home/ajmani/) and
(file-access read /home/) etc
but does not imply
(file-access read /home/ajmani/ant/bear)

whereas

(file-access admin /home/ajmani/ant/)
does not imply
(file-access admin /home/ajmani/) or
(file-access admin /home/) etc
but does imply
(file-access admin /home/ajmani/ant/bear)

I can see that one could model the 'admin' version using a PrefixTag for
the path element, but one as far as I can see one would need some form
of SuffixTag (ReversePrefixTag) for the 'read' version.

Can you see a way of doing it better?

(The .samsAs() method really came out of the above problem when doing a
search for certificates paths and I'm keen to get rid of it anyway, so
best not to cloud things with that at present).

but 
> > 3. A new concept on tags .sameAs() (wasn't happy about this, but at
> > the time had to be done - would ideally like to get rid of it, but
> > concensus may in the end be to keep it) - it allows tags of different
> > classes to be compared as equal() in terms of functionality.
> 
> I think the new implies() method on Tags provides this behavior.  Tag A
> implies() tag B if tag A grants all permissions granted by tag B (and
> possibly more).  For example, the file-access tag above implies() these
> tags:
> (file-access read (*prefix /home/ajmani))
> (file-access execute (*prefix /home/ajmani))
> (file-access (*set read execute) (*prefix /home/ajmani/bin))
> (file-access execute /home/ajmani/bin/script1)
> 
> If tag A and tag B implies() each other, they should be equals().  See
> TagTest for many more examples.
> 
> Note that the Prover may now return certificate chains that create a tag
> that's stronger than the one requested.  This makes JSDSI much more
> flexible -- you no longer need to match your request exactly to the tag
> returned by the Prover.
> 
> > 2. Generated the idea of a Question to pass to a Prover or Searcher
> > for retrieving a Proof or collection of certificate chains meeting
> > some criteria.
> 
> Does the new Prover behavior described above obviate the need for the
> Question class?  How is Question different from CertPathParameters?
> 

I'm not sure I understand what you mean by 'the Prover may now return
... a tag that's stronger than the one requested'. I assume you mean one
that may implies() more, i.e. a superset?

The Question class allows one to specify what you want and then some
additional information to the Prover/Searcher on how to process it (e.g
whether to caching preferences). Questions are also given an id for
identification of circular questions (see below).

Questions are also different to using CertPathParameters as they can be
used for:

1. Obtaining authorisation proofs (the same as 'jsdsi.Prover')
2. Obtaining Name proofs -i.e. a chain that proves that Principal 123
knows Principal 456 as 'bob'
3. Performing authorisation searces - e.g (a little harder to explain,
so in loose terms) return all the certificate paths that give Principal
123 access to resource A
4. Name searches - return all the the certificate paths that show that
Principal 123 knows another Principal as bob (i.e return all the
Principals that Principal 123 knows as 'bob')




> > 3. Created some rough and ready implementations of a distributed
> > Prover and Searcher for processing Questions.
> 
> Interesting -- how does this work?  I designed the Prover to work well
> when fetching certificates from a remote CertStore, but it sounds like
> you've actually distribuetd the Prover itself.  This definitely sound
> slike a cool addition.
> 

Yes, the Prover and Searcher design is a distributed one - needs some
extra work to make it nicer, but works... The actual algorythm behind my
current version(s) are a breadth-first-forward brute-force search. They
are of course just implementations of an interface so can easily be
swapped out for a more appropriate implementation in different
circumstances.


> > 5. A class to detect circular questions.
> Like "Does Alice grant read access to Alice"?
> 

No. More when:
Alice grants read to Bob
Bob grants read to Carol
Carol grants read to Alice

And you then ask to Prove that Derek can read - it prevents the Prover
(and Searcher) going round in a circular reference). Works by each
Pipeline having a CircularQuestionDetector which keeps track of recent
questions and throwing an exception if one re-appears.



> > 6. A Pipeline to configure provers/searchers/caches into a
> > process-flow. (probably a few other bits and pieces...)
> Definitely cool -- perhaps what we want is a jsdsi.process package...
> 

Well it would be cool to get some of this lot into the community. It has
all come about from looking at using SPKI in a 'wild' J2EE application
so I see it as the start of some things that are needed to make JSDSI
even more interesting and attractive for (distributed) web-based
applications.


> > In addition I've Maven'ised both JSDSI and my mini-project.
> Hmm.  I still use old-fashioned Makefiles, but useing something more
> advanced is probably smart :)  I just hesitate to make people download
> yet-another-package to use JSDSI.  Overall, JSDSI needs much better
> documentation, and at least a HOWTO or Getting Started guide.
> 

Maven gives a lot more than just easier building and testing - helps
with the documentationa and site generation for one. And of course
people who are only using jsdsi don't need to use maven themselves.



> > Sorry, I hadn't realised that you had made a new release. Are you
> > planning to start versioning the releases and announce them along with
> > intended future plans?
> 
> I really should.  We haven't been using the jsdsi-devel, jsdsi-users, or
> jsdsi-announce lists provided by SourceForge, and we ought to.
> 
I know, we all should really. In retrospect I should have asked you some
questions earlier but wanting to play around myself first to understand
all this stuff more first.

As mentioned before, in a couple of weeks I should have a little more
time to spend on tidying up all this. So hopefully, we'll get the
project in good shape with a nice web-presence and good project
structure.

> > As regards to my suggesting of a change of name. This is because I
> > feel that JSDSI is an implementation of SPKI 2 and as such should
> > reflect this and anyone doing a cursory search for SPKI information
> > may miss out on this valuable library. - just my view (it's all about
> > marketing) However, I totally understand your respect to legacy users.
> 
> Well, the title of the JSDSI home page is "JSDSI: A Java SPKI/SDSI
> implementation", and technically, SPKI 2.0 is also SDSI 2.0 :)  But I
> agree that name recognition is a good thing.  I'm not sure how to
> accomplish this, though.
> 
One to leave for a bit and maybe see how the community feel at a latter
stage.

> > And finally... In light of the inteded use of JSDSI, I definately feel
> > that swaping to a LGPL would help people/companies feel more
> > 'comfortable' in using the library.
> 
> Okay -- I'll just have to check with Ron Rivest et al that this is okay.
> 
Cool.

Thanks Sameer

Sean

> Thanks,
> Sameer
> 
> >
> > On Wed, 2004-02-11 at 00:38, Sameer Ajmani wrote:
> >> Sean,
> >>
> >> Does your new code change any of the JSDSI core classes?  If not, we
> >> could create a new JSDSI sub-package (jsdsi.whatever) with your
> >> additional features.  I hesitate to change the name, only because
> >> that may impact many existing users (and the project actually has
> >> some name recognition).
> >>
> >> As for the license, changing it to LGPL is probably ok.  But we need
> >> to retain the MIT copyright notice (separate from the license) on the
> >> original classes, but not on your new classes.
> >>
> >> btw, be sure to check out my recent extensions to the Tag class
> >> (support for full Tag intersection) and the new TagTest class in
> >> jsdsi.test.
> >>
> >> Sameer
> >>
> >> > Hi guys,
> >> >
> >> > How are you both. I trust you are well and busy (and doing some fun
> >> stuff).
> >> >
> >> > I myself have still been busy with SPKI related stuff based upong
> >> JSDSI. In doing so I have created numerous utility classes to make it
> >> easy to use in a J2EE application and for distributed proving and
> >> searching of certificate chains - still much work to do to improve
> >> and tidy it all up.
> >> >
> >> > And in a few weeks I may get some time to do just that and so have
> >> a
> >> proposal...
> >> >
> >> > I suggest amalgamating my stuff with the exisiting JSDSI codebase
> >> and rebranding it as a new project to reflect the fact that SPKI is
> >> now the more correct name. I agree to take on all this work and as
> >> such am prepared to take on 'ownership' to manage its future work and
> >> > corresponding web presence (with your guidance, naturally). I am
> >> keen to really try to inject some interest it this cool library.
> >> >
> >> > Ideally I feel that the license needs to also be updated to an "OSI
> >> Certified Open Source Software" one. My preference would be a LGPL
> >> (http://www.opensource.org/licenses/lgpl-license.php), but how would
> >> we/I go about that as regards to MIT (they may need to sign a
> >> copyright disclaimer)?
> >> >
> >> > How do you guys feel about all this?
> >> >
> >> > Regards,
> >> >
> >> >
> >> > Sean
> >> >
> >> > --
> >> > Dr. Sean Radford, MBBS, MSc
> >> > sra...@ae...
> >>
> >>
> >> http://ajmani.net
> >>
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> 
> 
> http://ajmani.net
> 
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...