jsdsi-devel — JSDSI Developers

[Jsdsi-devel] SerialVersionId

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

Any objections to me placing serialVersionUID's on the Serializable
classes to speed things up (and help class compatibility)?

Sean

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Algorythm names

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

Hi,

Don't suppose any of you have had a chance to look my classes - I'm
going to need to cope with varying algos in the very very near future so
would like to take a crack at it.

(If no one has had a chance, how do you all feel about me making a cvs
branch?)

Sean

On Mon, 2004-05-31 at 00:32, Sean Radford wrote:
> Been thinking and I believe that the Enum way of going is a good idea
> and so converted the util classes to them.
> 
> So in CVS there is my proposal of how to do things. Let me know what you
> think.
> 
> Sean
> 
> 
> On Sun, 2004-05-30 at 22:14, Sean Radford wrote:
> > I guess we could change Algorithms from using straight Strings for the
> > constants to an Enum class style for type-safety.
> > 
> > Something akin to:
> > 
> > http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
> >  
> > 
> > Sean
> > 
> > On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
> > > Guys,
> > > 
> > > I've committed to cvs 3 classes in jsdsi.util for handling of algorythm
> > > names:
> > > 
> > > Algorithms
> > > DigestUtils
> > > SignatureUtils
> > > 
> > > 
> > >  - not implemented any of them yet as want input/comments first.
> > > 
> > > The idea being that in Algorithms there is a list of constants which
> > > clients use to indicate what they desire, e.g. DIGEST_MD5, KEY_RSA, etc.
> > > There are then utility methods to calculate the SPKI or JDK versions of
> > > such (This includes the problematic Signatures).
> > > 
> > > I would suggest the following coding ethos is JSDSI:
> > > 
> > > 1. jsdsi object constructors that need algorythm names use SPKI format
> > > names (this is what they should use now as that is the format dumped to
> > > Sexpression, and consequently read from a stream)
> > > 
> > > Not so sure about Hash.. has anyone looked at an Sexpression for hash
> > > and know that if you supply MD5 it comes out (incorrectly) in upper case
> > > in the Sexpression? I guess the current implementation would cause a
> > > problem with SHA-1? (as in SPKI that should be sha1).
> > > 
> > > Which then begs the question: should Hash.getAlgorithm() return the SPKI
> > > or JDK version (I guess JDK to be consistent with Key and Signature)?
> > > 
> > > 
> > > 
> > > 2. static create methods use the constants for easy client use.
> > > 
> > > The question I have for this is about jsdsi.Signature. Should the create
> > > methods take a digest constant and from that calculate the JDK Signature
> > > algorythm and corresponding SPKI algorythm using the provided constant
> > > and by examining the given keypair?
> > > 
> > > 
> > > 
> > > Thoughts? (in particular problems this approach would lead to with
> > > existing applications)
> > > 
> > > 
> > > Sean
> > > 
> > >  
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

RE: [Jsdsi-devel] 200 downloads!

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

On Wed, 2004-06-02 at 14:29, Luis Pedro wrote:
> Sean,
> 
> Where do u see that stats?
> 
http://sourceforge.net/project/stats/?group_id=74580

(there is a drop-down on the page to toggle between weekly, monthly, and
yearly stats)



>    -- Luis Pedro
>  
> 
> >   -----Original Message-----
> >   From: jsd...@li... 
> >   [mailto:jsd...@li...] On Behalf 
> >   Of Sean Radford
> >   Sent: quarta-feira, 2 de Junho de 2004 13:34
> >   To: devel jsdsi
> >   Subject: [Jsdsi-devel] 200 downloads!
> >   
> >   Don't know if anyone has looked at the jsdsi usage stats 
> >   but we have hits the 200 downloads mark.
> >   
> >   (Not bad considering we only had 6 up to the start of this year)
> >   
> >   Sean
> >   
> >   --
> >   Dr. Sean Radford, MBBS, MSc
> >   sra...@ae...
> >   http://www.aegeus-technology.com
> >   
> >   
> >   
> >   -------------------------------------------------------
> >   This SF.Net email is sponsored by the new InstallShield X.
> >   From Windows to Linux, servers to mobile, InstallShield X is the one
> >   installation-authoring solution that does it all. Learn more and
> >   evaluate today! http://www.installshield.com/Dev2Dev/0504
> >   _______________________________________________
> >   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

[Jsdsi-devel] 200 downloads!

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

Don't know if anyone has looked at the jsdsi usage stats but we have
hits the 200 downloads mark.

(Not bad considering we only had 6 up to the start of this year)

Sean

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

RE: [Jsdsi-devel] Algorythm names

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

I think that you pass in the lower case "md5" which is both legal for
SPKI and JDK. If you passed in "MD5" which is legal for JDK and not
SPKI/SEXP I think you'd have problems.

The real problem then would happen with "SHA-256" or "sha-256" as both
are legal for JDK but not SPKI/SEXP - SPKI/SEXP uses only "sha256".

There is then the other exception that in a JDK signature algorythm,
"SHA256" or "sha256" is legal and "SHA-256" and "sha-256" are not!!!
(though these signature algos are only availabe with something like
BouncyCastle)

Regards,

Sean




