jsdsi-devel Mailing List for JSDSI
Status: Pre-Alpha
Brought to you by:
sajma
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...@gm...> - 2005-11-08 19:17:12
|
Ok, I found instructions on how to update the website, so now all the MIT copyright references should be removed from the site and the source files! I have also changed the license on SourceForge from MIT to BSD. Please take a look, if interested: http://jsdsi.sf.net Let me know if anything further needs to be done. S On 11/8/05, Rory Pheiffer <rp...@mi...> wrote: > > Dear Sameer, > > You can license the other portions of the code (the portions that never > belonged to MIT) under any license you deem appropriate. If you decide to > use the MIT license, make sure you adjust the copyrights accordingly. If > the MIT license is your preferred license, I suggest you use the > BSD-license, which is a more widely known open source license. Plus, give= n > the fact that some of the code was owned by MIT, using the "MIT license" > might be confusing. > > Please keep us posted on your efforts to remove the copyright notices. If > you need another week to solve the problem, we can allow that. > > Thanks for your assistance with this. > > Regards, > Rory > > > -----Original Message----- > From: Sameer Ajmani [mailto:aj...@gm...] > Sent: Monday, November 07, 2005 9:09 PM > To: Rory Pheiffer > Cc: aj...@cs...; mo...@gm...; Karin Rivard > Subject: Re: FW: JSDSI code > > Ok, I will try to remove the copyright notices ASAP. > > Can the code still be distributed under the MIT License? Can we > switch the license to another, e.g., LGPL? > > S > > On 11/7/05, Rory Pheiffer <rp...@mi...> wrote: > > > > > > > > Dear Sameer, > > > > > > > > M.I.T. wishes to place any code associated with JSDSI that currently > belongs > > to M.I.T. into the public domain. In conjunction with this desire, we > ask > > that you please remove any copyright notices associated with M.I.T. in > the > > JSDSI code. This decision means that you, as well as any other > contributing > > authors, do not have the right to claim any copyrights in the software > code > > (source, object or otherwise) that contains the software code originall= y > or > > subsequently belonging to M.I.T. We believe that this will be the most > > effective way to both disseminate the software for the public benefit > and > > clear up any confusion related to copyright ownership. > > > > > > > > Please remove any and all M.I.T. copyright notices in the next 48 hours > and > > confirm with me that these changes have been made. Of course, you and > other > > authors can contribute to JSDSI as you wish, and can copyright whatever > > portions that you contribute as you see fit so long as the code you > desire > > to copyright is not the code that MIT has released into the public > domain. > > > > > > > > Please contact me if you have any questions about this decision. > > > > > > > > Regards, > > > > Rory > > > > > > > > > > > > ________________________________ > > > > > > From: Sameer Ajmani [mailto:aj...@gm...] > > Sent: Friday, October 28, 2005 12:37 PM > > To: Rory Pheiffer > > Cc: aj...@cs... > > Subject: Re: FW: JSDSI code > > > > > > > > > > Hi Rory, > > > > The JSDSI SourceForge project (jsdsi.sf.net <http://jsdsi.sf.net>) > contains both MIT and > non-MIT > > code. The parts of the code developed at MIT (by Alex and by myself) ar= e > > covered by the MIT license and copyright. Other parts of the code were > > developed by individual non-MIT contributors and so fall under the MIT > > license, though it's unclear who holds the copyright. > > > > Alex's original code (Java package "sdsi") was developed as part of his > > MEng thesis in 1998, and I extended it as part of my Master's thesis in > > 2000. > > > > In 2001 and 2002, I developed a new codebase (Java package "jsdsi") tha= t > > replaces Alex's original package. Small parts of JSDSI reuse Alex's > code, > > but I wrote the majority of it from scratch. This code is not part of > any > > thesis, but I used it in some of my research between my Masters and PhD= . > > > > I moved JSDSI to SourceForge under the MIT License in Feb 2003. Since > then > > a few other developers have contributed to the codebase. One in > particular > > added the "jsdsi.ldap" package; it's unclear to me who owns the > copyright > > for this part of the code. > > > > Note that I graduated from MIT with my PhD in Aug 2004. I would still > like > > to be able to contribute to JSDSI when need arises. Please let me know > if > > there are any problems with this. And of course contact me with any > > followup questions. > > S > > > > > > On 10/25/05, Rory Pheiffer <rp...@mi...> wrote: > > > > > > > > > > > > > > ________________________________ > > > > > > From: Rory Pheiffer [mailto:rp...@mi...] > > Sent: Tuesday, October 25, 2005 11:02 AM > > To: 'aj...@mi...'; 'mo...@al...' > > Cc: 'Karin Rivard' > > Subject: FW: JSDSI code > > > > > > > > Dear Alexander and Sameer, > > > > > > > > The MIT Technology Licensing Office recently received the inquiry found > > below related to your software, JSDSI. I reviewed our file history and > > could not locate any disclosure to the TLO regarding this software. > Could > > you please provide me with details as to who owns the code? I see that > > Alexander's thesis is copyrighted by MIT, and based on the title, I > assume > > that the thesis is at least related to the code and may even contain th= e > > code. Additionally, it appears that the license attributes the copyrigh= t > to > > MIT as well. If MIT does own the copyright to the software, that > software > > should be disclosed to our office. Then we will be able to adequately > > answer questions like the ones posed below. > > > > > > > > Please contact me soon so that we can respond to Mr. Kirichenko. > > > > > > > > Thank you. > > > > > > > > Regards, > > > > Rory > > > > > > > > > > > > Rory P. Pheiffer > > > > Technology Licensing Associate > > > > Massachusetts Institute of Technology > > > > Technology Licensing Office > > > > Five Cambridge Center, NE25-230 > > > > Kendall Square > > > > Cambridge, MA 02142-1493 > > > > > > > > E-mail: rp...@mi... > > > > Telephone: (617) 253-6966 > > > > Fax: (617) 258-6790 > > > > > > > > ________________________________ > > > > > > From: Karin Rivard [mailto:rivard@MIT.EDU] > > Sent: Monday, October 24, 2005 8:40 AM > > To: Rory Pheiffer > > Subject: Fwd: JSDSI code > > > > > > > > Rory, > > See if we have a case disclosure on this code or anything else you can > find > > out. > > Thanks, > > Karin > > > > X-Sieve: CMU Sieve 2.2 > > X-Sender: al...@fs... > > X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 <http://6.1.2.0> > > Date: Mon, 24 Oct 2005 12:18:25 +0300 > > To: ri...@mi... > > From: ale...@f-... > > Subject: JSDSI code > > X-OriginalArrivalTime: 24 Oct 2005 09:19:15.0790 (UTC) > > FILETIME=3D[0137B6E0:01C5D87C] > > X-Spam-Score: -0.286 > > X-Spam-Flag: NO > > X-Scanned-By: MIMEDefang 2.42 > > > > Dear Karin, > > > > we've been evaluating the JSDSI code for implementing SPKI > > certificates support and related functionality in Java. We're > considering > > starting a project that would make use of a number of portions of > > the JSDSI package. > > > > The license that we found in the package appears very non-restrictive: > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > MIT License for JSDSI Implementation > > > > Copyright 2002 > > Massachusetts Institute of Technology > > > > Permission to use, copy, modify, and distribute this program for any > > purpose and without fee is hereby granted, provided that this copyright > > > > and permission notice appear on all copies and supporting > > documentation, > > > > the name of M.I.T. not be used in advertising or publicity pertaining > > to > > > > distribution of the program without specific prior permission, and > > notice > > > > be given in supporting documentation that copying and distribution is > > by > > > > permission of M.I.T. M.I.T. makes no representations about the > > suitability of this software for any purpose. It is provided > > "as is" without express or implied warranty. > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > However, as our legal people have their concerns, I'd appreciate if you > > answer the following questions: > > > > 1. My understanding is that the MIT license for the JSDSI code doesn't > > restrict us in the use of the code in our products, modulo the copyrigh= t > > and permission notice inclusion in appropriate places. Is that correct? > > In particular, our legal department is concerned of possible export > > restrictions that we may have to honor. Are you aware of anything like > > that? > > > > 2. Is there any way for us to ensure that the JSDSI code that we're > > planning > > to use really originates from the MIT group and is covered by the above > > MIT license? > > > > Thank you. > > > > Sincerely, > > > > Alexey > > ---------- > > Alexey Kirichenko tel +358 9 2520 0700 > > Senior Researcher fax +358 9 2520 5018 > > F-Secure Corporation http://www.f-secure.com/ > > BE SURE. > > > > __________________________________________________ > > Karin K. Rivard, Asst. Director and Counsel > > MIT Technology Licensing Office, Room NE25-230 > > Five Cambridge Center, Kendall Square > > Cambridge, MA 02142 > > Phone: (617) 253-6966; Fax: (617) 258-6790 > > Email: ri...@mi... > > > > > > > > > > -- > > Sameer > > http://ajmani.net > > > -- > Sameer > http://ajmani.net > > -- Sameer http://ajmani.net |
From: Sameer A. <aj...@gm...> - 2005-11-08 03:26:31
|
[use corrected JSDSI devel list] Sean, can you take a look at my message below? We need to remove the MIT copyright from JSDSI, and I'm having difficulty with Maven :) S On 11/7/05, Sameer Ajmani <aj...@gm...> wrote: > Okay, I have removed the MIT copyright from all the source files and > am working on redeploying the web site with the copyright removed. > Unfortunately, the project was ported to a build system (Maven) that I > am not very familiar with; I am ccing jsdsi-devel in hopes that > another developer more familiar with this task can help remove the > other copyright notices. > > I will not have much more time to work on this this week (busy with my > day job), so I cannot guarantee that all copyright notices will be > removed from the site in 48 hours, as you requested. Hopefully > another developer on the team will be able to pick this up in my > stead. > > S > > On 11/7/05, Sameer Ajmani <aj...@gm...> wrote: > > Ok, I will try to remove the copyright notices ASAP. > > > > Can the code still be distributed under the MIT License? Can we > > switch the license to another, e.g., LGPL? > > > > S > > > > On 11/7/05, Rory Pheiffer <rp...@mi...> wrote: > > > > > > > > > > > > Dear Sameer, > > > > > > > > > > > > M.I.T. wishes to place any code associated with JSDSI that currently = belongs > > > to M.I.T. into the public domain. In conjunction with this desire, w= e ask > > > that you please remove any copyright notices associated with M.I.T. i= n the > > > JSDSI code. This decision means that you, as well as any other contr= ibuting > > > authors, do not have the right to claim any copyrights in the softwar= e code > > > (source, object or otherwise) that contains the software code origina= lly or > > > subsequently belonging to M.I.T. We believe that this will be the mo= st > > > effective way to both disseminate the software for the public benefit= and > > > clear up any confusion related to copyright ownership. > > > > > > > > > > > > Please remove any and all M.I.T. copyright notices in the next 48 hou= rs and > > > confirm with me that these changes have been made. Of course, you an= d other > > > authors can contribute to JSDSI as you wish, and can copyright whatev= er > > > portions that you contribute as you see fit so long as the code you d= esire > > > to copyright is not the code that MIT has released into the public do= main. > > > > > > > > > > > > Please contact me if you have any questions about this decision. > > > > > > > > > > > > Regards, > > > > > > Rory > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > From: Sameer Ajmani [mailto:aj...@gm...] > > > Sent: Friday, October 28, 2005 12:37 PM > > > To: Rory Pheiffer > > > Cc: aj...@cs... > > > Subject: Re: FW: JSDSI code > > > > > > > > > > > > > > > Hi Rory, > > > > > > The JSDSI SourceForge project (jsdsi.sf.net) contains both MIT and n= on-MIT > > > code. The parts of the code developed at MIT (by Alex and by myself)= are > > > covered by the MIT license and copyright. Other parts of the code we= re > > > developed by individual non-MIT contributors and so fall under the MI= T > > > license, though it's unclear who holds the copyright. > > > > > > Alex's original code (Java package "sdsi") was developed as part of = his > > > MEng thesis in 1998, and I extended it as part of my Master's thesis = in > > > 2000. > > > > > > In 2001 and 2002, I developed a new codebase (Java package "jsdsi") = that > > > replaces Alex's original package. Small parts of JSDSI reuse Alex's = code, > > > but I wrote the majority of it from scratch. This code is not part o= f any > > > thesis, but I used it in some of my research between my Masters and P= hD. > > > > > > I moved JSDSI to SourceForge under the MIT License in Feb 2003. Sin= ce then > > > a few other developers have contributed to the codebase. One in part= icular > > > added the "jsdsi.ldap" package; it's unclear to me who owns the copyr= ight > > > for this part of the code. > > > > > > Note that I graduated from MIT with my PhD in Aug 2004. I would sti= ll like > > > to be able to contribute to JSDSI when need arises. Please let me kn= ow if > > > there are any problems with this. And of course contact me with any > > > followup questions. > > > S > > > > > > > > > On 10/25/05, Rory Pheiffer <rp...@mi...> wrote: > > > > > > > > > > > > > > > > > > > > > ________________________________ > > > > > > > > > From: Rory Pheiffer [mailto:rp...@mi...] > > > Sent: Tuesday, October 25, 2005 11:02 AM > > > To: 'aj...@mi...'; 'mo...@al...' > > > Cc: 'Karin Rivard' > > > Subject: FW: JSDSI code > > > > > > > > > > > > Dear Alexander and Sameer, > > > > > > > > > > > > The MIT Technology Licensing Office recently received the inquiry fou= nd > > > below related to your software, JSDSI. I reviewed our file history a= nd > > > could not locate any disclosure to the TLO regarding this software. = Could > > > you please provide me with details as to who owns the code? I see th= at > > > Alexander's thesis is copyrighted by MIT, and based on the title, I a= ssume > > > that the thesis is at least related to the code and may even contain = the > > > code. Additionally, it appears that the license attributes the copyr= ight to > > > MIT as well. If MIT does own the copyright to the software, that sof= tware > > > should be disclosed to our office. Then we will be able to adequatel= y > > > answer questions like the ones posed below. > > > > > > > > > > > > Please contact me soon so that we can respond to Mr. Kirichenko. > > > > > > > > > > > > Thank you. > > > > > > > > > > > > Regards, > > > > > > Rory > > > > > > > > > > > > > > > > > > Rory P. Pheiffer > > > > > > Technology Licensing Associate > > > > > > Massachusetts Institute of Technology > > > > > > Technology Licensing Office > > > > > > Five Cambridge Center, NE25-230 > > > > > > Kendall Square > > > > > > Cambridge, MA 02142-1493 > > > > > > > > > > > > E-mail: rp...@mi... > > > > > > Telephone: (617) 253-6966 > > > > > > Fax: (617) 258-6790 > > > > > > > > > > > > ________________________________ > > > > > > > > > From: Karin Rivard [mailto:rivard@MIT.EDU] > > > Sent: Monday, October 24, 2005 8:40 AM > > > To: Rory Pheiffer > > > Subject: Fwd: JSDSI code > > > > > > > > > > > > Rory, > > > See if we have a case disclosure on this code or anything else you c= an find > > > out. > > > Thanks, > > > Karin > > > > > > X-Sieve: CMU Sieve 2.2 > > > X-Sender: al...@fs... > > > X-Mailer: QUALCOMM Windows Eudora Version 6.1.2.0 > > > Date: Mon, 24 Oct 2005 12:18:25 +0300 > > > To: ri...@mi... > > > From: ale...@f-... > > > Subject: JSDSI code > > > X-OriginalArrivalTime: 24 Oct 2005 09:19:15.0790 (UTC) > > > FILETIME=3D[0137B6E0:01C5D87C] > > > X-Spam-Score: -0.286 > > > X-Spam-Flag: NO > > > X-Scanned-By: MIMEDefang 2.42 > > > > > > Dear Karin, > > > > > > we've been evaluating the JSDSI code for implementing SPKI > > > certificates support and related functionality in Java. We're consid= ering > > > starting a project that would make use of a number of portions of > > > the JSDSI package. > > > > > > The license that we found in the package appears very non-restrictiv= e: > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D > > > MIT License for JSDSI Implementation > > > > > > Copyright 2002 > > > Massachusetts Institute of Technology > > > > > > Permission to use, copy, modify, and distribute this program for any > > > purpose and without fee is hereby granted, provided that this copyrig= ht > > > > > > and permission notice appear on all copies and supporting > > > documentation, > > > > > > the name of M.I.T. not be used in advertising or publicity pertaining > > > to > > > > > > distribution of the program without specific prior permission, and > > > notice > > > > > > be given in supporting documentation that copying and distribution is > > > by > > > > > > permission of M.I.T. M.I.T. makes no representations about the > > > suitability of this software for any purpose. It is provided > > > "as is" without express or implied warranty. > > > > > > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > > > However, as our legal people have their concerns, I'd appreciate if = you > > > answer the following questions: > > > > > > 1. My understanding is that the MIT license for the JSDSI code doesn= 't > > > restrict us in the use of the code in our products, modulo the copyr= ight > > > and permission notice inclusion in appropriate places. Is that corre= ct? > > > In particular, our legal department is concerned of possible export > > > restrictions that we may have to honor. Are you aware of anything li= ke > > > that? > > > > > > 2. Is there any way for us to ensure that the JSDSI code that we're > > > planning > > > to use really originates from the MIT group and is covered by the ab= ove > > > MIT license? > > > > > > Thank you. > > > > > > Sincerely, > > > > > > Alexey > > > ---------- > > > Alexey Kirichenko tel +358 9 2520 0700 > > > Senior Researcher fax +358 9 2520 5018 > > > F-Secure Corporation http://www.f-secure.com/ > > > BE SURE. > > > > > > __________________________________________________ > > > Karin K. Rivard, Asst. Director and Counsel > > > MIT Technology Licensing Office, Room NE25-230 > > > Five Cambridge Center, Kendall Square > > > Cambridge, MA 02142 > > > Phone: (617) 253-6966; Fax: (617) 258-6790 > > > Email: ri...@mi... > > > > > > > > > > > > > > > -- > > > Sameer > > > http://ajmani.net > > > > > > -- > > Sameer > > http://ajmani.net > > > > > -- > Sameer > http://ajmani.net > -- Sameer http://ajmani.net |
From: Sean R. <sra...@ae...> - 2005-02-19 18:04:40
|
Comitted a simple JSDSI version of the Sun Keytool for command generation of a JSDSI keystore. Only genkey and list are currently implemented. Sean -- Dr. Sean Radford, MBBS, MSc sra...@ae... http://www.aegeus-technology.com/ Distributed Identity Management Solutions |
From: Sean R. <sra...@ae...> - 2005-02-17 16:54:23
|
Guys, Just committed to CVS a simple file-based KeyStore to handle JSDSI PublicKeys, PKCS8 PrivateKeys, and it should handle X509 PublicKeys too. PrivateKeys are individually encrypted (even in memory and only decrypted when required) and there is a MAC on the whole store. It is in the jsdsi.util package. Regards, Sean -- Dr. Sean Radford, MBBS, MSc sra...@ae... http://www.aegeus-technology.com/ Distributed Identity Management Solutions |
From: Sean R. <sra...@ae...> - 2004-12-30 23:03:20
|
Sameer Ajmani wrote: >Glad to hear it! Let us know if you have any feature requests or find any bugs. > > >On Thu, 30 Dec 2004 10:46:51 -0800 (PST), J. Patrick Bedell ><jpb...@uc...> wrote: > > >>Hello, >> This is a short note of thanks for developing your software, which I >>have used in my own ICWS (information currency web services) software at >>http://sourceforge.net/projects/infoeng. >> Thanks for your work! >> >> J. Patrick Bedell >> jpb...@uc... >> >> >> Ditto - Will be very interested to know your views on JSDSI. Will even try and look at your code over the next few weeks. Regards, Sean -- Dr. Sean Radford, MBBS, MSc sra...@ae... http://www.aegeus-technology.com/ |
From: Sameer A. <aj...@gm...> - 2004-12-30 19:06:06
|
Glad to hear it! Let us know if you have any feature requests or find any bugs. On Thu, 30 Dec 2004 10:46:51 -0800 (PST), J. Patrick Bedell <jpb...@uc...> wrote: > > Hello, > This is a short note of thanks for developing your software, which I > have used in my own ICWS (information currency web services) software at > http://sourceforge.net/projects/infoeng. > Thanks for your work! > > J. Patrick Bedell > jpb...@uc... > > ------------------------------------------------------- > The SF.Net email is sponsored by: Beat the post-holiday blues > Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. > It's fun and FREE -- well, almost....http://www.thinkgeek.com/sfshirt > _______________________________________________ > Jsdsi-devel mailing list > Jsd...@li... > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel > > -- Sameer Ajmani http://ajmani.net |
From: J. P. B. <jpb...@uc...> - 2004-12-30 18:46:59
|
Hello, This is a short note of thanks for developing your software, which I have used in my own ICWS (information currency web services) software at http://sourceforge.net/projects/infoeng. Thanks for your work! J. Patrick Bedell jpb...@uc... |
From: Sameer A. <aj...@gm...> - 2004-12-19 17:02:14
|
> Ok, I'm for that. > > Would you like me to (in the certstore branch): > > 1. Ditch JsdsiRuntimeException > 2. Create a JsdsiException (a checked exception) > 3. Refactor other code to throw a JsdsiException (or a subclass). > > I would also vote to clean-up the cerstore branch, in terms of removing > a number of the deprecated methods, then merge into HEAD and make a > shiny new release to sf.net. Thoughts? Yes, this sounds great! Thanks a lot, -- Sameer Ajmani http://ajmani.net |
From: Sean R. <sra...@ae...> - 2004-12-19 11:44:17
|
Sameer Ajmani wrote: >>I haven't changed JsdsiCertStoreException to be checked... I thought we >>had agreed back April time to use RuntimeExceptions. I've gone more and >>more off Checked Exceptions. Have a read here for other (well known >>peoples' views): >> >>http://www.artima.com/intv/handcuffs.html >>http://www.mindview.net/Etc/Discussions/CheckedExceptions >> >> > >These are interesting arguments, but I don't actually think JSDSI has >the scalability and versioning problems described herein. This is >because by having a top-level JsdsiException and other exceptions that >derive from this, clients can just catch that exception as they would >a runtime exception (they could even wrap it in a runtime exception if >they really prefer that). So even if we have JsdsiProverException, >JsdsiSignatureException, JsdsiCertStoreException, etc, the caller can >just catch an dprocess JsdsiException, or pass it along, or re-throw >something else. But making it checked guaranteed the compiler will >give clients of JSDSI a heads-up that there's an exception that may be >thrown. > >btw, I'm a big fan of exception chaining, so I definitely think any >Java Crypto Exceptions should be wrapped in a JsdsiException subclass; >users who care about the distinction between NoSuchProviderException >and NoSuchAlgorithmException can follow the causal chain to find this >information. > > Ok, I'm for that. Would you like me to (in the certstore branch): 1. Ditch JsdsiRuntimeException 2. Create a JsdsiException (a checked exception) 3. Refactor other code to throw a JsdsiException (or a subclass). I would also vote to clean-up the cerstore branch, in terms of removing a number of the deprecated methods, then merge into HEAD and make a shiny new release to sf.net. Thoughts? > > >>>In JdbcCertificateDAO.retrieve(), extract the long if-else chain into >>>a method that does: >>>return retrieve.(...); >>>- in each if-branch. This makes the code easier to read, since it's >>>clear "result" is only assigned to once in retrieve(). >>> >>> >>> >>Sorry, but not sure I understand what you mean by this. If you mean to >>not assign to 'result' but just return, then you loose the logging >>information. >> >> > >Actually, I just meant to move the if-then-else to a method, so as to >guarantee result is never accidentally left as null. Again, this is a >way to let the compiler help you: if the if-then-else is in a method, >and each branch returns the result, then the compiler will complain if >not all cases are covered. You would still have your roriginal method >assign the returned value to a "result" variable, log it, and return >it. > > > Understand. Will do. -- Dr. Sean Radford, MBBS, MSc sra...@ae... http://www.aegeus-technology.com/ |
From: Sean R. <sra...@ae...> - 2004-12-15 19:19:41
|
Sameer Ajmani wrote: >Nope, should be fine. We may need to write special deserialization >code to handle NULL_AUTH and the like (NULL_TAG, ALL_TAG). > >Sameer > > > Done and in CVS -- Dr. Sean Radford, MBBS, MSc sra...@ae... http://www.aegeus-technology.com/ |
From: Sameer A. <aj...@gm...> - 2004-12-15 17:23:55
|
Nope, should be fine. We may need to write special deserialization code to handle NULL_AUTH and the like (NULL_TAG, ALL_TAG). Sameer On Wed, 15 Dec 2004 17:06:42 +0000, Sean Radford <sra...@ae...> wrote: > Guys (Sameer), > > Any reasons why jsdsi.Auth should not be Serializable? > > (I want to pass it remotely) > > Sean > > -- > Dr. Sean Radford, MBBS, MSc > sra...@ae... > http://www.aegeus-technology.com/ > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Jsdsi-devel mailing list > Jsd...@li... > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel > > -- Sameer Ajmani http://ajmani.net |
From: Sean R. <sra...@ae...> - 2004-12-15 17:02:11
|
Guys (Sameer), Any reasons why jsdsi.Auth should not be Serializable? (I want to pass it remotely) Sean -- Dr. Sean Radford, MBBS, MSc sra...@ae... http://www.aegeus-technology.com/ |
From: Sean R. <sra...@ae...> - 2004-12-12 17:25:01
|
Guys, Done more work on the CertStore branch: 1. jsdsi.certstore.InMemoryCertificateDAO A MultiMap implemenation of jsdsi.certstore.CertificateDAO. 2. Fully implemented (with unit tests), a JDBC implementation of CertificatedDAO (jsdsi.certstore.jdbc.JdbcCertificateDAO) 3. A extension to CertificateDAO that I presume is needed for an LDAPCertificateDAO implementation in jsdsi.certstore.ldap package. 4. Moved jsdsi.MultiMap to jsdsi.util package and made it 'public'. 5. Various code tidy-up and documentation. I haven't changed JsdsiCertStoreException to be checked... I thought we had agreed back April time to use RuntimeExceptions. I've gone more and more off Checked Exceptions. Have a read here for other (well known peoples' views): http://www.artima.com/intv/handcuffs.html http://www.mindview.net/Etc/Discussions/CheckedExceptions Sameer, >- There's a misspelled file: jsdsi.JsdiRuntimeException (there's also >the correctly-spelled version) > > There sure is, but it is deprecated for the very reason that it is spelt wrong. >In JdbcCertificateDAO.retrieve(), extract the long if-else chain into >a method that does: >return retrieve.(...); >- in each if-branch. This makes the code easier to read, since it's >clear "result" is only assigned to once in retrieve(). > > Sorry, but not sure I understand what you mean by this. If you mean to not assign to 'result' but just return, then you loose the logging information. Let me know what you think. Regards, Sean -- Dr. Sean Radford, MBBS, MSc sra...@ae... http://www.aegeus-technology.com/ |
From: Sameer A. <aj...@gm...> - 2004-12-07 22:03:36
|
You might just add a new one, "AuthOnlyCertSelector." Ideally, we'd retroactively name the old one "IssuerAuthCertSelector" and call yours "AuthCertSelector", but I'd lke to keep the API stable. Sameer On Tue, 07 Dec 2004 18:55:27 +0000, Sean Radford <sra...@ae...> wrote: > Well I need it for an app I'm dealing with at present. I could extend > CertSelector and make a 'new' AuthCertSelector within my own package > that does what I need I guess. > > > > > Sameer Ajmani wrote: > > >Sure, but the Prover will never use that kind of query (it will always > >specify an issuer for AuthCertSelectors and NameCertSelectors). One > >of the benefits of always requiring the issuer is that it lets > >CertStores avoid keeping really long lists of certs that all share the > >same auth or same name. > > > >If you allow null issuer in AuthCertSelector, you ought to do the same > >for NameCertSelector. But is this kind of queyr really useful? I'd > >rather enforce non-null issuer if possible. > > > >Sameer > > > >On Tue, 07 Dec 2004 17:18:06 +0000, Sean Radford > ><sra...@ae...> wrote: > > > > > >>Hi, > >> > >>Would it be valid to allow AuthCertSelector to have a null issuer so it > >>would match all AuthCerts only on the Auth? > >> > >>Sean > >> > >>-- > >>Dr. Sean Radford, MBBS, MSc > >>sra...@ae... > >>http://www.aegeus-technology.com/ > >> > >>------------------------------------------------------- > >>SF email is sponsored by - The IT Product Guide > >>Read honest & candid reviews on hundreds of IT Products from real users. > >>Discover which products truly live up to the hype. Start reading now. > >>http://productguide.itmanagersjournal.com/ > >>_______________________________________________ > >>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/ > > -- Sameer Ajmani http://ajmani.net |
From: Sean R. <sra...@ae...> - 2004-12-07 18:52:52
|
Well I need it for an app I'm dealing with at present. I could extend CertSelector and make a 'new' AuthCertSelector within my own package that does what I need I guess. Sameer Ajmani wrote: >Sure, but the Prover will never use that kind of query (it will always >specify an issuer for AuthCertSelectors and NameCertSelectors). One >of the benefits of always requiring the issuer is that it lets >CertStores avoid keeping really long lists of certs that all share the >same auth or same name. > >If you allow null issuer in AuthCertSelector, you ought to do the same >for NameCertSelector. But is this kind of queyr really useful? I'd >rather enforce non-null issuer if possible. > >Sameer > >On Tue, 07 Dec 2004 17:18:06 +0000, Sean Radford ><sra...@ae...> wrote: > > >>Hi, >> >>Would it be valid to allow AuthCertSelector to have a null issuer so it >>would match all AuthCerts only on the Auth? >> >>Sean >> >>-- >>Dr. Sean Radford, MBBS, MSc >>sra...@ae... >>http://www.aegeus-technology.com/ >> >>------------------------------------------------------- >>SF email is sponsored by - The IT Product Guide >>Read honest & candid reviews on hundreds of IT Products from real users. >>Discover which products truly live up to the hype. Start reading now. >>http://productguide.itmanagersjournal.com/ >>_______________________________________________ >>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...@gm...> - 2004-12-07 17:54:51
|
Sure, but the Prover will never use that kind of query (it will always specify an issuer for AuthCertSelectors and NameCertSelectors). One of the benefits of always requiring the issuer is that it lets CertStores avoid keeping really long lists of certs that all share the same auth or same name. If you allow null issuer in AuthCertSelector, you ought to do the same for NameCertSelector. But is this kind of queyr really useful? I'd rather enforce non-null issuer if possible. Sameer On Tue, 07 Dec 2004 17:18:06 +0000, Sean Radford <sra...@ae...> wrote: > Hi, > > Would it be valid to allow AuthCertSelector to have a null issuer so it > would match all AuthCerts only on the Auth? > > Sean > > -- > Dr. Sean Radford, MBBS, MSc > sra...@ae... > http://www.aegeus-technology.com/ > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > Jsdsi-devel mailing list > Jsd...@li... > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel > > -- Sameer Ajmani http://ajmani.net |
From: Sean R. <sra...@ae...> - 2004-12-07 17:15:35
|
Hi, Would it be valid to allow AuthCertSelector to have a null issuer so it would match all AuthCerts only on the Auth? Sean -- Dr. Sean Radford, MBBS, MSc sra...@ae... http://www.aegeus-technology.com/ |
From: Sean R. <sra...@ae...> - 2004-12-07 08:04:06
|
Sameer Ajmani wrote: >These changes look good. A few notes: >- Provide some package-level documentation -- what's a DAO? (Data >Access Object) What are the important interfaces of this package? >(CertificateDAO) What implementations are provided? (Jdbc) >- You should extract the Multimap-based implementation of >jsdsi.CertStore into a DAO, "LocalCertificateDAO", and make >jsdsi.CertStore a subclass of certstore.JsdsiCertStore that uses >LocalCertificateDAO. (the following bullets clarify how to go about >this) >- AbstractJsdsiCertStore should implement >init(CollectionCertStoreParameters params) by calling >this.addCertificate(c) for eact Certificate c in >params.getCollection().iterator(). addCertificate is a new abstract >method of AbstractJsdsiCertStore. >- JsdsiCertStore implements addCertificate(c) by calling dao.store(c). >- LocalCertifificateDAO implements store(c) by populating its >MultiMaps as shown in jsdsi.CertStore.init(). >- AbstractJsdsiCertStore.getCertificates: change "( X instanceof Y) == >false" to "!(X instanceof Y)" >- There's a misspelled file: jsdsi.JsdiRuntimeException (there's also >the correctly-spelled version) >- I personally don't like RuntimeExceptions -- I'd rather the compiler >tell me that there's an exception on the way, even if all I can do is >propagate it. >- I thnk JsdsiCertStoreException ought to be a checked (non-runtime) exception. >- JdbcCertificateDAO.store() is hard to follow. Instead, define these methods: >byte[] getIssuer(Certificate) >byte[] getSubject(Certificate) >byte[] getCompatible(Certificate) >byte[] getLocalName(Certificate) >byte[] getName(Certificate) >- and populate the "params" array with calls to these methods >In JdbcCertificateDAO.retrieve(), extract the long if-else chain into >a method that does: >return retrieve.(...); >- in each if-branch. This makes the code easier to read, since it's >clear "result" is only assigned to once in retrieve(). > >Overall, looks cool. Does the prover work correctly with the >JdbcCertStore? (it should!) Is JdbcCertStore a distributed store? > >Thanks for the contribution. Let me know if you want me to look at >revisions, and assuming all is well, we can merge it in to the >mainline. > >Sameer > >On Tue, 23 Nov 2004 14:32:08 +0000, Sean Radford ><sra...@ae...> wrote: > > Sameer, Cheers for your input. Hopefully, I'll be able to work on it this w/e. Sean -- Dr. Sean Radford, MBBS, MSc sra...@ae... http://www.aegeus-technology.com/ |
From: Sameer A. <aj...@gm...> - 2004-12-06 23:15:12
|
These changes look good. A few notes: - Provide some package-level documentation -- what's a DAO? (Data Access Object) What are the important interfaces of this package? (CertificateDAO) What implementations are provided? (Jdbc) - You should extract the Multimap-based implementation of jsdsi.CertStore into a DAO, "LocalCertificateDAO", and make jsdsi.CertStore a subclass of certstore.JsdsiCertStore that uses LocalCertificateDAO. (the following bullets clarify how to go about this) - AbstractJsdsiCertStore should implement init(CollectionCertStoreParameters params) by calling this.addCertificate(c) for eact Certificate c in params.getCollection().iterator(). addCertificate is a new abstract method of AbstractJsdsiCertStore. - JsdsiCertStore implements addCertificate(c) by calling dao.store(c). - LocalCertifificateDAO implements store(c) by populating its MultiMaps as shown in jsdsi.CertStore.init(). - AbstractJsdsiCertStore.getCertificates: change "( X instanceof Y) == false" to "!(X instanceof Y)" - There's a misspelled file: jsdsi.JsdiRuntimeException (there's also the correctly-spelled version) - I personally don't like RuntimeExceptions -- I'd rather the compiler tell me that there's an exception on the way, even if all I can do is propagate it. - I thnk JsdsiCertStoreException ought to be a checked (non-runtime) exception. - JdbcCertificateDAO.store() is hard to follow. Instead, define these methods: byte[] getIssuer(Certificate) byte[] getSubject(Certificate) byte[] getCompatible(Certificate) byte[] getLocalName(Certificate) byte[] getName(Certificate) - and populate the "params" array with calls to these methods In JdbcCertificateDAO.retrieve(), extract the long if-else chain into a method that does: return retrieve.(...); - in each if-branch. This makes the code easier to read, since it's clear "result" is only assigned to once in retrieve(). Overall, looks cool. Does the prover work correctly with the JdbcCertStore? (it should!) Is JdbcCertStore a distributed store? Thanks for the contribution. Let me know if you want me to look at revisions, and assuming all is well, we can merge it in to the mainline. Sameer On Tue, 23 Nov 2004 14:32:08 +0000, Sean Radford <sra...@ae...> wrote: > Sean Radford wrote: > > > > > No sooner have I merged one branch, I've created another... > > > > Guys, > > > > I've created a branch in CVS called 'branch-certstore'. > > > > This is another experimental design I'd like you all to have a look at > > refactoring the architecture of CertStore to easily allow alternate > > stores and standard interface for also storing Certificates. Fancy > > taking a look and getting back to me? (jsdsi.certstore package). The > > new implementation is for JDBC. > > > > Regards, > > > > Sean > > > Don't suppose any of you have had a look? > > -- > Dr. Sean Radford, MBBS, MSc > sra...@ae... > http://www.aegeus-technology.com/ > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > > > _______________________________________________ > Jsdsi-devel mailing list > Jsd...@li... > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel > > -- Sameer Ajmani http://ajmani.net |
From: Sean R. <sra...@ae...> - 2004-11-23 14:30:29
|
Sean Radford wrote: > No sooner have I merged one branch, I've created another... > > Guys, > > I've created a branch in CVS called 'branch-certstore'. > > This is another experimental design I'd like you all to have a look at > refactoring the architecture of CertStore to easily allow alternate > stores and standard interface for also storing Certificates. Fancy > taking a look and getting back to me? (jsdsi.certstore package). The > new implementation is for JDBC. > > Regards, > > Sean > Don't suppose any of you have had a look? -- Dr. Sean Radford, MBBS, MSc sra...@ae... http://www.aegeus-technology.com/ |
From: Sean R. <sra...@ae...> - 2004-11-16 17:10:59
|
No sooner have I merged one branch, I've created another... Guys, I've created a branch in CVS called 'branch-certstore'. This is another experimental design I'd like you all to have a look at refactoring the architecture of CertStore to easily allow alternate stores and standard interface for also storing Certificates. Fancy taking a look and getting back to me? (jsdsi.certstore package). The new implementation is for JDBC. Regards, Sean -- Dr. Sean Radford, MBBS, MSc sra...@ae... http://www.aegeus-technology.com/ |
From: Sameer A. <aj...@gm...> - 2004-11-15 02:00:11
|
The RSAKeyPairGenerator and KeyGenParameters look great---thanks! S On Fri, 12 Nov 2004 09:48:53 -0500, Sameer Ajmani <aj...@gm...> wrote: > Ok, I'll try to look at this over the weekend. > > Thanks, > Sameer > > > > > On Fri, 12 Nov 2004 10:05:48 +0000, Sean Radford > <sra...@ae...> wrote: > > Guys, > > > > Think I've finished with the Key stuff for now. > > > > I'm off on a long w/e shortly. If there are no issues on my return next > > week I'll do a snapshot build and deploy to sourceforge. > > > > Sean > > > > -- > > Dr. Sean Radford, MBBS, MSc > > sra...@ae... > > http://www.aegeus-technology.com/ > > > > ------------------------------------------------------- > > This SF.Net email is sponsored by: > > Sybase ASE Linux Express Edition - download now for FREE > > LinuxWorld Reader's Choice Award Winner for best database on Linux. > > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > > _______________________________________________ > > Jsdsi-devel mailing list > > Jsd...@li... > > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel > > > > > > > -- > Sameer Ajmani > http://ajmani.net > -- Sameer Ajmani http://ajmani.net |
From: Sameer A. <aj...@gm...> - 2004-11-12 14:49:02
|
Ok, I'll try to look at this over the weekend. Thanks, Sameer On Fri, 12 Nov 2004 10:05:48 +0000, Sean Radford <sra...@ae...> wrote: > Guys, > > Think I've finished with the Key stuff for now. > > I'm off on a long w/e shortly. If there are no issues on my return next > week I'll do a snapshot build and deploy to sourceforge. > > Sean > > -- > Dr. Sean Radford, MBBS, MSc > sra...@ae... > http://www.aegeus-technology.com/ > > ------------------------------------------------------- > This SF.Net email is sponsored by: > Sybase ASE Linux Express Edition - download now for FREE > LinuxWorld Reader's Choice Award Winner for best database on Linux. > http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click > _______________________________________________ > Jsdsi-devel mailing list > Jsd...@li... > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel > > -- Sameer Ajmani http://ajmani.net |
From: Sean R. <sra...@ae...> - 2004-11-12 10:06:35
|
Guys, Think I've finished with the Key stuff for now. I'm off on a long w/e shortly. If there are no issues on my return next week I'll do a snapshot build and deploy to sourceforge. Sean -- Dr. Sean Radford, MBBS, MSc sra...@ae... http://www.aegeus-technology.com/ |
From: Sean R. <sra...@ae...> - 2004-11-11 12:06:37
|
Sameer, I've done a little bit more to the KeyPairGenerator and have a question. How to handle the URIs for our keys? I think that ideally we want to be able specify a URI for each KeyPair creation, but I guess we have to do it per KeyPairGenerator via initialise(AlgorithmParameterSpec). What do you think? Sean -- Dr. Sean Radford, MBBS, MSc sra...@ae... http://www.aegeus-technology.com/ |