jsdsi-devel Mailing List for JSDSI (Page 9)
Status: Pre-Alpha
Brought to you by:
sajma
Menu
▾
▴
jsdsi-devel — JSDSI Developers
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(4) |
Sep
|
Oct
|
Nov
|
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
|
Feb
(45) |
Mar
(60) |
Apr
(12) |
May
(18) |
Jun
(14) |
Jul
(8) |
Aug
(10) |
Sep
|
Oct
(12) |
Nov
(16) |
Dec
(15) |
| 2005 |
Jan
|
Feb
(2) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|
From: Sameer A. <aj...@cs...> - 2004-02-24 00:41:31
|
Funny enough, ConChord doesn't use JSDSI (it's implemented in C++). ConChord has some design flaws, and I actually think JSDSI's name resolution algorithms (which I developed after ConChord) are more efficient! Sameer > Sameer, > > Sounds good to me - I'm more than willing to accept your judegement as > good enough. > > On a side note... The code from ConChord, is that available somewhere > and possible to integrate into JSDSI? > > Sean > > On Mon, 2004-02-23 at 21:00, Sameer Ajmani wrote: >> Hi guys, >> >> Another developer has been workign with JSDSI for the last several >> months and has created an LDAP CertStore that works with JSDSI. He's >> interested in contributing this code to JSDSI, so I'd like to add him >> as another developer. Let me know if you have any questions or >> concerns; if not, I'll add him tomorrow. >> >> Sameer >> >> 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... > http://www.aegeus-technology.com http://ajmani.net |
|
From: Sean R. <sra...@ae...> - 2004-02-24 00:05:54
|
Ah... I like the idea of the peer-2-peer storage for certificates though.... Got any ideas running through your head on future directions for jsdsi in order to "scale to thousands of servers and millions of certificates" that you say that ConChord could? Sean On Mon, 2004-02-23 at 23:40, Sameer Ajmani wrote: > Funny enough, ConChord doesn't use JSDSI (it's implemented in C++). > ConChord has some design flaws, and I actually think JSDSI's name > resolution algorithms (which I developed after ConChord) are more > efficient! > > Sameer > > > Sameer, > > > > Sounds good to me - I'm more than willing to accept your judegement as > > good enough. > > > > On a side note... The code from ConChord, is that available somewhere > > and possible to integrate into JSDSI? > > > > Sean > > > > On Mon, 2004-02-23 at 21:00, Sameer Ajmani wrote: > >> Hi guys, > >> > >> Another developer has been workign with JSDSI for the last several > >> months and has created an LDAP CertStore that works with JSDSI. He's > >> interested in contributing this code to JSDSI, so I'd like to add him > >> as another developer. Let me know if you have any questions or > >> concerns; if not, I'll add him tomorrow. > >> > >> Sameer > >> > >> 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... > > http://www.aegeus-technology.com > > > http://ajmani.net > -- Dr. Sean Radford, MBBS, MSc sra...@ae... http://www.aegeus-technology.com |
|
From: Sean R. <sra...@ae...> - 2004-02-23 23:47:08
|
Sameer, Sounds good to me - I'm more than willing to accept your judegement as good enough. On a side note... The code from ConChord, is that available somewhere and possible to integrate into JSDSI? Sean On Mon, 2004-02-23 at 21:00, Sameer Ajmani wrote: > Hi guys, > > Another developer has been workign with JSDSI for the last several months > and has created an LDAP CertStore that works with JSDSI. He's interested > in contributing this code to JSDSI, so I'd like to add him as another > developer. Let me know if you have any questions or concerns; if not, > I'll add him tomorrow. > > Sameer > > 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... http://www.aegeus-technology.com |
|
From: Sameer A. <aj...@cs...> - 2004-02-23 21:08:45
|
Hi guys, Another developer has been workign with JSDSI for the last several months and has created an LDAP CertStore that works with JSDSI. He's interested in contributing this code to JSDSI, so I'd like to add him as another developer. Let me know if you have any questions or concerns; if not, I'll add him tomorrow. Sameer http://ajmani.net |
|
From: Sameer A. <aj...@cs...> - 2004-02-21 14:55:49
|
Sean, Eclipse seems to handle rebuilding JSDSI very well on its own. What would Maven contribute to the process? Is there a way to make JSDSI buildable/usable without Maven, yet also distributed the Maven files for those who want them? Thanks, Sameer > Hiya, > > Just a quick reply to the first part of Sameer's message (regarding > Eclipse) as I've got to run off for the weekend... > > 1. I love Eclipse - been using it for about 2 years now. > 2. I love Maven - been using it for about 2.5 years. > 3. I use Maven for managing and doing all the automated builds for my > project and normally use the Maven Eclipse Plugin to (re)create the > Eclipse project as needed. > > So I guess what I am saying is that Maven and Eclipse can work very well > together. > > And I'm happy to port it all into that structure if you guys like. > > > Regards, > > Sean > > P.S. I agree that the parsing stuff needs improving. Just need time > myself to look into it - will look at the projects you have suggested > Sameer early next week. > > On Sat, 2004-02-21 at 06:23, Sameer Ajmani wrote: >> Hi guys, >> >> I have a couple of things I'd like to consider for JSDSI: >> >> 1) I've checked out the Eclipse IDE, and I really like it. What do >> you guys think of making JSDSI an Eclipse project? I realize Sean's >> code uses Maven, so I don't know what sort of problems this might >> cause for that. Sean: could we develop the core of JSDSI using >> Eclipse, and export it as a JAR for your purposes? >> >> 2) I want to replace all of JSDSI's hand-written parsing and unparsing >> code (jsdsi.sexp, and the toSexp() methods in each jsdsi.Obj subclass) >> with something based on an actual grammar. I really like Parsing >> Expression Grammars (http://www.pdos.lcs.mit.edu/~baford/packrat/), >> and a group at NYU has recently created a PEG parser generator for >> Java called Rats(http://www.cs.nyu.edu/rgrimm/xtc/rats.html). PEGs >> are faster and clearer than CFGs, and Rats has a clean, >> straightforward syntax. I don't have much time to work on this >> (trying to graduate with my PhD), but I'll probably hack on a JSDSI >> PEG when I get a chance. >> >> Let me know what you think, >> Sameer >> >> 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... http://ajmani.net |
|
From: Sean R. <sra...@ae...> - 2004-02-21 11:41:49
|
Hiya, Just a quick reply to the first part of Sameer's message (regarding Eclipse) as I've got to run off for the weekend... 1. I love Eclipse - been using it for about 2 years now. 2. I love Maven - been using it for about 2.5 years. 3. I use Maven for managing and doing all the automated builds for my project and normally use the Maven Eclipse Plugin to (re)create the Eclipse project as needed. So I guess what I am saying is that Maven and Eclipse can work very well together. And I'm happy to port it all into that structure if you guys like. Regards, Sean P.S. I agree that the parsing stuff needs improving. Just need time myself to look into it - will look at the projects you have suggested Sameer early next week. On Sat, 2004-02-21 at 06:23, Sameer Ajmani wrote: > Hi guys, > > I have a couple of things I'd like to consider for JSDSI: > > 1) I've checked out the Eclipse IDE, and I really like it. What do you > guys think of making JSDSI an Eclipse project? I realize Sean's code uses > Maven, so I don't know what sort of problems this might cause for that. > Sean: could we develop the core of JSDSI using Eclipse, and export it as a > JAR for your purposes? > > 2) I want to replace all of JSDSI's hand-written parsing and unparsing > code (jsdsi.sexp, and the toSexp() methods in each jsdsi.Obj subclass) > with something based on an actual grammar. I really like Parsing > Expression Grammars (http://www.pdos.lcs.mit.edu/~baford/packrat/), and a > group at NYU has recently created a PEG parser generator for Java called > Rats(http://www.cs.nyu.edu/rgrimm/xtc/rats.html). PEGs are faster and > clearer than CFGs, and Rats has a clean, straightforward syntax. I don't > have much time to work on this (trying to graduate with my PhD), but I'll > probably hack on a JSDSI PEG when I get a chance. > > Let me know what you think, > Sameer > > 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... |
|
From: Sameer A. <aj...@cs...> - 2004-02-21 06:29:55
|
Hi guys, I have a couple of things I'd like to consider for JSDSI: 1) I've checked out the Eclipse IDE, and I really like it. What do you guys think of making JSDSI an Eclipse project? I realize Sean's code uses Maven, so I don't know what sort of problems this might cause for that. Sean: could we develop the core of JSDSI using Eclipse, and export it as a JAR for your purposes? 2) I want to replace all of JSDSI's hand-written parsing and unparsing code (jsdsi.sexp, and the toSexp() methods in each jsdsi.Obj subclass) with something based on an actual grammar. I really like Parsing Expression Grammars (http://www.pdos.lcs.mit.edu/~baford/packrat/), and a group at NYU has recently created a PEG parser generator for Java called Rats(http://www.cs.nyu.edu/rgrimm/xtc/rats.html). PEGs are faster and clearer than CFGs, and Rats has a clean, straightforward syntax. I don't have much time to work on this (trying to graduate with my PhD), but I'll probably hack on a JSDSI PEG when I get a chance. Let me know what you think, Sameer http://ajmani.net |
|
From: Sameer A. <aj...@cs...> - 2004-02-12 19:25:17
|
Comments inline:
> 1. Made jsdsi.Obj implement java.io.Serializable for rmi. I think this
> should really implement the readObject() and writeObject() methods too
> in order to marshal using SEXPs.
Yes, it should definitely override those methods.
> 2. jsdsi.Validity had some code added to it by Michael Jaegar:
>
> He added some bounds checking to the constructor:
>
> public Validity(Date b, Date a, OnlineTest[] t) {
> // By mic...@in...
> if( t==null ) {
> t = new OnlineTest[0];
> }
> notBefore = b;
> notAfter = a;
> tests = t;
> }
This is fine.
> and similar to the intersect method:
>
> public Validity intersect(Validity v) {
> // combine lists of tests
> OnlineTest[] ts =
> new OnlineTest[(tests == null ? 0 : tests.length)
> + (v.tests == null ? 0 : v.tests.length)];
> int i = 0;
> if (tests != null) {
> System.arraycopy(tests, 0, ts, i, tests.length);
> i += tests.length;
> }
> if (v.tests != null) {
> System.arraycopy(v.tests, 0, ts, i, v.tests.length);
> }
This change is unnecessary because the constructor now guarantees 'tests'
can never be null -- the original intersect code will work (and is
simpler).
> 3. Michael also added some similar bounds checking to
> jsdsi.NameCertSelector:
>
> public boolean match(jsdsi.Certificate cert) {
> boolean toReturn = (cert.getCert() instanceof NameCert);
> // By mic...@in...:
> if( issuer != null ) {
> toReturn &= cert.getCert().getIssuer().samePrincipalAs(issuer);
> }
> if( name!=null) {
> toReturn &= ((NameCert) cert.getCert()).getName().equals(name);
> }
> return toReturn;
> /*
> return (cert.getCert() instanceof NameCert)
> && cert.getCert().getIssuer().samePrincipalAs(issuer)
> && ((NameCert) cert.getCert()).getName().equals(name);
> */
> }
I think instead the NameCertSelector constructor should require that
issuer and name be non-null (and throw an exception otherwise). If we
want to allow NameCert lookups by just the issuer, there should be a
different CertSelector class. This way, CertStores can reject unsupported
selectors just by checking their type.
> 4. The rest of the changes/were to do with parsing/unparsing and I'd
> need to have a more indepth look to find out what. From memory there was
> one or two bugs and some stuff left to implement, e.g. handling of URLs.
> What I'll do is run your latest code against my unit tests that I
> created to test/implement my parsing/unparsing code.
Sounds good. I'd really like to replace all the manual parsing/unparsing
with a generated parser, e.g., using JavaCC. I can't pursue this right
now, but I think it would be a very nice change.
> And as additional questions:
>
> 1. Shouldn't the references to java.net.URLs actually be java.net.URIs?
Yes -- that class didn't exist when I implemented this :)
> 2. Should the <issuer-loc> (issuer-info) attribute be added to AuthCert?
> (http://theworld.com/~cme/spki.txt section 4.4)
Yes.
Thanks,
Sameer
|
|
From: Sean R. <sra...@ae...> - 2004-02-12 19:01:26
|
Sameer,
I've had a quick look at my changes and thought I'd let you know some
points thus far:
1. Made jsdsi.Obj implement java.io.Serializable for rmi. I think this
should really implement the readObject() and writeObject() methods too
in order to marshal using SEXPs.
2. jsdsi.Validity had some code added to it by Michael Jaegar:
He added some bounds checking to the constructor:
public Validity(Date b, Date a, OnlineTest[] t) {
// By mic...@in...
if( t==null ) {
t = new OnlineTest[0];
}
notBefore = b;
notAfter = a;
tests = t;
}
and similar to the intersect method:
public Validity intersect(Validity v) {
Date nb = notBefore;
if ((nb == null) || (v.notBefore != null && v.notBefore.after(nb))) {
nb = v.notBefore;
}
Date na = notAfter;
if ((na == null) || (v.notAfter != null && v.notAfter.before(na))) {
na = v.notAfter;
}
// combine lists of tests
OnlineTest[] ts =
new OnlineTest[(tests == null ? 0 : tests.length)
+ (v.tests == null ? 0 : v.tests.length)];
int i = 0;
if (tests != null) {
System.arraycopy(tests, 0, ts, i, tests.length);
i += tests.length;
}
if (v.tests != null) {
System.arraycopy(v.tests, 0, ts, i, v.tests.length);
}
return new Validity(nb, na, ts);
}
3. Michael also added some similar bounds checking to
jsdsi.NameCertSelector:
public boolean match(jsdsi.Certificate cert) {
boolean toReturn = (cert.getCert() instanceof NameCert);
// By mic...@in...:
if( issuer != null ) {
toReturn &= cert.getCert().getIssuer().samePrincipalAs(issuer);
}
if( name!=null) {
toReturn &= ((NameCert) cert.getCert()).getName().equals(name);
}
return toReturn;
/*
return (cert.getCert() instanceof NameCert)
&& cert.getCert().getIssuer().samePrincipalAs(issuer)
&& ((NameCert) cert.getCert()).getName().equals(name);
*/
}
4. The rest of the changes/were to do with parsing/unparsing and I'd
need to have a more indepth look to find out what. From memory there was
one or two bugs and some stuff left to implement, e.g. handling of URLs.
What I'll do is run your latest code against my unit tests that I
created to test/implement my parsing/unparsing code.
And as additional questions:
1. Shouldn't the references to java.net.URLs actually be java.net.URIs?
2. Should the <issuer-loc> (issuer-info) attribute be added to AuthCert?
(http://theworld.com/~cme/spki.txt section 4.4)
Let me know what you think, regards,
Sean
--
Dr. Sean Radford, MBBS, MSc
sra...@ae...
|
|
From: Sameer A. <aj...@cs...> - 2004-02-12 15:41:01
|
>> > 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. Are you sure the Prover goes around this repeatedly? It's designed to handle this case cleanly: before it inserts a new certificate, it first checks whether it has already seen that certificate. This way, the Prover is guaranteed to stop when all possible certificate compositions are done. I have just checked in a CertPathTest that exercises this behavior. In input certificate set is defined in the file certs.in.5: ALICE +read -> BOB BOB +read -> CAROL CAROL +read -> ALICE The output file certs.out.5 contains all of the certifcates that the Prover found: ALICE +read -> ALICE ALICE +read -> BOB ALICE +read -> CAROL BOB +read -> ALICE BOB +read -> BOB BOB +read -> CAROL CAROL +read -> ALICE CAROL +read -> BOB CAROL +read -> CAROL The prover does in fact terminate, so I believe it works okay with circular cert sets. Can you create a test that fails? Sameer |
|
From: Sean R. <sra...@ae...> - 2004-02-11 23:25:12
|
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... |
|
From: Sameer A. <aj...@cs...> - 2004-02-11 17:09:05
|
-------- 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?. > 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. > 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? > 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. > 5. A class to detect circular questions. Like "Does Alice grant read access to Alice"? > 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... > 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. > 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. > 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. > 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. 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 |
|
From: Michael J. <mij...@in...> - 2003-08-06 07:14:02
|
Hey,
now it seems that everybody is on the ship again! Great to hear from you
both!
On Tuesday 05 August 2003 16:41, Sameer Ajmani wrote:
| Here's a revised grammar that may work:
|
| <tag-all>:: "(*)" ;
| <tag-expr>:: <tag-set> | <tag-simple> | <tag-string> ;
| <tag-expr-or-all>:: <tag-expr> | <tag-all>;
| <tag-prefix>:: "(" "*" "prefix" <byte-string> ")" ;
| <tag-range>:: "(" "*" "range" <range-ordering> <low-lim>? <up-lim>?
| ")" ;
| <tag-set>:: "(" "*" "set" <tag-expr>* ")" ;
| <tag-simple>:: "(" <byte-string> <tag-expr-or-all>* ")" ;
| <tag-string>:: <byte-string> | <tag-range> | <tag-prefix> ;
| <tag>:: "(" "tag" <tag-expr-or-all> ")" ;
|
| I've replaced "tag-star" with "tag-all" and renamed "simple-tag" to
| "tag-simple". The most important facet of this grammar is that
| "tag-all" may NOT appear inside a "tag-set" (if it could, the whole set
| could just be replaced by "tag-all").
Sameer, your revised grammar should work -- in principle this is the way I
solved this issue for my thesis. As I'm actually working for a company I
can't say how much time this will take me to do, but my plan is to first
write a JUnit-test and after that maybe I will first start to implement the
parsing stuff with JavaCC. Hopefully I will start my Ph.D. soon, because
then I will hopefully have more time to work on JSDSI :-).
| Nice ot hear you guys are working on this :)
| I've been going crazy trying to get my Ph.D. done (on another topic).
How is your Ph.D. doing, Sameer? Have you done it?
I whish you all the best.
Michael.
|
|
From: Sameer A. <aj...@CS...> - 2003-08-05 14:42:00
|
Here's a revised grammar that may work:
<tag-all>:: "(*)" ;
<tag-expr>:: <tag-set> | <tag-simple> | <tag-string> ;
<tag-expr-or-all>:: <tag-expr> | <tag-all>;
<tag-prefix>:: "(" "*" "prefix" <byte-string> ")" ;
<tag-range>:: "(" "*" "range" <range-ordering> <low-lim>? <up-lim>?
")" ;
<tag-set>:: "(" "*" "set" <tag-expr>* ")" ;
<tag-simple>:: "(" <byte-string> <tag-expr-or-all>* ")" ;
<tag-string>:: <byte-string> | <tag-range> | <tag-prefix> ;
<tag>:: "(" "tag" <tag-expr-or-all> ")" ;
I've replaced "tag-star" with "tag-all" and renamed "simple-tag" to
"tag-simple". The most important facet of this grammar is that
"tag-all" may NOT appear inside a "tag-set" (if it could, the whole set
could just be replaced by "tag-all").
Nice ot hear you guys are working on this :)
I've been going crazy trying to get my Ph.D. done (on another topic).
Sameer
Sean Radford wrote:
> Hi Guys,
>
> Yep, has been a little quiet on the list - though for me, that doesn't
> mean that I haven't been playing with SPKI (JSDSI). On the contrary, I
> have been doing nothing but... However, it's all been 'higher-level'
> stuff: some jsdsi utilities; a web-based Principal (and Name/Auth)
> management system; and a certificate server. Still LOADS to do! My
> 'dream' is to present a plausible promise of using SPKI as a security
> infrastructure and then making it all open source (that last bit depends
> on company strategy, but all the board members are keen, but actually
> doing so depends on lots of factors).
>
> As regards to the ALL_TAG issue. I'm not sure. Still not looked in great
> detail about tag handling and intersection. However, it does seem
> logical to allow the ALL_TAG as a SimpleTag to me, and in looking
> through the SPKI mailing list that is how Carl says it should be - as he
> says, he needs to update the documentation.
>
>
> Regards,
>
> Sean
>
>
>
> On Sat, 2003-08-02 at 19:58, Michael Jaeger wrote:
>
>>Hi,
>>
>>there has been a lot of silence on the lists the last months. Today I found
>>the time to work on jsdsi and the first thing i wanted to fix was the
>>SimpleTag: As i wrote previously, the combination with the ALL_TAG is
>>currently not correct. As a reminder here is what i wrote:
>>
>>
>>>I've got a suggestion for JSDSI: I don't know if I'm right, but maybe we
>>>should overthink the implementation of the ALL_TAG. Currently it's a
>>>Tag and not an ExprTag, which means that you can't use it in a SimpleTag.
>>
>>In
>>
>>>RFC 2693 Ellison et al. quote an example in section 6.5.7 which looks like
>>>this:
>>>
>>>(tag (* set (ssl) (dns (*))))
>>>
>>>This examples looks like the ALL_TAG is allowed in a SimpleTag. What do you
>>>think? In my opinion it makes sense to allow the ALL_TAG in SimpleTags.
>>
>>As Carl Ellison replied to my question on the SPKI Mailinglist this behaviour
>>is wrong and not covered in the BNF.
>>
>>For my diplomathesis I just changed the implies()-method in the following way,
>>which is quite a dirty fix:
>>
>> boolean implies(Tag that) {
>> // By mic...@in...
>> if( (value.equals("*") && tags.length==0) ) {
>> return true;
>> }
>>
>> if( that instanceof SimpleTag ) {
>> SimpleTag sThat = (SimpleTag) that;
>> if( sThat.getValue().equals(value) && tags.length==sThat.getTags().length)
>>{
>> for(int i=0; i<tags.length; i++ ) {
>> if( !tags[i].implies(sThat.tags[i]) ) {
>> return false;
>> }
>> }
>> return true;
>> }
>> }
>> return false;
>> }
>>
>>My suggestion is to solve the problem by refactoring the ALL_TAG. This could
>>otherwise be problematic as this would mean altering the BNF-scheme defined
>>by Carl Ellison. What do you think?
>>
>>All the best,
>>Michael.
>>
>>
>>
>>--
>>This SF.Net email sponsored by: Free pre-built ASP.NET sites including
>>Data Reports, E-commerce, Portals, and Forums are available now.
>>Download today and enter to win an XBOX or Visual Studio .NET.
>>http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
>>_______________________________________________
>>Jsdsi-devel mailing list
>>Jsd...@li...
>>https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
>
>
|
|
From: Sean R. <sra...@ae...> - 2003-08-05 12:50:41
|
Hi Guys,
Yep, has been a little quiet on the list - though for me, that doesn't
mean that I haven't been playing with SPKI (JSDSI). On the contrary, I
have been doing nothing but... However, it's all been 'higher-level'
stuff: some jsdsi utilities; a web-based Principal (and Name/Auth)
management system; and a certificate server. Still LOADS to do! My
'dream' is to present a plausible promise of using SPKI as a security
infrastructure and then making it all open source (that last bit depends
on company strategy, but all the board members are keen, but actually
doing so depends on lots of factors).
As regards to the ALL_TAG issue. I'm not sure. Still not looked in great
detail about tag handling and intersection. However, it does seem
logical to allow the ALL_TAG as a SimpleTag to me, and in looking
through the SPKI mailing list that is how Carl says it should be - as he
says, he needs to update the documentation.
Regards,
Sean
On Sat, 2003-08-02 at 19:58, Michael Jaeger wrote:
> Hi,
>
> there has been a lot of silence on the lists the last months. Today I found
> the time to work on jsdsi and the first thing i wanted to fix was the
> SimpleTag: As i wrote previously, the combination with the ALL_TAG is
> currently not correct. As a reminder here is what i wrote:
>
> > I've got a suggestion for JSDSI: I don't know if I'm right, but maybe we
> > should overthink the implementation of the ALL_TAG. Currently it's a
> > Tag and not an ExprTag, which means that you can't use it in a SimpleTag.
> In
> > RFC 2693 Ellison et al. quote an example in section 6.5.7 which looks like
> > this:
> >
> > (tag (* set (ssl) (dns (*))))
> >
> > This examples looks like the ALL_TAG is allowed in a SimpleTag. What do you
> > think? In my opinion it makes sense to allow the ALL_TAG in SimpleTags.
>
> As Carl Ellison replied to my question on the SPKI Mailinglist this behaviour
> is wrong and not covered in the BNF.
>
> For my diplomathesis I just changed the implies()-method in the following way,
> which is quite a dirty fix:
>
> boolean implies(Tag that) {
> // By mic...@in...
> if( (value.equals("*") && tags.length==0) ) {
> return true;
> }
>
> if( that instanceof SimpleTag ) {
> SimpleTag sThat = (SimpleTag) that;
> if( sThat.getValue().equals(value) && tags.length==sThat.getTags().length)
> {
> for(int i=0; i<tags.length; i++ ) {
> if( !tags[i].implies(sThat.tags[i]) ) {
> return false;
> }
> }
> return true;
> }
> }
> return false;
> }
>
> My suggestion is to solve the problem by refactoring the ALL_TAG. This could
> otherwise be problematic as this would mean altering the BNF-scheme defined
> by Carl Ellison. What do you think?
>
> All the best,
> Michael.
>
>
>
> --
> This SF.Net email sponsored by: Free pre-built ASP.NET sites including
> Data Reports, E-commerce, Portals, and Forums are available now.
> Download today and enter to win an XBOX or Visual Studio .NET.
> http://aspnet.click-url.com/go/psa00100003ave/direct;at.aspnet_072303_01/01
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
--
Dr. Sean Radford, MBBS, MSc
<sra...@ae...>
Aegeus Technology Ltd.
|
|
From: Michael J. <mij...@in...> - 2003-08-02 18:59:00
|
Hi,
there has been a lot of silence on the lists the last months. Today I found
the time to work on jsdsi and the first thing i wanted to fix was the
SimpleTag: As i wrote previously, the combination with the ALL_TAG is
currently not correct. As a reminder here is what i wrote:
> I've got a suggestion for JSDSI: I don't know if I'm right, but maybe we
> should overthink the implementation of the ALL_TAG. Currently it's a
> Tag and not an ExprTag, which means that you can't use it in a SimpleTag.
In
> RFC 2693 Ellison et al. quote an example in section 6.5.7 which looks like
> this:
>
> (tag (* set (ssl) (dns (*))))
>
> This examples looks like the ALL_TAG is allowed in a SimpleTag. What do you
> think? In my opinion it makes sense to allow the ALL_TAG in SimpleTags.
As Carl Ellison replied to my question on the SPKI Mailinglist this behaviour
is wrong and not covered in the BNF.
For my diplomathesis I just changed the implies()-method in the following way,
which is quite a dirty fix:
boolean implies(Tag that) {
// By mic...@in...
if( (value.equals("*") && tags.length==0) ) {
return true;
}
if( that instanceof SimpleTag ) {
SimpleTag sThat = (SimpleTag) that;
if( sThat.getValue().equals(value) && tags.length==sThat.getTags().length)
{
for(int i=0; i<tags.length; i++ ) {
if( !tags[i].implies(sThat.tags[i]) ) {
return false;
}
}
return true;
}
}
return false;
}
My suggestion is to solve the problem by refactoring the ALL_TAG. This could
otherwise be problematic as this would mean altering the BNF-scheme defined
by Carl Ellison. What do you think?
All the best,
Michael.
|
2 messages has been excluded from this view by a project administrator.