On Mon, 2004-05-31 at 13:00, Luis Pedro wrote:
> Hi Sean,
> 
> I'm working right now with sdsi certifcates and on the signatures the hash
> Sexpression comes rigth(lower case).
> 
>    -- Luis Pedro
>  
> 
> >   -----Original Message-----
> >   From: jsd...@li... 
> >   [mailto:jsd...@li...] On Behalf 
> >   Of Sean Radford
> >   Sent: domingo, 30 de Maio de 2004 20:53
> >   To: devel jsdsi
> >   Subject: [Jsdsi-devel] Algorythm names
> >   
> >   Guys,
> >   
> >   I've committed to cvs 3 classes in jsdsi.util for handling 
> >   of algorythm
> >   names:
> >   
> >   Algorithms
> >   DigestUtils
> >   SignatureUtils
> >   
> >   
> >    - not implemented any of them yet as want input/comments first.
> >   
> >   The idea being that in Algorithms there is a list of 
> >   constants which clients use to indicate what they desire, 
> >   e.g. DIGEST_MD5, KEY_RSA, etc.
> >   There are then utility methods to calculate the SPKI or JDK 
> >   versions of such (This includes the problematic Signatures).
> >   
> >   I would suggest the following coding ethos is JSDSI:
> >   
> >   1. jsdsi object constructors that need algorythm names use 
> >   SPKI format names (this is what they should use now as that 
> >   is the format dumped to Sexpression, and consequently read 
> >   from a stream)
> >   
> >   Not so sure about Hash.. has anyone looked at an 
> >   Sexpression for hash and know that if you supply MD5 it 
> >   comes out (incorrectly) in upper case in the Sexpression? I 
> >   guess the current implementation would cause a problem with 
> >   SHA-1? (as in SPKI that should be sha1).
> >   
> >   Which then begs the question: should Hash.getAlgorithm() 
> >   return the SPKI or JDK version (I guess JDK to be 
> >   consistent with Key and Signature)?
> >   
> >   
> >   
> >   2. static create methods use the constants for easy client use.
> >   
> >   The question I have for this is about jsdsi.Signature. 
> >   Should the create methods take a digest constant and from 
> >   that calculate the JDK Signature algorythm and 
> >   corresponding SPKI algorythm using the provided constant 
> >   and by examining the given keypair?
> >   
> >   
> >   
> >   Thoughts? (in particular problems this approach would lead 
> >   to with existing applications)
> >   
> >   
> >   Sean
> >   
> >    
> >   
> >   --
> >   Dr. Sean Radford, MBBS, MSc
> >   sra...@ae...
> >   http://www.aegeus-technology.com
> >   
> >   
> >   
> >   -------------------------------------------------------
> >   This SF.Net email is sponsored by: Oracle 10g
> >   Get certified on the hottest thing ever to hit the 
> >   market... Oracle 10g. 
> >   Take an Oracle 10g class now, and we'll give you the exam FREE.
> >   http://ads.osdn.com/?ad_id=3149&alloc_id=8166&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

Re: [Jsdsi-devel] Algorythm names

[Sameer A. <aj...@cs...>]

I don't have time to look at this right now, but I am interested in
checking out the design.  Please mark any additions as "experimental" or
somesuch, because we may want to revise it in the near future.

Thanks,
Sameer

> Been thinking and I believe that the Enum way of going is a good idea
> and so converted the util classes to them.
>
> So in CVS there is my proposal of how to do things. Let me know what you
> think.
>
> Sean
>
>
> On Sun, 2004-05-30 at 22:14, Sean Radford wrote:
>> I guess we could change Algorithms from using straight Strings for the
>> constants to an Enum class style for type-safety.
>>
>> Something akin to:
>>
>> http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
>>
>>
>> Sean
>>
>> On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
>> > Guys,
>> >
>> > I've committed to cvs 3 classes in jsdsi.util for handling of
>> algorythm names:
>> >
>> > Algorithms
>> > DigestUtils
>> > SignatureUtils
>> >
>> >
>> >  - not implemented any of them yet as want input/comments first.
>> >
>> > The idea being that in Algorithms there is a list of constants which
>> clients use to indicate what they desire, e.g. DIGEST_MD5, KEY_RSA,
>> etc. There are then utility methods to calculate the SPKI or JDK
>> versions of such (This includes the problematic Signatures).
>> >
>> > I would suggest the following coding ethos is JSDSI:
>> >
>> > 1. jsdsi object constructors that need algorythm names use SPKI
>> format names (this is what they should use now as that is the format
>> dumped to Sexpression, and consequently read from a stream)
>> >
>> > Not so sure about Hash.. has anyone looked at an Sexpression for
>> hash and know that if you supply MD5 it comes out (incorrectly) in
>> upper case in the Sexpression? I guess the current implementation
>> would cause a problem with SHA-1? (as in SPKI that should be sha1).
>> >
>> > Which then begs the question: should Hash.getAlgorithm() return the
>> SPKI or JDK version (I guess JDK to be consistent with Key and
>> Signature)?
>> >
>> >
>> >
>> > 2. static create methods use the constants for easy client use.
>> >
>> > The question I have for this is about jsdsi.Signature. Should the
>> create methods take a digest constant and from that calculate the
>> JDK Signature algorythm and corresponding SPKI algorythm using the
>> provided constant and by examining the given keypair?
>> >
>> >
>> >
>> > Thoughts? (in particular problems this approach would lead to with
>> existing applications)
>> >
>> >
>> > Sean
>> >
>> >
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
>  Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

Re: [Jsdsi-devel] Algorythm names

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

Been thinking and I believe that the Enum way of going is a good idea
and so converted the util classes to them.

So in CVS there is my proposal of how to do things. Let me know what you
think.

Sean


On Sun, 2004-05-30 at 22:14, Sean Radford wrote:
> I guess we could change Algorithms from using straight Strings for the
> constants to an Enum class style for type-safety.
> 
> Something akin to:
> 
> http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
>  
> 
> Sean
> 
> On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
> > Guys,
> > 
> > I've committed to cvs 3 classes in jsdsi.util for handling of algorythm
> > names:
> > 
> > Algorithms
> > DigestUtils
> > SignatureUtils
> > 
> > 
> >  - not implemented any of them yet as want input/comments first.
> > 
> > The idea being that in Algorithms there is a list of constants which
> > clients use to indicate what they desire, e.g. DIGEST_MD5, KEY_RSA, etc.
> > There are then utility methods to calculate the SPKI or JDK versions of
> > such (This includes the problematic Signatures).
> > 
> > I would suggest the following coding ethos is JSDSI:
> > 
> > 1. jsdsi object constructors that need algorythm names use SPKI format
> > names (this is what they should use now as that is the format dumped to
> > Sexpression, and consequently read from a stream)
> > 
> > Not so sure about Hash.. has anyone looked at an Sexpression for hash
> > and know that if you supply MD5 it comes out (incorrectly) in upper case
> > in the Sexpression? I guess the current implementation would cause a
> > problem with SHA-1? (as in SPKI that should be sha1).
> > 
> > Which then begs the question: should Hash.getAlgorithm() return the SPKI
> > or JDK version (I guess JDK to be consistent with Key and Signature)?
> > 
> > 
> > 
> > 2. static create methods use the constants for easy client use.
> > 
> > The question I have for this is about jsdsi.Signature. Should the create
> > methods take a digest constant and from that calculate the JDK Signature
> > algorythm and corresponding SPKI algorythm using the provided constant
> > and by examining the given keypair?
> > 
> > 
> > 
> > Thoughts? (in particular problems this approach would lead to with
> > existing applications)
> > 
> > 
> > Sean
> > 
> >  
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Algorythm names

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

I guess we could change Algorithms from using straight Strings for the
constants to an Enum class style for type-safety.

Something akin to:

http://jakarta.apache.org/commons/lang/api/org/apache/commons/lang/enum/Enum.html
 

Sean

On Sun, 2004-05-30 at 20:52, Sean Radford wrote:
> Guys,
> 
> I've committed to cvs 3 classes in jsdsi.util for handling of algorythm
> names:
> 
> Algorithms
> DigestUtils
> SignatureUtils
> 
> 
>  - not implemented any of them yet as want input/comments first.
> 
> The idea being that in Algorithms there is a list of constants which
> clients use to indicate what they desire, e.g. DIGEST_MD5, KEY_RSA, etc.
> There are then utility methods to calculate the SPKI or JDK versions of
> such (This includes the problematic Signatures).
> 
> I would suggest the following coding ethos is JSDSI:
> 
> 1. jsdsi object constructors that need algorythm names use SPKI format
> names (this is what they should use now as that is the format dumped to
> Sexpression, and consequently read from a stream)
> 
> Not so sure about Hash.. has anyone looked at an Sexpression for hash
> and know that if you supply MD5 it comes out (incorrectly) in upper case
> in the Sexpression? I guess the current implementation would cause a
> problem with SHA-1? (as in SPKI that should be sha1).
> 
> Which then begs the question: should Hash.getAlgorithm() return the SPKI
> or JDK version (I guess JDK to be consistent with Key and Signature)?
> 
> 
> 
> 2. static create methods use the constants for easy client use.
> 
> The question I have for this is about jsdsi.Signature. Should the create
> methods take a digest constant and from that calculate the JDK Signature
> algorythm and corresponding SPKI algorythm using the provided constant
> and by examining the given keypair?
> 
> 
> 
> Thoughts? (in particular problems this approach would lead to with
> existing applications)
> 
> 
> Sean
> 
>  
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] Algorythm names

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

Guys,

I've committed to cvs 3 classes in jsdsi.util for handling of algorythm
names:

Algorithms
DigestUtils
SignatureUtils


 - not implemented any of them yet as want input/comments first.

The idea being that in Algorithms there is a list of constants which
clients use to indicate what they desire, e.g. DIGEST_MD5, KEY_RSA, etc.
There are then utility methods to calculate the SPKI or JDK versions of
such (This includes the problematic Signatures).

I would suggest the following coding ethos is JSDSI:

1. jsdsi object constructors that need algorythm names use SPKI format
names (this is what they should use now as that is the format dumped to
Sexpression, and consequently read from a stream)

Not so sure about Hash.. has anyone looked at an Sexpression for hash
and know that if you supply MD5 it comes out (incorrectly) in upper case
in the Sexpression? I guess the current implementation would cause a
problem with SHA-1? (as in SPKI that should be sha1).

Which then begs the question: should Hash.getAlgorithm() return the SPKI
or JDK version (I guess JDK to be consistent with Key and Signature)?



2. static create methods use the constants for easy client use.

The question I have for this is about jsdsi.Signature. Should the create
methods take a digest constant and from that calculate the JDK Signature
algorythm and corresponding SPKI algorythm using the provided constant
and by examining the given keypair?



Thoughts? (in particular problems this approach would lead to with
existing applications)


Sean

 

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Alogorythm names

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

On Thu, 2004-05-27 at 03:26, Sameer Ajmani wrote:
> Hmm, I don't recall discussing this, but it seems like a good idea.
There was only about 2 sentences mixed within some other discussions
which were more important and this idea got forgotten about.


>   The
> main problem is that SPKI/SDSI's algorithm names differ from Java's
> algorithm names, particularly for ciphers and signature algorithms that
> have various modes in addition to the algorithm.  We need some sort of
> class whose responsibility is to convert from one to another. 
> Alternately, this conversion can be embedded in the relevant JSDSI
> classes, e.g., jsdsi.Signature and jsdsi.RSAPublicKey.

My preference is a separate service class to handle it all. Probably in
jsdsi.util and called Alogorythms. Got some work I need to get done for
the next few hours. I'll try to have a think about its
interface/signatures later and email my ideas.

Sean



> Sameer
> 
> > Hi guys,
> >
> > Did we ever decide on a way to move away from using plain Strings for
> > algorythm names? i.e. a Constants interface/class or something more
> > snazzy?
> >
> > Regards,
> >
> > Sean
> >
> >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: Oracle 10g
> > Get certified on the hottest thing ever to hit the market... Oracle 10g.
> >  Take an Oracle 10g class now, and we'll give you the exam FREE.
> > http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&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

Re: [Jsdsi-devel] Alogorythm names

[Sameer A. <aj...@cs...>]

Hmm, I don't recall discussing this, but it seems like a good idea.  The
main problem is that SPKI/SDSI's algorithm names differ from Java's
algorithm names, particularly for ciphers and signature algorithms that
have various modes in addition to the algorithm.  We need some sort of
class whose responsibility is to convert from one to another. 
Alternately, this conversion can be embedded in the relevant JSDSI
classes, e.g., jsdsi.Signature and jsdsi.RSAPublicKey.

Sameer

> Hi guys,
>
> Did we ever decide on a way to move away from using plain Strings for
> algorythm names? i.e. a Constants interface/class or something more
> snazzy?
>
> Regards,
>
> Sean
>
>
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g.
>  Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

[Jsdsi-devel] Alogorythm names

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

Hi guys,

Did we ever decide on a way to move away from using plain Strings for
algorythm names? i.e. a Constants interface/class or something more
snazzy?

Regards,

Sean


-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] SSH to sf

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

Hi,

Anyone any ideas why I'm getting:

ssh_exchange_identification: Connection closed by remote host

when I try to ssh in to project.sf.net? 

(used to be able to connect - to do the website upload)

Regards,

Sean

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] FASD project: Online survey launched

[<ben...@id...>]

Dear Open Source developer

I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate.
You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it.

With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development.


With many thanks for your participation,
Benno Luthiger


PS:
The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/.
We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list.

_______________________________________________________________________

Benno Luthiger
Swiss Federal Institute of Technology Zurich
8092 Zurich

Mail: benno.luthiger(at)id.ethz.ch
_______________________________________________________________________

Re: [Jsdsi-devel] Proposed additions to jsdsi.Signature

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

On Tue, 2004-05-18 at 21:34, Sameer Ajmani wrote:
> Probably okay, though Signature is getting pretty cluttered.  If you do
> this, you should change the existing create and verify methods to use
> these new methods (via ByteArrayInputStream).
Exactly my thinking :-)

Sean

> Sameer
> 
> > Guys,
> >
> > Any objection to me adding 4 new methods to jsdsi.Signature?
> >
> > public static Signature create(java.security.KeyPair kp,
> > java.io.InputStream toSign, String a)
> >
> > public static Signature create(java.security.KeyPair kp,
> > java.io.InputStream toSign, String a, String provider)
> >
> > and
> >
> > public boolean verify(java.security.PublicKey key, java.io.InputStream
> > toSign)
> >
> > public boolean verify(java.security.PublicKey key, java.io.InputStream
> > toSign, String provider)
> >
> > Basically to add functionality to allow signing and verifying of large
> > byte arrays.
> >
> >
> > Regards,
> >
> >
> > Sean
> >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: SourceForge.net Broadband
> > Sign-up now for SourceForge Broadband and get the fastest
> > 6.0/768 connection for only $19.95/mo for the first 3 months!
> > http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&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

Re: [Jsdsi-devel] Proposed additions to jsdsi.Signature

[Sameer A. <aj...@cs...>]

Probably okay, though Signature is getting pretty cluttered.  If you do
this, you should change the existing create and verify methods to use
these new methods (via ByteArrayInputStream).

Sameer

> Guys,
>
> Any objection to me adding 4 new methods to jsdsi.Signature?
>
> public static Signature create(java.security.KeyPair kp,
> java.io.InputStream toSign, String a)
>
> public static Signature create(java.security.KeyPair kp,
> java.io.InputStream toSign, String a, String provider)
>
> and
>
> public boolean verify(java.security.PublicKey key, java.io.InputStream
> toSign)
>
> public boolean verify(java.security.PublicKey key, java.io.InputStream
> toSign, String provider)
>
> Basically to add functionality to allow signing and verifying of large
> byte arrays.
>
>
> Regards,
>
>
> Sean
>
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: SourceForge.net Broadband
> Sign-up now for SourceForge Broadband and get the fastest
> 6.0/768 connection for only $19.95/mo for the first 3 months!
> http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

[Jsdsi-devel] Proposed additions to jsdsi.Signature

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

Guys,

Any objection to me adding 4 new methods to jsdsi.Signature?

public static Signature create(java.security.KeyPair kp,
java.io.InputStream toSign, String a)

public static Signature create(java.security.KeyPair kp,
java.io.InputStream toSign, String a, String provider)

and

public boolean verify(java.security.PublicKey key, java.io.InputStream
toSign)

public boolean verify(java.security.PublicKey key, java.io.InputStream
toSign, String provider)

Basically to add functionality to allow signing and verifying of large
byte arrays.


Regards,


Sean

-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] RE: RE:Tag

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

On Tue, 2004-05-18 at 15:31, Luis Pedro wrote:
> Sean,
>=20
> All sounds great, but the only problem is that Obj is an abstract class=
!!
Hmm... doesn't seem right that the registration process needs to
instantiate the class being registered. Can't see why it would or
should.

Guess, without playing myself I'm not going to help anymore :-( And
after all this I'm itching to sort it! Maybe in a couple of weeks I'll
be able to.

Sorry,

Sean


> Obj doesn't follow java bean specification and i can't see, yet, what c=
ould
> be done to make it so. Abstract classes can't be instantied. To registe=
r or
> mapping the class, the class should be a bean or things wan't work(i kn=
ow,
> because i've tryied). Using soap it's easy when your objects have only
> primitive types, but my Certificate object has jsdsi.Certificate,
> jsdsi.AuthCert, jsdsi.Tag and so on. You can't imagine what this is :( =
:(
> !!!!
>=20
> There is another possibility, using Document style instead of RPC. But =
i
> don't wan't to follow this because leads to a lot of work and trouble.
>=20
>    -- Luis Pedro
> =20
>=20
> =BB   -----Original Message-----
> =BB   From: Sean Radford [mailto:sra...@ae...]=20
> =BB   Sent: ter=E7a-feira, 18 de Maio de 2004 13:00
> =BB   To: Luis Pedro
> =BB   Cc: devel jsdsi
> =BB   Subject: Re: RE:Tag
> =BB  =20
> =BB   On Tue, 2004-05-18 at 11:52, Luis Pedro wrote:
> =BB   >  Other solution is to make soap
> =BB   > serializers/deserializers to all classes used, for=20
> =BB   example..if u wish=20
> =BB   > to pass a Tag then u have to make a=20
> =BB   serializer/deserializer to Tag,=20
> =BB   > SetTag, PrefixTag and so on. If u pass a Tag as an Obj=20
> =BB   then u have to=20
> =BB   > make serializer/deserializer to Obj, Tag, etc..because u=20
> =BB   will have the=20
> =BB   > need of cast Obj to Tag.
> =BB  =20
> =BB   Don't think that is quite correct. You should only need to=20
> =BB   create one jsdsi.Obj and register that. When Axis=20
> =BB   encounters a jsdsi.Tag, it'll see that it is a jsdsi.Obj,=20
> =BB   pass that to your serializer, where you can serialize the=20
> =BB   Tag - akin to how RMI for jsdsi classes work.
> =BB  =20
> =BB  =20
> =BB   Have you tried using=20
> =BB   org.apache.axis.encoding.ser.SimpleSerializer? You may be=20
> =BB   able to just register jsdsi.Obj to be handled by that serializer.
> =BB  =20
> =BB   Else, preferably you may be able to extend=20
> =BB   org.apache.axis.encoding.ser.Base64Serializer, and override=20
> =BB   the getValueAsString method with something like:
> =BB  =20
> =BB   public String getValueAsString(Object value, SerializationContext
> =BB   context) {
> =BB     if ((value instanceof jsdsi.Obj)=3D=3Dfalse) {
> =BB       throw new IllegalArgumentException("value must be a jsdsi.Obj=
");
> =BB     }
> =BB     byte[] bytes =3D ((jsdsi.Obj)value).toTransport();
> =BB     return Sexp.decodeString(bytes);
> =BB   }
> =BB  =20
> =BB   and of course do something similar with BaseDeserializer.
> =BB  =20
> =BB  =20
> =BB   I wish I had time to look into this - sounds a nice problem=20
> =BB   to get my teeth into...
> =BB  =20
> =BB   Sean
> =BB  =20
> =BB   >  Making the
> =BB   > (de)serializers is the correct procedure but this implies=20
> =BB   a lot of=20
> =BB   > work and is not a easy procedure(take a look at the src=20
> =BB   of axis and u=20
> =BB   > ill see what i mean)! But i found something that can be=20
> =BB   > helpfull...schema compilers that giving a schema converts=20
> =BB   to XML and=20
> =BB   > from XML java objects.
> =BB   >=20
> =BB   > Really, right now i'm a little lost in all of this and=20
> =BB   disapointed=20
> =BB   > with soap!
> =BB   >=20
> =BB   > -- Luis Pedro
> =BB   --
> =BB   Dr. Sean Radford, MBBS, MSc
> =BB   sra...@ae...
> =BB   http://www.aegeus-technology.com
> =BB  =20
> =BB  =20
--=20
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] Re: RE:Tag

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

On Tue, 2004-05-18 at 11:52, Luis Pedro wrote:
>  Other solution is to make soap
> serializers/deserializers to all classes used, for
> example..if u wish to pass a Tag then u have to make a
> serializer/deserializer to Tag, SetTag, PrefixTag and so
> on. If u pass a Tag as an Obj then u have to make
> serializer/deserializer to Obj, Tag, etc..because u will
> have the need of cast Obj to Tag.

Don't think that is quite correct. You should only need to create one
jsdsi.Obj and register that. When Axis encounters a jsdsi.Tag, it'll see
that it is a jsdsi.Obj, pass that to your serializer, where you can
serialize the Tag - akin to how RMI for jsdsi classes work.


Have you tried using org.apache.axis.encoding.ser.SimpleSerializer? You
may be able to just register jsdsi.Obj to be handled by that serializer.

Else, preferably you may be able to extend
org.apache.axis.encoding.ser.Base64Serializer, and override the
getValueAsString method with something like:

public String getValueAsString(Object value, SerializationContext
context) {
  if ((value instanceof jsdsi.Obj)==false) {
    throw new IllegalArgumentException("value must be a jsdsi.Obj");
  }
  byte[] bytes = ((jsdsi.Obj)value).toTransport();
  return Sexp.decodeString(bytes);
}

and of course do something similar with BaseDeserializer.


I wish I had time to look into this - sounds a nice problem to get my
teeth into...

Sean

>  Making the
> (de)serializers is the correct procedure but this implies
> a lot of work and is not a easy procedure(take a look at
> the src of axis and u ill see what i mean)! But i found
> something that can be helpfull...schema compilers that
> giving a schema converts to XML and from XML java objects.
> 
> Really, right now i'm a little lost in all of this and
> disapointed with soap!
> 
> -- Luis Pedro 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] RE: Soap and Jsdsi

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

It would be fantastic if you came up with something. Adding SOAP (even a
prototype implementation of) to jsdsi would make it even more
attractive.

I have a friend who has done a fair bit with axis in the last year or
so. I have a chat with him next week to sanity check with him - you
never know I may even persuade him to help you (us) out...

Good luck,

Sean

On Sat, 2004-05-15 at 13:53, Luis Pedro wrote:
> Sean,
>=20
> Well, i'll try to implement the ideia. At the time any ideia it's good =
for
> me, because i'm having great problems to pass the jsdsi.Obj.
>=20
> All tutorials that i've read, advice to use BeanSerializer and not to m=
ake
> new ones. But to me this doesn't make sense, transform all classes to b=
eans
> till java primitives types are catched!! I'm really begining to be
> disapointed with soap and maybe i'll change everything to work with rmi.
>=20
> But i'm going to give a look at the serializers.
>=20
> 	Thanks a lot.
>=20
> 	-- Luis Pedro =20
>=20
> =BB     -----Original Message-----
> =BB     From: Sean Radford [mailto:sra...@ae...]=20
> =BB     Sent: s=E1bado, 15 de Maio de 2004 12:04
> =BB     To: Luis Pedro
> =BB     Cc: devel jsdsi
> =BB     Subject: Re: Soap and Jsdsi
> =BB    =20
> =BB     I guess that you only need to cater for classes that=20
> =BB     extend jsdsi.Obj
> =BB     and so I think you should be able to just create a class (e.g.
> =BB     JsdsiSerializer) that implements=20
> =BB     org.apache.axis.encoding.Serializer
> =BB     which caters for serializing of jsdsi.Obj.
> =BB    =20
> =BB     Since jsdsi.Obj can generate the Sexp for the jsdsi class=20
> =BB     you want to
> =BB     serialize you can just output the Sexp in xml format=20
> =BB     using the jsdsi.xml
> =BB     package.
> =BB    =20
> =BB     Consequently you want to develop a JsdsiDeserializer that=20
> =BB     implements
> =BB     org.apache.axis.encoding.Deserializer to perform=20
> =BB     deserialization from
> =BB     xml to the correct jsdsi class.
> =BB    =20
> =BB     Couldn't google a tutorial on how to do it, but here are=20
> =BB     2 links that
> =BB     may be of use:
> =BB    =20
> =BB     http://ws.apache.org/soap/faq/ (search for 'How do I send=20
> =BB     user defined
> =BB     java objects using SOAP')
> =BB    =20
> =BB     http://forum.java.sun.com/thread.jsp?thread=3D488310&forum=3D3
> =BB     31&message=3D2289159
> =BB    =20
> =BB     Maybe an idea to get the axis source code and examine their
> =BB     serializers/deserializers?
> =BB    =20
> =BB     I really can't promise anything, but if you still can't=20
> =BB     get things to
> =BB     work I'll try to make time to play myself - but it won't=20
> =BB     be for a week
> =BB     at least :-(
> =BB    =20
> =BB     Sean
> =BB    =20
> =BB     On Fri, 2004-05-14 at 15:05, Luis Pedro wrote:
> =BB     > Hi Sean,
> =BB     >=20
> =BB     > U have send a mail to the mailing list about the=20
> =BB     question that i made
> =BB     > "passing certificates over soap". Have any ideia how to=20
> =BB     do it? I'm using
> =BB     > BeanSerializer of Soap wich is what they recommend, but=20
> =BB     i'm having a lot of
> =BB     > trouble because i've to convert every class to bean and=20
> =BB     in my opinion this
> =BB     > is a wrong procedure. =20
> =BB     >=20
> =BB     >    -- Luis Pedro
> =BB     --=20
> =BB     Dr. Sean Radford, MBBS, MSc
> =BB     sra...@ae...
> =BB     http://www.aegeus-technology.com
> =BB    =20
> =BB    =20
--=20
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] Re: Soap and Jsdsi

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

I guess that you only need to cater for classes that extend jsdsi.Obj
and so I think you should be able to just create a class (e.g.
JsdsiSerializer) that implements org.apache.axis.encoding.Serializer
which caters for serializing of jsdsi.Obj.

Since jsdsi.Obj can generate the Sexp for the jsdsi class you want to
serialize you can just output the Sexp in xml format using the jsdsi.xml
package.

Consequently you want to develop a JsdsiDeserializer that implements
org.apache.axis.encoding.Deserializer to perform deserialization from
xml to the correct jsdsi class.

Couldn't google a tutorial on how to do it, but here are 2 links that
may be of use:

http://ws.apache.org/soap/faq/ (search for 'How do I send user defined
java objects using SOAP')

http://forum.java.sun.com/thread.jsp?thread=488310&forum=331&message=2289159

Maybe an idea to get the axis source code and examine their
serializers/deserializers?

I really can't promise anything, but if you still can't get things to
work I'll try to make time to play myself - but it won't be for a week
at least :-(

Sean

On Fri, 2004-05-14 at 15:05, Luis Pedro wrote:
> Hi Sean,
> 
> U have send a mail to the mailing list about the question that i made
> "passing certificates over soap". Have any ideia how to do it? I'm using
> BeanSerializer of Soap wich is what they recommend, but i'm having a lot of
> trouble because i've to convert every class to bean and in my opinion this
> is a wrong procedure.  
> 
>    -- Luis Pedro
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] RE: [Jsdsi-users] Specific Tag

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

Hmm... The jsdsi mailing list should be being archived. I see that there
are some for jsdsi-dev for Apr. Anything to do with the SF problem of
keeping project stats up to date?

Sean

On Wed, 2004-05-12 at 20:39, Carla Marceau wrote:
> I would think these messages would be being saved and posted automatically
> from https://lists.sourceforge.net/lists/listinfo/jsdsi-users.  However, I
> don't any messages posted there from April or May.
> 
> -----Original Message-----
> From: Sameer Ajmani [mailto:aj...@cs...] 
> Sent: Wednesday, May 12, 2004 3:30 PM
> To: gna...@ab...
> Cc: jsd...@li...
> Subject: Re: [Jsdsi-users] Specific Tag
> 
> 
> I have these messages saved in my personal mail folders.  Would it be sueful
> to post them online somewhere?  Does anyone know an easy way to extract
> messages into HTML from mbox format?
> 
> Sameer
> 
> >>> Thanks, I couldn't find any hash chains or validation trees 
> >>> references in the archives at a first search. I'll try to look at 
> >>> them closer.
> >> Just to clarify... Sameer is talking of the SPKI mailing list, not 
> >> JSDSI.
> >
> > Thanks, that's what I though. I searched:
> >
> > http://www.sandelman.ottawa.on.ca/spki/
> > http://groups.yahoo.com/group/spki/messages
> >
> > guillermo
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by Sleepycat Software
> > Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> > deliver higher performing products faster, at low TCO. 
> > http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> > _______________________________________________
> > Jsdsi-users mailing list
> > Jsd...@li... 
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-users
> 
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Jsdsi-users mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-users
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by Sleepycat Software
> Learn developer strategies Cisco, Motorola, Ericsson & Lucent use to 
> deliver higher performing products faster, at low TCO.
> http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3
> _______________________________________________
> Jsdsi-users mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-users
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] Re: SetTag

[Sameer A. <aj...@cs...>]

Luis,

While math sets can indeed have 0, 1 or more elements, this does not make
sense for SetTags.  A SetTag with zero elements provides no permissions:
it is essentially a NULL_TAG (and should not be allowed to appear in a
cert).  A SetTag with one element is equivalent to just that element; we
want to disallow different syntax for the same meaning, so we choose to
disallow 1-element SetTags.

Sameer

> Sameer,
>
> I've changed everything to work with (tag write) and not with (tag (*
> set write)), but now i've to justify the changes. I want your opinion.
>
> Since (tag (* set write)) is illegal and set is a set of elements liste=
d
> in the *-forms, than can be concluded that 'set' is a special set
> without null or 1-element, because sets like Math sets can have 0, 1 or
> more elements? And (tag (* set write)) =3D (tag write) is just a matter=
 of
> syntax?
>
>    -- Luis Pedro
>
>
> =BB   -----Original Message-----
> =BB   From: Sameer Ajmani [mailto:aj...@cs...]
> =BB   Sent: quarta-feira, 21 de Abril de 2004 12:25
> =BB   To: lp...@ne...
> =BB   Subject: RE: Signature
> =BB
> =BB   Luis,
> =BB
> =BB   There is no inconsistency because (* set write) is illegal.
> =BB    I said (tag (*set write)) =3D (tag write) just to explain it
> =BB   to you; you should always use (tag write) in this case.
> =BB
> =BB   Sameer
> =BB
> =BB   > Sameer,
> =BB   >
> =BB   > Ok, i can leave with that, since i have the sources. But
> =BB   following
> =BB   > your thought, if (* set read write) should satisfy (tag
> =BB   write) or (tag
> =BB   > read) then it should also satisfy (* set read) or (* set
> =BB   write) since
> =BB   > (* set
> =BB   > read) =3D (tag read). At the moment that isn't happening,
> =BB   jsdsi let you
> =BB   > make a certificate with (* set write) but if u want to
> =BB   prove it u have
> =BB   > to use (tag write), something like this:
> =BB   > 	(A B (* set write read)),
> =BB   > 	(B C (* set write))
> =BB   > Now if u want (A C (* set write)) all blows, but if u use
> =BB   (A C (tag
> =BB   > write)) all goes well!!! I think this shouldn't happen since (*=
set
> =BB   > write) =3D (tag write)....something is not consistent here.
> =BB   I also think
> =BB   > this could give space to dangerous interpretations.
> =BB   >
> =BB   > Imagine now, i can think that (* set write read etc) =3D
> =BB   (tag write read
> =BB   > etc)! Is this the same? And if it's the case, 'set'
> =BB   stands for what?
> =BB   >
> =BB   >    -- Luis Pedro
> =BB   >
> =BB   >
> =BB   > =BB   -----Original Message-----
> =BB   > =BB   From: Sameer Ajmani [mailto:aj...@cs...]
> =BB   > =BB   Sent: ter=E7a-feira, 20 de Abril de 2004 20:14
> =BB   > =BB   To: lp...@ne...
> =BB   > =BB   Cc: jsd...@li...
> =BB   > =BB   Subject: RE: Signature
> =BB   > =BB
> =BB   > =BB   Luis,
> =BB   > =BB
> =BB   > =BB   Unfortunately, the semantics you describe below are not
> =BB   > =BB   what we want.  Our semantics are that (tag (*set write)) =
=3D =BB
>> =BB   (tag write).  This is convenient, because it means (tag
> =BB   > =BB   (*set read write)) can satisfy a request for (tag write).=
 =BB
>> =BB   This is also why we want to forbit 1-element sets: if
> =BB   (tag (*set =BB
> =BB   > write)) is disallowed, then we won't have this confusion!
> =BB   > =BB
> =BB   > =BB   Sameer
> =BB   > =BB
> =BB   > =BB   > To me is very important that (tag (* set write)) =3D (t=
ag =BB
>> =BB   (* set write))
> =BB   > =BB   > and not (tag (* set write)) =3D (tag write). Make sense=
 to =BB
>> =BB   me because is
> =BB   > =BB   > a way of distinguish SetTags from StringTags to me SetT=
ag =BB
>  > =BB   is always a
> =BB   > =BB   > SetTag and StringTag can be anything with a String.
> =BB   > =BB   >
> =BB   > =BB   >
> =BB   > =BB   >    -- Luis Pedro
> =BB   > =BB   >
> =BB   > =BB   >
> =BB   > =BB   > =BB   -----Original Message-----
> =BB   > =BB   > =BB   From: Sameer Ajmani [mailto:aj...@cs...]
> =BB   > =BB   > =BB   Sent: ter=E7a-feira, 20 de Abril de 2004 15:59
> =BB   > =BB   > =BB   To: lp...@ne...
> =BB   > =BB   > =BB   Subject: RE: Signature
> =BB   > =BB   > =BB
> =BB   > =BB   > =BB   This is a feature, not a bug :)  SetTag doesn't
> =BB   make sense =BB
> =BB   >> =BB   with just one or zero tags in it.  But I just looked
> =BB   at the =BB   >
> =BB   > =BB   code, and it looks like the code that would fail is
> =BB   > =BB   commented out: =BB
> =BB   > =BB   >           public SetTag(ExprTag[] e)
> =BB   > =BB   > =BB           {
> =BB   > =BB   > =BB   //              if (e =3D=3D null || e.length < 2=
)
> =BB   > =BB   > =BB   //              {
> =BB   > =BB   > =BB   //                      throw new
> =BB   > =BB   > =BB   IllegalArgumentException("element array
> =BB   > =BB   > =BB   must c
> =BB   > =BB   > =BB   ontain at least 2 elements");
> =BB   > =BB   > =BB   //              }
> =BB   > =BB   > =BB                   elements =3D Arrays.asList(e);
> =BB   > =BB   > =BB           }
> =BB   > =BB   > =BB
> =BB   > =BB   > =BB   Did it get uncommented in your copy?
> =BB   > =BB   > =BB   Sameer
> =BB   > =BB   > =BB
> =BB   > =BB   > =BB
> =BB   > =BB   > =BB   > Sameer,
> =BB   > =BB   > =BB   >
> =BB   > =BB   > =BB   > The problem isn't the Signature wich is working=
 fine.
> =BB   > =BB   > =BB   Somehow someone
> =BB   > =BB   > =BB   > here or even me let the the code with the SetTa=
g that
> =BB   > =BB   > =BB   prevents from
> =BB   > =BB   > =BB   > using just one tag inside it and that is
> =BB   breaking all!! =BB
> =BB   >> =BB   The latest
> =BB   > =BB   > =BB   > code of SetTag as the support for just one tag?
> =BB   > =BB   > =BB   >
> =BB   > =BB   > =BB   >    -- Luis Pedro
> =BB   > =BB   > =BB   >
> =BB   > =BB   > =BB   >
> =BB   > =BB   > =BB   > =BB   -----Original Message-----
> =BB   > =BB   > =BB   > =BB   From: Sameer Ajmani [mailto:ajmani@csail.=
mit.edu]
> =BB   > =BB   > =BB   > =BB   Sent: ter=E7a-feira, 20 de Abril de 2004 =
14:42 =BB   >
> =BB   > =BB   > =BB   To: lp...@ne...
> =BB   > =BB   > =BB   > =BB   Subject: Re: Signature
> =BB   > =BB   > =BB   > =BB
> =BB   > =BB   > =BB   > =BB   I made some changes to Signature on 2004/=
03/26 =BB
>> =BB   to add some =BB
> =BB   > =BB   >> =BB   convenience methods.  The tests all pass, so I
> =BB   > =BB   assume those =BB   >
> =BB   > =BB   > =BB   are okay.  Are you sure it's Signature that is fa=
iling?
> =BB   > =BB   > =BB   > =BB
> =BB   > =BB   > =BB   > =BB   > Since the proofs work with Cert and not
> =BB   > =BB   Certificate is =BB   >
> =BB   > =BB   > =BB   the Signature
> =BB   > =BB   > =BB   > =BB   > relevant for the proof?
> =BB   > =BB   > =BB   > =BB
> =BB   > =BB   > =BB   > =BB   The Signature is relevant: it's your only
> =BB   > =BB   assurance that =BB   >
> =BB   > =BB   > =BB   the issuer actually created the Certs in the Proo=
f. =BB
>> =BB   > =BB   > =BB   Without a Signature, anyone could create a
> =BB   > =BB   valid Cert that =BB
> =BB   > =BB   >> =BB   says anything, which is no security at all!
> =BB   > =BB   > =BB   > =BB
> =BB   > =BB   > =BB   > =BB   Sameer
> =BB   > =BB   > =BB   > =BB
> =BB   > =BB   > =BB   > =BB   > Sameer,
> =BB   > =BB   > =BB   > =BB   >
> =BB   > =BB   > =BB   > =BB   > Have u made changes on Signature? Since=
 this =BB
>> =BB   morning i'm =BB
> =BB   > =BB   >> =BB   not able to
> =BB   > =BB   > =BB   > =BB   > proof certs. Since the proofs work with
> =BB   Cert and not =BB
> =BB   >   > =BB   > =BB   Certificate is
> =BB   > =BB   > =BB   > =BB   > the Signature relevant for the proof?
> =BB   > =BB   > =BB   > =BB   >
> =BB   > =BB   > =BB   > =BB   >    -- Luis Pedro
> =BB   > =BB   > =BB   > =BB
> =BB   > =BB   > =BB   > =BB
> =BB   > =BB   > =BB   > =BB   http://ajmani.net
> =BB   > =BB   > =BB   > =BB
> =BB   > =BB   > =BB   > =BB
> =BB   > =BB   > =BB   > =BB
> =BB   > =BB   > =BB   > =BB
> =BB   > =BB   > =BB
> =BB   > =BB   > =BB
> =BB   > =BB   > =BB   http://ajmani.net
> =BB   > =BB   > =BB
> =BB   > =BB   > =BB
> =BB   > =BB   > =BB
> =BB   > =BB   > =BB
> =BB   > =BB
> =BB   > =BB
> =BB   > =BB   http://ajmani.net
> =BB   > =BB
> =BB   > =BB
> =BB   > =BB
> =BB   > =BB
> =BB
> =BB
> =BB   http://ajmani.net
> =BB
> =BB
> =BB


http://ajmani.net

[Jsdsi-devel] RE: Signature

[Sameer A. <aj...@cs...>]

Luis,

Unfortunately, the semantics you describe below are not what we want.  Ou=
r
semantics are that (tag (*set write)) =3D (tag write).  This is convenien=
t,
because it means (tag (*set read write)) can satisfy a request for (tag
write).  This is also why we want to forbit 1-element sets: if (tag (*set
write)) is disallowed, then we won't have this confusion!

Sameer

> To me is very important that (tag (* set write)) =3D (tag (* set write)=
)
> and not (tag (* set write)) =3D (tag write). Make sense to me because i=
s a
> way of distinguish SetTags from StringTags to me SetTag is always a
> SetTag and StringTag can be anything with a String.
>
>
>    -- Luis Pedro
>
>
> =BB   -----Original Message-----
> =BB   From: Sameer Ajmani [mailto:aj...@cs...]
> =BB   Sent: ter=E7a-feira, 20 de Abril de 2004 15:59
> =BB   To: lp...@ne...
> =BB   Subject: RE: Signature
> =BB
> =BB   This is a feature, not a bug :)  SetTag doesn't make sense
> =BB   with just one or zero tags in it.  But I just looked at the
> =BB   code, and it looks like the code that would fail is commented out=
: =BB
>           public SetTag(ExprTag[] e)
> =BB           {
> =BB   //              if (e =3D=3D null || e.length < 2)
> =BB   //              {
> =BB   //                      throw new
> =BB   IllegalArgumentException("element array
> =BB   must c
> =BB   ontain at least 2 elements");
> =BB   //              }
> =BB                   elements =3D Arrays.asList(e);
> =BB           }
> =BB
> =BB   Did it get uncommented in your copy?
> =BB   Sameer
> =BB
> =BB
> =BB   > Sameer,
> =BB   >
> =BB   > The problem isn't the Signature wich is working fine.
> =BB   Somehow someone
> =BB   > here or even me let the the code with the SetTag that
> =BB   prevents from
> =BB   > using just one tag inside it and that is breaking all!!
> =BB   The latest
> =BB   > code of SetTag as the support for just one tag?
> =BB   >
> =BB   >    -- Luis Pedro
> =BB   >
> =BB   >
> =BB   > =BB   -----Original Message-----
> =BB   > =BB   From: Sameer Ajmani [mailto:aj...@cs...]
> =BB   > =BB   Sent: ter=E7a-feira, 20 de Abril de 2004 14:42
> =BB   > =BB   To: lp...@ne...
> =BB   > =BB   Subject: Re: Signature
> =BB   > =BB
> =BB   > =BB   I made some changes to Signature on 2004/03/26 to add som=
e =BB
>> =BB   convenience methods.  The tests all pass, so I assume those =BB =
  >
> =BB   are okay.  Are you sure it's Signature that is failing?
> =BB   > =BB
> =BB   > =BB   > Since the proofs work with Cert and not Certificate is =
=BB   >
> =BB   the Signature
> =BB   > =BB   > relevant for the proof?
> =BB   > =BB
> =BB   > =BB   The Signature is relevant: it's your only assurance that =
=BB   >
> =BB   the issuer actually created the Certs in the Proof.
> =BB   > =BB   Without a Signature, anyone could create a valid Cert tha=
t =BB
>> =BB   says anything, which is no security at all!
> =BB   > =BB
> =BB   > =BB   Sameer
> =BB   > =BB
> =BB   > =BB   > Sameer,
> =BB   > =BB   >
> =BB   > =BB   > Have u made changes on Signature? Since this morning i'=
m =BB
>> =BB   not able to
> =BB   > =BB   > proof certs. Since the proofs work with Cert and not
> =BB   > =BB   Certificate is
> =BB   > =BB   > the Signature relevant for the proof?
> =BB   > =BB   >
> =BB   > =BB   >    -- Luis Pedro
> =BB   > =BB
> =BB   > =BB
> =BB   > =BB   http://ajmani.net
> =BB   > =BB
> =BB   > =BB
> =BB   > =BB
> =BB   > =BB
> =BB
> =BB
> =BB   http://ajmani.net
> =BB
> =BB
> =BB
> =BB


http://ajmani.net

Re: [Jsdsi-devel] Principal.getURIs()

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

Cool, 

I'll do the necessary.

Sean

On Mon, 2004-04-05 at 17:04, Sameer Ajmani wrote:
> Sounds fine.
> 
> > Guys...
> >
> >
> > How do we feel about making sdsi.Principal declare the method:
> >
> > public URI[] getURIs();
> >
> > ?
> >
> > jsdsi.PublicKey supports this method anyway, and jsdsi.PublicKeyHash can
> > easily delegate to its enclosed jsdsi.Hash object.
> >
> > Doing so means that if one has a jsdsi.Principal, it is extremely easy
> > to get the list of locator URI's for where Certificates might be found
> > empowering the Principal.
> >
> > Thoughts,
> >
> >
> > Sean
> >
> >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > This SF.Net email is sponsored by: IBM Linux Tutorials
> > Free Linux tutorial presented by Daniel Robbins, President and CEO of
> > GenToo technologies. Learn everything from fundamentals to system
> > administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com