jsdsi-devel — JSDSI Developers

Re: [Jsdsi-devel] URI's instead of URL's

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

Yes, that sounds good.

Thanks!
Sameer

> Sameer,
>
> I'm going to do a utility KeyPairFactory class(es) for assisting with
> generating KeyPairs (in light of yesterday's discussion).
>
> Whilst I'm at it would you like me to use URI's (instead of URL's) and
> in jsdsi.PublicKey and jsdsi.RSAPublicKey mark the URL methods as
> deprecated?
>
> We can then do similar as we work on other parts of the system.
>
> (I'm assuming you want to eventually replace the URL's after our
> previous discussion on the topic)
>
> 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

[Jsdsi-devel] URI's instead of URL's

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

Sameer,

I'm going to do a utility KeyPairFactory class(es) for assisting with
generating KeyPairs (in light of yesterday's discussion). 

Whilst I'm at it would you like me to use URI's (instead of URL's) and
in jsdsi.PublicKey and jsdsi.RSAPublicKey mark the URL methods as
deprecated?

We can then do similar as we work on other parts of the system.

(I'm assuming you want to eventually replace the URL's after our
previous discussion on the topic)

Sean

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

Re: [Jsdsi-devel] Re: [Jsdsi-users] Sun KeyPairGeneratory

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

>> We could provide a separate convenience class that generates RSA key
>> pairs and handles the initialization, if you want.
> Agree. Think that is the best route.
>
> I'll do it tomorrow if that is ok with you.

Soudns great.

> Any more thoughts on the SetTag issues?

If we disallow singleton and empty SetTags, we need to esnure they cannot
be created by any of the intersect methods or SetTag constructors.  In the
case of intersect, a singleton set should become just a tag, and an empty
set should become NULL_TAG.  The SetTag constructor should throw an
exception if its parameter is a List that has fewer than two elements.

We need to think carefully about how SetTag intersects with RangeTag and
PrefixTag.  RangeTag is simply a compact representation of a set: (* range
gt "0" lt "5") is the same as (* set "1" "2" "3" "4").  The only
difference if that RangeTag can represent infinite sets.  PrefixTag is
similar, except it can only represent sets of strings.

The current intersect code doesn't handle this correctly at all: a set
intersects a range simply by testing whether the RangeTag is implied by
any member of the set!  Probably the whole intersection framework needs to
be rethought.  We might look at Jon Howell's Snowflake code for
inspiration (though I'm not sure whether his code does this right,
either).

If you change SetTag, please also update TagTest so that it keeps working.

>> >> > On Mon, 2004-03-08 at 16:33, Sameer Ajmani wrote:
>> >> >> Rethinking this, we should check that this is really a bug in
>> Sun's
>> >> code and not ours.  Could you try creating keys using their
>> >> generator directly?
>> >> >>  And could you check to see whether this is a known bug?
>> >> >>
>> >> >> For JSDSI, we should be careful about automatically initializing
>> >> anything.
>> >> >>  I hesitate to add this initialization workaround to the API.
>> >> >>
>> >> >> Sameer
>> >> >>
>> >> >> > How should we decide on this?
>> >> >> >
>> >> >> > Shall we just say 512 as that is what Sun says is theres?
>> >> >> >
>> >> >> > Sean
>> >> >> >
>> >> >> > (if you are happy with this I can code it up)
>> >> >> >
>> >> >> >
>> >> >> > On Mon, 2004-03-08 at 16:00, Sameer Ajmani wrote:
>> >> >> >> It seems better for create() without a key size to do
>> initialize
>> >> >> with some default key size.
>> >> >> >>
>> >> >> >> Sameer
>> >> >> >>
>> >> >> >> > I know - very wierd.
>> >> >> >> >
>> >> >> >> > I first noticed it about a year ago and so also specified a
>> >> >> >> key-size. I read and read the javadocs and assumed I was
>> doing
>> >> >> something odd, so thought I'd come back to it. Finally got round
>> to
>> >> it this w/e and can't figure out why!
>> >> >> >> >
>> >> >> >> > It's good to know that someone else is seeing it.
>> >> >> >> >
>> >> >> >> > What I propose is to add 2 constructors to
>> jsdsi.RSAPublicKey:
>> >> >> >> >
>> >> >> >> > /**
>> >> >> >> >  * Creates a new RSA key pair whose public key is a {@link
>> >> >> >> > jsdsi.Principal}.
>> >> >> >> >  * @param a the specific RSA algorithm to use
>> >> >> >> >  * @param provider the provider to use
>> >> >> >> >  * @param size the key size to create
>> >> >> >> >  * @param uris an array of uris (<code>java.net.URL</code>)
>> >> >> related
>> >> >> >> to
>> >> >> >> > this key pair (may be <code>null</code>)
>> >> >> >> >  * @return
>> >> >> >> >  * @throws NoSuchAlgorithmException
>> >> >> >> >  * @throws NoSuchProviderException
>> >> >> >> >  */
>> >> >> >> > public static KeyPair create(String a, String provider, int
>> >> size,
>> >> >> >> URL[] uris)
>> >> >> >> > throws NoSuchAlgorithmException, NoSuchProviderException;
>> >> >> >> >
>> >> >> >> > and
>> >> >> >> >
>> >> >> >> > /**
>> >> >> >> >  * Creates a new RSA key pair whose public key is a {@link
>> >> >> >> > jsdsi.Principal}.
>> >> >> >> >  * @param a the specific RSA algorithm to use
>> >> >> >> >  * @param provider the provider to use
>> >> >> >> >  * @param uris an array of uris (<code>java.net.URL</code>)
>> >> >> related
>> >> >> >> to
>> >> >> >> > this key pair
>> >> >> >> >  * @return
>> >> >> >> >  * @throws NoSuchAlgorithmException
>> >> >> >> >  * @throws NoSuchProviderException
>> >> >> >> >  */
>> >> >> >> > public static KeyPair create(String a, String provider,
>> URL[]
>> >> >> uris)
>> >> >> >> >   throws NoSuchAlgorithmException, NoSuchProviderException;
>> >> >> >> >
>> >> >> >> > These will allow developers to specify a key size
>> themselves.
>> >> >> I'll
>> >> >> >> then put a WARNING on the constructors that don't specify a
>> key
>> >> >> size about issues noticed with the Sun provider.
>> >> >> >> >
>> >> >> >> > How does that sound?
>> >> >> >> >
>> >> >> >> > Regards,
>> >> >> >> >
>> >> >> >> > Sean
>> >> >> >> >
>> >> >> >> > PS. By the way I have the parsing public key uri code ready
>> >> for
>> >> >> CVS.
>> >> >> >> Happy for a 'simple' ParsingTest class that tests it to go
>> into
>> >> CVS
>> >> >> too?
>> >> >> >> >
>> >> >> >> >
>> >> >> >> > On Mon, 2004-03-08 at 14:36, Sameer Ajmani wrote:
>> >> >> >> >> That's very weird.  According to the JDK javadoc, there
>> >> should
>> >> >> be a
>> >> >> >> default iniitalization:
>> >> >> >> >>
>> >> >> >> >> In case the client does not explicitly initialize the
>> >> >> >> KeyPairGenerator (via a call to an initialize method), each
>> >> provider must supply (and document) a default initialization. For
>> >> >> example, the Sun provider uses a default modulus size (keysize)
>> of
>> >> 1024 bits.
>> >> >> >> >>
>> >> >> >> >> Perhaps this is happening because the generator is using a
>> >> >> Random
>> >> >> >> object rather than a SecureRandom object.  Random seeds
>> itself
>> >> >> using the current time, which for two subsequent calls, may be
>> the
>> >> same.
>> >> >> >> >>
>> >> >> >> >> Please check in your fix, and thanks for catching this!
>> >> Sameer
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> > Hi all,
>> >> >> >> >> >
>> >> >> >> >> > Anyone seen this before:
>> >> >> >> >> >
>> >> >> >> >> > (I've got my default KeyPairGenerator Provider to be
>> sun.security.provider.Sun)
>> >> >> >> >> >
>> >> >> >> >> > All my KeyPairs being generated are the same (equal) ...
>> >> >> >> >> >
>> >> >> >> >> > Try this:
>> >> >> >> >> >
>> >> >> >> >> > KeyPair kp1 = jsdsi.RSAPublicKey.create("RSA");
>> >> >> >> >> > KeyPair kp2 = jsdsi.RSAPublicKey.create("RSA");
>> >> >> >> >> >
>> >> >> >> >> > System.out.println( kp1.getPublic().toString() );
>> >> >> >> >> > System.out.println( kp2.getPublic().toString() );
>> >> >> >> >> >
>> >> >> >> >> >
>> >> >> >> >> > (I've found that if I insert a call to
>> initialise(KEY_SIZE)
>> >> in
>> >> >> >> the
>> >> >> >> >> jsdsi.RSAKeyPair.create(..) all is cool)
>> >> >> >> >> >
>> >> >> >> >> > Any ideas?
>> >> >> >> >> >
>> >> >> >> >> > 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-users mailing list
>> >> >> >> >> > Jsd...@li...
>> >> >> >> >> > https://lists.sourceforge.net/lists/listinfo/jsdsi-users
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> http://ajmani.net
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >>
>> >> >> >> >> -------------------------------------------------------
>> 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-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
>> >> >> >>
>> >> >> >>
>> >> >> >> http://ajmani.net
>> >> >> >>
>> >> >> > --
>> >> >> > Dr. Sean Radford, MBBS, MSc
>> >> >> > sra...@ae...
>> >> >> > http://www.aegeus-technology.com
>> >> >>
>> >> >>
>> >> >> http://ajmani.net
>> >> >>
>> >> > --
>> >> > Dr. Sean Radford, MBBS, MSc
>> >> > sra...@ae...
>> >> > http://www.aegeus-technology.com
>> >> >
>> >> >
>> >> >
>> >> > -------------------------------------------------------
>> >> > 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
>> >
>> >
>> >
>> > -------------------------------------------------------
>> > 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
>
>
>
> -------------------------------------------------------
> 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

Re: [Jsdsi-devel] Re: [Jsdsi-users] Sun KeyPairGeneratory

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

On Mon, 2004-03-08 at 19:56, Sameer Ajmani wrote:
> >> > I think we need to add overloaded create() methods to allow keySize,
> >> SecureRandom, and java.security.spec.AlgorithmParameterSpec. How
> >> about one that takes a KeyPairGenerator instance too?
> >>
> >> At this point, it might make more sense to create our own
> >> jsdsi.RSAKeyPairGeneratorSpi that handles initialization correctly.
> > Not sure how this helps exactly. How does that cater for people who need
> > to specify alternate Providers?
> 
> Fair point.  I'm just trying to avoid polluting the JSDSI API because of a
> specific provider bug.  An alternative would be to deprecate RSAKey.create
> and require people to use the
> RSAPublicKey(java.security.interfaces.RSAPublicKey k) constructor instead.
>  This way, we move all the KeyGenerator troubles out of our code.
> 
> We could provide a separate convenience class that generates RSA key pairs
> and handles the initialization, if you want.
Agree. Think that is the best route.

I'll do it tomorrow if that is ok with you.

Any more thoughts on the SetTag issues?

> Sameer
> 
> >
> > Sean
> >
> >> Sameer
> >>
> >> >
> >> > Sean
> >> >
> >> >
> >> >
> >> > On Mon, 2004-03-08 at 16:33, Sameer Ajmani wrote:
> >> >> Rethinking this, we should check that this is really a bug in Sun's
> >> code and not ours.  Could you try creating keys using their
> >> generator directly?
> >> >>  And could you check to see whether this is a known bug?
> >> >>
> >> >> For JSDSI, we should be careful about automatically initializing
> >> anything.
> >> >>  I hesitate to add this initialization workaround to the API.
> >> >>
> >> >> Sameer
> >> >>
> >> >> > How should we decide on this?
> >> >> >
> >> >> > Shall we just say 512 as that is what Sun says is theres?
> >> >> >
> >> >> > Sean
> >> >> >
> >> >> > (if you are happy with this I can code it up)
> >> >> >
> >> >> >
> >> >> > On Mon, 2004-03-08 at 16:00, Sameer Ajmani wrote:
> >> >> >> It seems better for create() without a key size to do initialize
> >> >> with some default key size.
> >> >> >>
> >> >> >> Sameer
> >> >> >>
> >> >> >> > I know - very wierd.
> >> >> >> >
> >> >> >> > I first noticed it about a year ago and so also specified a
> >> >> >> key-size. I read and read the javadocs and assumed I was doing
> >> >> something odd, so thought I'd come back to it. Finally got round to
> >> it this w/e and can't figure out why!
> >> >> >> >
> >> >> >> > It's good to know that someone else is seeing it.
> >> >> >> >
> >> >> >> > What I propose is to add 2 constructors to jsdsi.RSAPublicKey:
> >> >> >> >
> >> >> >> > /**
> >> >> >> >  * Creates a new RSA key pair whose public key is a {@link
> >> >> >> > jsdsi.Principal}.
> >> >> >> >  * @param a the specific RSA algorithm to use
> >> >> >> >  * @param provider the provider to use
> >> >> >> >  * @param size the key size to create
> >> >> >> >  * @param uris an array of uris (<code>java.net.URL</code>)
> >> >> related
> >> >> >> to
> >> >> >> > this key pair (may be <code>null</code>)
> >> >> >> >  * @return
> >> >> >> >  * @throws NoSuchAlgorithmException
> >> >> >> >  * @throws NoSuchProviderException
> >> >> >> >  */
> >> >> >> > public static KeyPair create(String a, String provider, int
> >> size,
> >> >> >> URL[] uris)
> >> >> >> > throws NoSuchAlgorithmException, NoSuchProviderException;
> >> >> >> >
> >> >> >> > and
> >> >> >> >
> >> >> >> > /**
> >> >> >> >  * Creates a new RSA key pair whose public key is a {@link
> >> >> >> > jsdsi.Principal}.
> >> >> >> >  * @param a the specific RSA algorithm to use
> >> >> >> >  * @param provider the provider to use
> >> >> >> >  * @param uris an array of uris (<code>java.net.URL</code>)
> >> >> related
> >> >> >> to
> >> >> >> > this key pair
> >> >> >> >  * @return
> >> >> >> >  * @throws NoSuchAlgorithmException
> >> >> >> >  * @throws NoSuchProviderException
> >> >> >> >  */
> >> >> >> > public static KeyPair create(String a, String provider, URL[]
> >> >> uris)
> >> >> >> >   throws NoSuchAlgorithmException, NoSuchProviderException;
> >> >> >> >
> >> >> >> > These will allow developers to specify a key size themselves.
> >> >> I'll
> >> >> >> then put a WARNING on the constructors that don't specify a key
> >> >> size about issues noticed with the Sun provider.
> >> >> >> >
> >> >> >> > How does that sound?
> >> >> >> >
> >> >> >> > Regards,
> >> >> >> >
> >> >> >> > Sean
> >> >> >> >
> >> >> >> > PS. By the way I have the parsing public key uri code ready
> >> for
> >> >> CVS.
> >> >> >> Happy for a 'simple' ParsingTest class that tests it to go into
> >> CVS
> >> >> too?
> >> >> >> >
> >> >> >> >
> >> >> >> > On Mon, 2004-03-08 at 14:36, Sameer Ajmani wrote:
> >> >> >> >> That's very weird.  According to the JDK javadoc, there
> >> should
> >> >> be a
> >> >> >> default iniitalization:
> >> >> >> >>
> >> >> >> >> In case the client does not explicitly initialize the
> >> >> >> KeyPairGenerator (via a call to an initialize method), each
> >> provider must supply (and document) a default initialization.
> >> For
> >> >> example, the Sun provider uses a default modulus size (keysize) of
> >> 1024 bits.
> >> >> >> >>
> >> >> >> >> Perhaps this is happening because the generator is using a
> >> >> Random
> >> >> >> object rather than a SecureRandom object.  Random seeds itself
> >> >> using the current time, which for two subsequent calls, may be the
> >> same.
> >> >> >> >>
> >> >> >> >> Please check in your fix, and thanks for catching this!
> >> Sameer
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> > Hi all,
> >> >> >> >> >
> >> >> >> >> > Anyone seen this before:
> >> >> >> >> >
> >> >> >> >> > (I've got my default KeyPairGenerator Provider to be
> >> >> >> >> > sun.security.provider.Sun)
> >> >> >> >> >
> >> >> >> >> > All my KeyPairs being generated are the same (equal) ...
> >> >> >> >> >
> >> >> >> >> > Try this:
> >> >> >> >> >
> >> >> >> >> > KeyPair kp1 = jsdsi.RSAPublicKey.create("RSA");
> >> >> >> >> > KeyPair kp2 = jsdsi.RSAPublicKey.create("RSA");
> >> >> >> >> >
> >> >> >> >> > System.out.println( kp1.getPublic().toString() );
> >> >> >> >> > System.out.println( kp2.getPublic().toString() );
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> > (I've found that if I insert a call to initialise(KEY_SIZE)
> >> in
> >> >> >> the
> >> >> >> >> jsdsi.RSAKeyPair.create(..) all is cool)
> >> >> >> >> >
> >> >> >> >> > Any ideas?
> >> >> >> >> >
> >> >> >> >> > 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-users mailing list
> >> >> >> >> > Jsd...@li...
> >> >> >> >> > https://lists.sourceforge.net/lists/listinfo/jsdsi-users
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> http://ajmani.net
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >>
> >> >> >> >> ------------------------------------------------------- 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-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
> >> >> >>
> >> >> >>
> >> >> >> http://ajmani.net
> >> >> >>
> >> >> > --
> >> >> > Dr. Sean Radford, MBBS, MSc
> >> >> > sra...@ae...
> >> >> > http://www.aegeus-technology.com
> >> >>
> >> >>
> >> >> http://ajmani.net
> >> >>
> >> > --
> >> > Dr. Sean Radford, MBBS, MSc
> >> > sra...@ae...
> >> > http://www.aegeus-technology.com
> >> >
> >> >
> >> >
> >> > -------------------------------------------------------
> >> > 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
> >
> >
> >
> > -------------------------------------------------------
> > 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

Re: [Jsdsi-devel] Re: [Jsdsi-users] Sun KeyPairGeneratory

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

On Mon, 2004-03-08 at 18:05, Sameer Ajmani wrote:
> > Well, can't find any related bugs mentioned anywhere but here's what I
> > notice when creating KeyPairs directly using the Sun Provider:
> >
> > 1. Not calling initialise(KEY_SIZE)
> >
> > The keys generated by the instance of KeyPairGenerator is predictable,
> > i.e. follow a set pattern/order.
> 
> I'm pretty sure this means its using Random() with some deterministic seed
> (that's unrelated to time, because I get the same value at different
> times).
> 
> You shoudl submit this as a bug to Sun.  Be sure to point out the part of
> the Javadocs that says that not calling initialize is okay.  Also be sure
> you've tested this the the latest JDK.
Ok, will do.


> 
> > I think we need to add overloaded create() methods to allow keySize,
> > SecureRandom, and java.security.spec.AlgorithmParameterSpec. How about
> > one that takes a KeyPairGenerator instance too?
> 
> At this point, it might make more sense to create our own
> jsdsi.RSAKeyPairGeneratorSpi that handles initialization correctly.
Not sure how this helps exactly. How does that cater for people who need to specify
alternate Providers?

Sean

> Sameer
> 
> >
> > Sean
> >
> >
> >
> > On Mon, 2004-03-08 at 16:33, Sameer Ajmani wrote:
> >> Rethinking this, we should check that this is really a bug in Sun's
> >> code and not ours.  Could you try creating keys using their generator
> >> directly?
> >>  And could you check to see whether this is a known bug?
> >>
> >> For JSDSI, we should be careful about automatically initializing
> >> anything.
> >>  I hesitate to add this initialization workaround to the API.
> >>
> >> Sameer
> >>
> >> > How should we decide on this?
> >> >
> >> > Shall we just say 512 as that is what Sun says is theres?
> >> >
> >> > Sean
> >> >
> >> > (if you are happy with this I can code it up)
> >> >
> >> >
> >> > On Mon, 2004-03-08 at 16:00, Sameer Ajmani wrote:
> >> >> It seems better for create() without a key size to do initialize
> >> with some default key size.
> >> >>
> >> >> Sameer
> >> >>
> >> >> > I know - very wierd.
> >> >> >
> >> >> > I first noticed it about a year ago and so also specified a
> >> >> key-size. I read and read the javadocs and assumed I was doing
> >> something odd, so thought I'd come back to it. Finally got round to
> >> it this w/e and can't figure out why!
> >> >> >
> >> >> > It's good to know that someone else is seeing it.
> >> >> >
> >> >> > What I propose is to add 2 constructors to jsdsi.RSAPublicKey:
> >> >> >
> >> >> > /**
> >> >> >  * Creates a new RSA key pair whose public key is a {@link
> >> >> > jsdsi.Principal}.
> >> >> >  * @param a the specific RSA algorithm to use
> >> >> >  * @param provider the provider to use
> >> >> >  * @param size the key size to create
> >> >> >  * @param uris an array of uris (<code>java.net.URL</code>)
> >> related
> >> >> to
> >> >> > this key pair (may be <code>null</code>)
> >> >> >  * @return
> >> >> >  * @throws NoSuchAlgorithmException
> >> >> >  * @throws NoSuchProviderException
> >> >> >  */
> >> >> > public static KeyPair create(String a, String provider, int size,
> >> >> URL[] uris)
> >> >> > throws NoSuchAlgorithmException, NoSuchProviderException;
> >> >> >
> >> >> > and
> >> >> >
> >> >> > /**
> >> >> >  * Creates a new RSA key pair whose public key is a {@link
> >> >> > jsdsi.Principal}.
> >> >> >  * @param a the specific RSA algorithm to use
> >> >> >  * @param provider the provider to use
> >> >> >  * @param uris an array of uris (<code>java.net.URL</code>)
> >> related
> >> >> to
> >> >> > this key pair
> >> >> >  * @return
> >> >> >  * @throws NoSuchAlgorithmException
> >> >> >  * @throws NoSuchProviderException
> >> >> >  */
> >> >> > public static KeyPair create(String a, String provider, URL[]
> >> uris)
> >> >> >   throws NoSuchAlgorithmException, NoSuchProviderException;
> >> >> >
> >> >> > These will allow developers to specify a key size themselves.
> >> I'll
> >> >> then put a WARNING on the constructors that don't specify a key
> >> size about issues noticed with the Sun provider.
> >> >> >
> >> >> > How does that sound?
> >> >> >
> >> >> > Regards,
> >> >> >
> >> >> > Sean
> >> >> >
> >> >> > PS. By the way I have the parsing public key uri code ready for
> >> CVS.
> >> >> Happy for a 'simple' ParsingTest class that tests it to go into CVS
> >> too?
> >> >> >
> >> >> >
> >> >> > On Mon, 2004-03-08 at 14:36, Sameer Ajmani wrote:
> >> >> >> That's very weird.  According to the JDK javadoc, there should
> >> be a
> >> >> default iniitalization:
> >> >> >>
> >> >> >> In case the client does not explicitly initialize the
> >> >> KeyPairGenerator (via a call to an initialize method), each
> >> >> provider must supply (and document) a default initialization. For
> >> example, the Sun provider uses a default modulus size (keysize) of
> >> 1024 bits.
> >> >> >>
> >> >> >> Perhaps this is happening because the generator is using a
> >> Random
> >> >> object rather than a SecureRandom object.  Random seeds itself
> >> using the current time, which for two subsequent calls, may be the
> >> same.
> >> >> >>
> >> >> >> Please check in your fix, and thanks for catching this!
> >> >> >> Sameer
> >> >> >>
> >> >> >>
> >> >> >> > Hi all,
> >> >> >> >
> >> >> >> > Anyone seen this before:
> >> >> >> >
> >> >> >> > (I've got my default KeyPairGenerator Provider to be
> >> >> >> > sun.security.provider.Sun)
> >> >> >> >
> >> >> >> > All my KeyPairs being generated are the same (equal) ...
> >> >> >> >
> >> >> >> > Try this:
> >> >> >> >
> >> >> >> > KeyPair kp1 = jsdsi.RSAPublicKey.create("RSA");
> >> >> >> > KeyPair kp2 = jsdsi.RSAPublicKey.create("RSA");
> >> >> >> >
> >> >> >> > System.out.println( kp1.getPublic().toString() );
> >> >> >> > System.out.println( kp2.getPublic().toString() );
> >> >> >> >
> >> >> >> >
> >> >> >> > (I've found that if I insert a call to initialise(KEY_SIZE) in
> >> >> the
> >> >> >> jsdsi.RSAKeyPair.create(..) all is cool)
> >> >> >> >
> >> >> >> > Any ideas?
> >> >> >> >
> >> >> >> > 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-users mailing list
> >> >> >> > Jsd...@li...
> >> >> >> > https://lists.sourceforge.net/lists/listinfo/jsdsi-users
> >> >> >>
> >> >> >>
> >> >> >> http://ajmani.net
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >>
> >> >> >> -------------------------------------------------------
> >> >> >> 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-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
> >> >>
> >> >>
> >> >> http://ajmani.net
> >> >>
> >> > --
> >> > Dr. Sean Radford, MBBS, MSc
> >> > sra...@ae...
> >> > http://www.aegeus-technology.com
> >>
> >>
> >> http://ajmani.net
> >>
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > 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

[Jsdsi-devel] Re: [Jsdsi-users] Sun KeyPairGeneratory

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

Well, can't find any related bugs mentioned anywhere but here's what I
notice when creating KeyPairs directly using the Sun Provider:

1. Not calling initialise(KEY_SIZE)

The keys generated by the instance of KeyPairGenerator is predictable,
i.e. follow a set pattern/order.

2. Calling initialise(KEY_SIZE)

The keys generated seem random.

I think we need to add overloaded create() methods to allow keySize,
SecureRandom, and java.security.spec.AlgorithmParameterSpec. How about
one that takes a KeyPairGenerator instance too?

Sean



On Mon, 2004-03-08 at 16:33, Sameer Ajmani wrote:
> Rethinking this, we should check that this is really a bug in Sun's code
> and not ours.  Could you try creating keys using their generator directly?
>  And could you check to see whether this is a known bug?
> 
> For JSDSI, we should be careful about automatically initializing anything.
>  I hesitate to add this initialization workaround to the API.
> 
> Sameer
> 
> > How should we decide on this?
> >
> > Shall we just say 512 as that is what Sun says is theres?
> >
> > Sean
> >
> > (if you are happy with this I can code it up)
> >
> >
> > On Mon, 2004-03-08 at 16:00, Sameer Ajmani wrote:
> >> It seems better for create() without a key size to do initialize with
> >> some default key size.
> >>
> >> Sameer
> >>
> >> > I know - very wierd.
> >> >
> >> > I first noticed it about a year ago and so also specified a
> >> key-size. I read and read the javadocs and assumed I was doing
> >> something odd, so thought I'd come back to it. Finally got round to
> >> it this w/e and can't figure out why!
> >> >
> >> > It's good to know that someone else is seeing it.
> >> >
> >> > What I propose is to add 2 constructors to jsdsi.RSAPublicKey:
> >> >
> >> > /**
> >> >  * Creates a new RSA key pair whose public key is a {@link
> >> > jsdsi.Principal}.
> >> >  * @param a the specific RSA algorithm to use
> >> >  * @param provider the provider to use
> >> >  * @param size the key size to create
> >> >  * @param uris an array of uris (<code>java.net.URL</code>) related
> >> to
> >> > this key pair (may be <code>null</code>)
> >> >  * @return
> >> >  * @throws NoSuchAlgorithmException
> >> >  * @throws NoSuchProviderException
> >> >  */
> >> > public static KeyPair create(String a, String provider, int size,
> >> URL[] uris)
> >> > throws NoSuchAlgorithmException, NoSuchProviderException;
> >> >
> >> > and
> >> >
> >> > /**
> >> >  * Creates a new RSA key pair whose public key is a {@link
> >> > jsdsi.Principal}.
> >> >  * @param a the specific RSA algorithm to use
> >> >  * @param provider the provider to use
> >> >  * @param uris an array of uris (<code>java.net.URL</code>) related
> >> to
> >> > this key pair
> >> >  * @return
> >> >  * @throws NoSuchAlgorithmException
> >> >  * @throws NoSuchProviderException
> >> >  */
> >> > public static KeyPair create(String a, String provider, URL[] uris)
> >> >   throws NoSuchAlgorithmException, NoSuchProviderException;
> >> >
> >> > These will allow developers to specify a key size themselves. I'll
> >> then put a WARNING on the constructors that don't specify a key size
> >> about issues noticed with the Sun provider.
> >> >
> >> > How does that sound?
> >> >
> >> > Regards,
> >> >
> >> > Sean
> >> >
> >> > PS. By the way I have the parsing public key uri code ready for CVS.
> >> Happy for a 'simple' ParsingTest class that tests it to go into CVS
> >> too?
> >> >
> >> >
> >> > On Mon, 2004-03-08 at 14:36, Sameer Ajmani wrote:
> >> >> That's very weird.  According to the JDK javadoc, there should be a
> >> default iniitalization:
> >> >>
> >> >> In case the client does not explicitly initialize the
> >> KeyPairGenerator (via a call to an initialize method), each
> >> provider must supply (and document) a default initialization. For
> >> example, the Sun provider uses a default modulus size (keysize) of
> >> 1024 bits.
> >> >>
> >> >> Perhaps this is happening because the generator is using a Random
> >> object rather than a SecureRandom object.  Random seeds itself
> >> using the current time, which for two subsequent calls, may be the
> >> same.
> >> >>
> >> >> Please check in your fix, and thanks for catching this!
> >> >> Sameer
> >> >>
> >> >>
> >> >> > Hi all,
> >> >> >
> >> >> > Anyone seen this before:
> >> >> >
> >> >> > (I've got my default KeyPairGenerator Provider to be
> >> >> > sun.security.provider.Sun)
> >> >> >
> >> >> > All my KeyPairs being generated are the same (equal) ...
> >> >> >
> >> >> > Try this:
> >> >> >
> >> >> > KeyPair kp1 = jsdsi.RSAPublicKey.create("RSA");
> >> >> > KeyPair kp2 = jsdsi.RSAPublicKey.create("RSA");
> >> >> >
> >> >> > System.out.println( kp1.getPublic().toString() );
> >> >> > System.out.println( kp2.getPublic().toString() );
> >> >> >
> >> >> >
> >> >> > (I've found that if I insert a call to initialise(KEY_SIZE) in
> >> the
> >> >> jsdsi.RSAKeyPair.create(..) all is cool)
> >> >> >
> >> >> > Any ideas?
> >> >> >
> >> >> > 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-users mailing list
> >> >> > Jsd...@li...
> >> >> > https://lists.sourceforge.net/lists/listinfo/jsdsi-users
> >> >>
> >> >>
> >> >> http://ajmani.net
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> -------------------------------------------------------
> >> >> 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-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
> >>
> >>
> >> http://ajmani.net
> >>
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] SetTag intersection and Hash problem

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

This is a very good point.  I like your intersect() code, and it brings up
an interesting point: should singleton and empty SetTags be disallowed? 
Do they ever make sense?

Sameer

> Question:
>
> What should the intersection of
>
> (* set (* prefix /my/priv/) (* prefix /dummy) (* prefix /my/pub/))
> intersected with (* prefix /my/) be?
>
> I reckon: (* set /my/priv/ /my/pub/)
>
> and not the NULL_TAG as the code thinks.
>
>
> Also I believe that using a java.util.Set to store the elements of the
> SetTag is incorrect. Reason is that a Set does not gaurantee order (more
> particularly the HashSet that it uses). This is not normally a
> problem... untill you:
>
> 1. create an AuthCert
> 2. sign it, creating a Certificate
> 3. Store the Certificate
> 4. Load the Certificate
> 5. Verify the Certificate - it normally fails!!!
>
> This is because on loading the order of the elements in the SetTag and
> often chaned from their original order. Hence, the Hash of the AuthCert
> changes, and so can't be verified! :-)
>
> I think we should change the element storage to a List or array.
>
> If we change it to a List I think that the interset method should change
> to someting like:
>
> public Tag intersect(Tag that) {
>  if (that instanceof SetTag) {
>    return intersect((SetTag) that);
>  }
>  LinkedList newTags = new LinkedList();
>  for (Iterator i = this.elements.iterator(); i.hasNext();) {
>    ExprTag thisTag = (ExprTag) i.next();
>    Tag newTag = thisTag.intersect(that);
>    if (newTag instanceof ExprTag) {
>      // excludes ALL_TAG and NULL_TAG
>      newTags.add(newTag);
>    }
>  }
>  if (newTags.isEmpty()) {
>    return Tag.NULL_TAG;
>  } else {
>    if (newTags.size()>1) {
>      reduce(newTags);
>    }
>    if (newTags.size()>1) {
>      return new SetTag(newTags);
>    } else {
>      return (Tag) newTags.iterator().next();
>    }
>  }
> }
>
> // removes duplicate and un-necessary tags
> private void reduce(List tags) {
>  int i=0;
>  while (i<tags.size()) {
>    for (int j=tags.size()-1; j>=0; j--) {
>      Tag iTag = (Tag) tags.get(i);
>      Tag jTag = (Tag) tags.get(j);
>      if (iTag!=jTag) {
>        if (iTag.equals(jTag) || iTag.implies(jTag)) {
>          tags.remove(j);
>        }
>      }
>    }
>    i++;
>  }
> }
>
>
> Regards,
>
> 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

[Jsdsi-devel] SetTag intersection and Hash problem

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

Question:

What should the intersection of

(* set (* prefix /my/priv/) (* prefix /dummy) (* prefix /my/pub/))
intersected with (* prefix /my/) be?

I reckon: (* set /my/priv/ /my/pub/)

and not the NULL_TAG as the code thinks.


Also I believe that using a java.util.Set to store the elements of the
SetTag is incorrect. Reason is that a Set does not gaurantee order (more
particularly the HashSet that it uses). This is not normally a
problem... untill you:

1. create an AuthCert
2. sign it, creating a Certificate
3. Store the Certificate
4. Load the Certificate
5. Verify the Certificate - it normally fails!!!

This is because on loading the order of the elements in the SetTag and
often chaned from their original order. Hence, the Hash of the AuthCert
changes, and so can't be verified! :-)

I think we should change the element storage to a List or array.

If we change it to a List I think that the interset method should change
to someting like:

public Tag intersect(Tag that) {
 if (that instanceof SetTag) {
   return intersect((SetTag) that);
 }
 LinkedList newTags = new LinkedList();
 for (Iterator i = this.elements.iterator(); i.hasNext();) {
   ExprTag thisTag = (ExprTag) i.next();
   Tag newTag = thisTag.intersect(that);
   if (newTag instanceof ExprTag) {
     // excludes ALL_TAG and NULL_TAG
     newTags.add(newTag);
   }
 }
 if (newTags.isEmpty()) {
   return Tag.NULL_TAG;
 } else {
   if (newTags.size()>1) {
     reduce(newTags);
   }
   if (newTags.size()>1) {
     return new SetTag(newTags);
   } else {
     return (Tag) newTags.iterator().next();
   }
 }
}

// removes duplicate and un-necessary tags
private void reduce(List tags) {
 int i=0;
 while (i<tags.size()) {
   for (int j=tags.size()-1; j>=0; j--) {
     Tag iTag = (Tag) tags.get(i);
     Tag jTag = (Tag) tags.get(j);
     if (iTag!=jTag) {
       if (iTag.equals(jTag) || iTag.implies(jTag)) {
         tags.remove(j);
       }
     }
   }
   i++;
 }
}


Regards,

Sean

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

[Jsdsi-devel] Re: [Jsdsi-users] Sun KeyPairGeneratory

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

I know - very wierd.

I first noticed it about a year ago and so also specified a key-size. I
read and read the javadocs and assumed I was doing something odd, so
thought I'd come back to it. Finally got round to it this w/e and can't
figure out why!

It's good to know that someone else is seeing it.

What I propose is to add 2 constructors to jsdsi.RSAPublicKey:

/**
 * Creates a new RSA key pair whose public key is a {@link
jsdsi.Principal}.
 * @param a the specific RSA algorithm to use
 * @param provider the provider to use
 * @param size the key size to create
 * @param uris an array of uris (<code>java.net.URL</code>) related to
this key pair (may be <code>null</code>)
 * @return
 * @throws NoSuchAlgorithmException
 * @throws NoSuchProviderException
 */
public static KeyPair create(String a, String provider, int size, URL[]
uris)
throws NoSuchAlgorithmException, NoSuchProviderException;

and

/**
 * Creates a new RSA key pair whose public key is a {@link
jsdsi.Principal}.
 * @param a the specific RSA algorithm to use
 * @param provider the provider to use
 * @param uris an array of uris (<code>java.net.URL</code>) related to
this key pair
 * @return
 * @throws NoSuchAlgorithmException
 * @throws NoSuchProviderException
 */
public static KeyPair create(String a, String provider, URL[] uris)
  throws NoSuchAlgorithmException, NoSuchProviderException;

These will allow developers to specify a key size themselves. I'll then
put a WARNING on the constructors that don't specify a key size about
issues noticed with the Sun provider.

How does that sound?

Regards,

Sean

PS. By the way I have the parsing public key uri code ready for CVS.
Happy for a 'simple' ParsingTest class that tests it to go into CVS too?


On Mon, 2004-03-08 at 14:36, Sameer Ajmani wrote:
> That's very weird.  According to the JDK javadoc, there should be a
> default iniitalization:
> 
> In case the client does not explicitly initialize the KeyPairGenerator
> (via a call to an initialize method), each provider must supply (and
> document) a default initialization. For example, the Sun provider uses a
> default modulus size (keysize) of 1024 bits.
> 
> Perhaps this is happening because the generator is using a Random object
> rather than a SecureRandom object.  Random seeds itself using the current
> time, which for two subsequent calls, may be the same.
> 
> Please check in your fix, and thanks for catching this!
> Sameer
> 
> 
> > Hi all,
> >
> > Anyone seen this before:
> >
> > (I've got my default KeyPairGenerator Provider to be
> > sun.security.provider.Sun)
> >
> > All my KeyPairs being generated are the same (equal) ...
> >
> > Try this:
> >
> > KeyPair kp1 = jsdsi.RSAPublicKey.create("RSA");
> > KeyPair kp2 = jsdsi.RSAPublicKey.create("RSA");
> >
> > System.out.println( kp1.getPublic().toString() );
> > System.out.println( kp2.getPublic().toString() );
> >
> >
> > (I've found that if I insert a call to initialise(KEY_SIZE) in the
> > jsdsi.RSAKeyPair.create(..) all is cool)
> >
> > Any ideas?
> >
> > 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-users mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-users
> 
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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-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

Re: [Jsdsi-devel] SetTag intersection

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

I have fixed this, but I am unable to check in (I can't SSH into
cvs.sf.net forsome reason).  For now, here's the corrected
SetTag.intersect:

    public Tag intersect(Tag that)
    {
        if (that instanceof SetTag) {
            return intersect((SetTag)that);
        }
        for (Iterator i = this.elements.iterator(); i.hasNext();) {
            ExprTag thisTag = (ExprTag)i.next();
            if (thisTag.implies(that)) {
                return that;
            }
        }
        return Tag.NULL_TAG;
    }

Note that this change also requires changes to TagTest.  I will check
these in as well.

Sameer

> Sameer,
>
> Is the full intersection of SetTag complete? I ask as:
>
> (tag (* set (* prefix a/b) (* prefix c/d)))
>
> does not imply
>
> (tag a/b/x)
>
>
> (The code is doing what the comments state, but I would have thought the
> above should succeed).
>
> [ (tag (* set a/b/x)) does imply by the way ]
>
>
> 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

Re: [Jsdsi-devel] SetTag intersection

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

I can do it if you like.

Just need to change in SetTag:

public Tag intersect(Tag that)
    {
        if (that instanceof SetTag)
        {
            return intersect((SetTag) that);
        }
        if (elements.contains(that)) {
            return that;
        }
        return Tag.NULL_TAG;
    }

to

 public Tag intersect(Tag that)
    {
        if (that instanceof SetTag)
        {
            return intersect((SetTag) that);
        }
        for (Iterator i = this.elements.iterator(); i.hasNext();)
        {
            ExprTag thisTag = (ExprTag) i.next();
            Tag newTag = thisTag.intersect(that);
            if (newTag instanceof ExprTag)
            {
                // excludes ALL_TAG and NULL_TAG
                return newTag;
            }
        }
        return Tag.NULL_TAG;
    }

On Thu, 2004-03-04 at 20:07, Sameer Ajmani wrote:
> Good catch.  I'll submit a fix soon.
> 
> Sameer
> 
> > Sameer,
> >
> > Is the full intersection of SetTag complete? I ask as:
> >
> > (tag (* set (* prefix a/b) (* prefix c/d)))
> >
> > does not imply
> >
> > (tag a/b/x)
> >
> >
> > (The code is doing what the comments state, but I would have thought the
> > above should succeed).
> >
> > [ (tag (* set a/b/x)) does imply by the way ]
> >
> >
> > 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

[Jsdsi-devel] SetTag intersection

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

Sameer,

Is the full intersection of SetTag complete? I ask as:

(tag (* set (* prefix a/b) (* prefix c/d)))

does not imply 

(tag a/b/x)


(The code is doing what the comments state, but I would have thought the
above should succeed).

[ (tag (* set a/b/x)) does imply by the way ]


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

[Jsdsi-devel] New look JSDSI website

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

All,

Just a quick email to let you know that the JSDSI project has undergone
an overhaul, both in structure and look, as we are now using Maven
(http://maven.apache.org/) to build and manage the project.

Naturally, there is still lots of work to do. However, there are at the
least fairly comprehensive instructions, for those who wish to, on
building Maven from source.

May I take this opportunity to welcome Luis Pedro to the Development
Team - we all look forward to the LDAP work you have in the offing.

Regards,

Sean Radford
(on behalf of JSDSI)

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

Re: [Jsdsi-devel] TODO's in code

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

No problem (it is on 'my list' of things to sort for the web-site).
It'll be a separate page called something like "Future Work", "Under
Discussion", or "What Next" - any other suggestions?


On Mon, 2004-03-01 at 19:05, Sameer Ajmani wrote:
> Sounds good.  Some of my TODOs are project-wide, though (see the TODO file
> in the repository).  Is there a place for these, too?
> 
> > All,
> >
> > In moving to Maven, how do people feel about specifying TODO's in code
> > using @todo javadoc tags instead?
> >
> > The @todo tag can be placed at the class and method level.
> >
> > In doing so, we can track todo's both in Maven via its Task List report,
> > and in Eclipse by stating that @todo is a Task Tag (I have this set as a
> > global Eclipse setting, but you can do it on a per-project basis too if
> > you prefer).
> >
> > Sean
> >
> >
> >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] SuffixTag (or rather ReversePrefixTag)

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

Sameer,

Been looking at the SuffixTag and I think that SuffixTag is the wrong
name, a better name being 'ReversePrefixTag'. As its function is:

A tag that matches strings that prefix its own string value, i.e. (tag
(* reverse-prefix /my/private)) implies (tag /my) but not (tag
/my/private/file)

it is not a suffix as:

(tag (* reverse-prefix /my/private)) does not imply (tag /my/my/private)
[even though it is a suffix]


How does that sound?

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

Re: [Jsdsi-devel] TODO's in code

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

Sounds good.  Some of my TODOs are project-wide, though (see the TODO file
in the repository).  Is there a place for these, too?

> All,
>
> In moving to Maven, how do people feel about specifying TODO's in code
> using @todo javadoc tags instead?
>
> The @todo tag can be placed at the class and method level.
>
> In doing so, we can track todo's both in Maven via its Task List report,
> and in Eclipse by stating that @todo is a Task Tag (I have this set as a
> global Eclipse setting, but you can do it on a per-project basis too if
> you prefer).
>
> Sean
>
>
>
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

[Jsdsi-devel] TODO's in code

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

All,

In moving to Maven, how do people feel about specifying TODO's in code
using @todo javadoc tags instead?

The @todo tag can be placed at the class and method level.

In doing so, we can track todo's both in Maven via its Task List report,
and in Eclipse by stating that @todo is a Task Tag (I have this set as a
global Eclipse setting, but you can do it on a per-project basis too if
you prefer).

Sean



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

[Jsdsi-devel] RE: Ldap - Information Stored

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

Luis,

It sounds like what you have now works pretty well.  Once you've checked
it in, I'll take a look at it and give you comments.

Regarding checking in new code: Sean has integrated JSDSI with Maven, so
the source files now reside in a different directory of the repository.=20
Sean will soon post instructions for how to install Maven and JSDSI (usin=
g
Eclipse as well).  Once that's done, you can add your code as a jsdsi.lda=
p
package.

Sameer


> Sameer,
>
> This is exactly how i'm doing. I'm using issuer and subject attributes
> like Octet, i store the corresponding public keys as hashes("md5" or
> "sha1"). The canonicalSexp i'm storing like Octet and using
> writeTransport().
>
> With this form the public keys can't be read using a ldap browser. Why
> i'm not using writeTransport()? Because it's easier when using the
> selectors if i keep the public keys with writeTransport() then i've to
> writeTransport() the selector components so i can be able to compare
> ldap attributes with selectors components.
>
> Put the certificate readable, well i thought in that and tested but the
> result is not pretty :) The cert appears all in 1 line. Like i have now
> the only thing readable with an ldap browser are: issuerName,
> subjectName and notBefore.
>
> Do u think that is really necessary to use any kind of write canonical
> or transport?
>
> This is i how i do it:
> 	issuer =3D new Hash("...", certificate.getIssuer()) if not a hash or
> issuer =3D certificate.getIssuer()
>
> Then i store as String(but can be byte[]) with issuer attribute as Octe=
t
>
> The difference is when using canonical or transport then the informatio=
n
> take from the selectors have be encode like transport or canonical too
> to make the comparations.
>
> 	Ex: Principal subject =3D ((SubjectCertSelector) s).getSubject();
> 	Then to compare with the information stored i've to encode subject
> with transport or canonical.
>
>    -- Luis Pedro
>
>
> =BB   -----Original Message-----
> =BB   From: Sameer Ajmani [mailto:aj...@cs...]
> =BB   Sent: segunda-feira, 1 de Mar=E7o de 2004 14:05
> =BB   To: lp...@ne...
> =BB   Cc: jsd...@li...
> =BB   Subject: RE: Ldap - Information Stored
> =BB
> =BB   Luis,
> =BB
> =BB   It looks like Octet is Base64 encoding and Binary is
> =BB   Base16.  The formats I proposed last week (encode
> =BB   everything in transport form) assumed LDAP just stored
> =BB   Strings.  Since LDAP can store binary forms, we might want
> =BB   to store the canonical form directly as Octet strings.  It
> =BB   really depends on which form is easiest to search and
> =BB   browse.  We have two use cases:
> =BB   1) Someone is browsing the LDAP server.  In this case, we
> =BB   want to present information about the Cert in readable form
> =BB   (writeReadable->String->DirectoryString).
> =BB   2) Someone is running CertPathBuilder, and so is accessing
> =BB   LDAP via CertSelectors.  In this case, the CertStore wants
> =BB   to look up certain LDAP entries (e.g., hash of issuer key,
> =BB   hash of subject, issuer name string, subject name string,
> =BB   etc).  The CertStore has these objects as JSDSI Objs, so it
> =BB   can convert them to any format (byte[] or String).
> =BB   However, searchable terms must NOT be stored in readable
> =BB   form (because different searchers may use different spacing
> =BB   in the readable form).
> =BB
> =BB   So, the bottom line is that the schema for a cert should
> =BB   include a readable form of the cert:
> =BB   readable =3D cert.toSexp().writeReadable(..., 0, 72, 0)
> =BB   [input as String; store as DirectoryString]
> =BB
> =BB   And the rest in canonical form:
> =BB   issuerHash =3D cert.getIssuer().toSexp().writeCanonical(...)
> =BB   [input as byte[]; store as Octet]
> =BB
> =BB   Or possibly in transport form, but I'm not sure why this
> =BB   would be better:
> =BB   issuerHash =3D cert.getIssuer().toSexp().writeTransport(...)
> =BB   [input as byte[]; store as DirectoryString]
> =BB
> =BB   Sameer
> =BB
> =BB   > Sameer,
> =BB   >
> =BB   > I'll try to explain. Octet, binary and directory strings
> =BB   are the way
> =BB   > that information is represented on ldap. When u see the
> =BB   information
> =BB   > using an ldap browser this is what u see:
> =BB   > 	Octet: {KDVx/6tyUIo9},
> =BB   > 	Binary: 30 82 50 5F,
> =BB   > 	DirectoryString(Readable String): luis This types are
> =BB   only relevant
> =BB   > to make comparations.
> =BB   > String and byte[] are the to ways that we can send
> =BB   information to the
> =BB   > ldap. For example, "certificate" is a sdsi certificate
> =BB   the we can send
> =BB   > it like:
> =BB   > 	certificate.toString() or
> =BB   > 	certificate.encode() or
> =BB   > 	---------------------------
> =BB   > 	ByteArrayOutputStream bos =3D new ByteArrayOutputStream();
> =BB   > 	(certificate.toSequence().toSexp()).writeTransport(bos);
> =BB   >
> =BB   > 	and then store it like bos.toString() or bos.toByteArray(). =BB=
   >
> =BB   > I was just asking if u have preferences on that? I'm
> =BB   using Octet and
> =BB   > store like Strings(toString()). Other thing, i've choose
> =BB   as default to
> =BB   > the hashes the "md5".
> =BB   >
> =BB   > I've everything almost ready, i still have to test the
> =BB   Selectors and
> =BB   > the ldap filters for Compatible and Name Selector. Maybe
> =BB   tomorrow all
> =BB   > will be completed.
> =BB   >
> =BB   >    -- Luis Pedro
> =BB   >
> =BB   >
> =BB   > =BB   -----Original Message-----
> =BB   > =BB   From: Sameer Ajmani [mailto:aj...@cs...]
> =BB   > =BB   Sent: segunda-feira, 1 de Mar=E7o de 2004 1:11
> =BB   > =BB   To: lp...@ne...
> =BB   > =BB   Subject: Re: Ldap - Information Stored
> =BB   > =BB
> =BB   > =BB   Luis,
> =BB   > =BB
> =BB   > =BB   In what context can we choose bwteen String and byte[], a=
nd =BB
>  > =BB   in what other context can we choose bwteen Octet, binary, =BB =
  > =BB
>   and dictionary strings?  I'm not sure I undertstand
> =BB   the differences.
> =BB   > =BB
> =BB   > =BB   Sameer
> =BB   > =BB
> =BB   > =BB   > Sameer,
> =BB   > =BB   >
> =BB   > =BB   > This is just a formal question. The information can be =
=BB   >
> =BB   stored on ldap
> =BB   > =BB   > as String or byte[], wich do u prefer? I prefer String =
=BB   >
> =BB   because i can
> =BB   > =BB   > see the information stored and be sure that all is
> =BB   there. Another
> =BB   > =BB   > thing, on the ldap server the information can be
> =BB   represented like
> =BB   > =BB   > OctetStrings, binary, DirectoryStrings, etc...This 3 ar=
e =BB
>> =BB   the relevant
> =BB   > =BB   > for us, wich do u prefer? I like the OctetString becaus=
e =BB
>> =BB   of the same
> =BB   > =BB   > reason that i gave before.
> =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


http://ajmani.net

[Jsdsi-devel] RE: Ldap - Information Stored

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

Luis,

It looks like Octet is Base64 encoding and Binary is Base16.  The formats
I proposed last week (encode everything in transport form) assumed LDAP
just stored Strings.  Since LDAP can store binary forms, we might want to
store the canonical form directly as Octet strings.  It really depends on
which form is easiest to search and browse.  We have two use cases:
1) Someone is browsing the LDAP server.  In this case, we want to present
information about the Cert in readable form
(writeReadable->String->DirectoryString).
2) Someone is running CertPathBuilder, and so is accessing LDAP via
CertSelectors.  In this case, the CertStore wants to look up certain LDAP
entries (e.g., hash of issuer key, hash of subject, issuer name string,
subject name string, etc).  The CertStore has these objects as JSDSI Objs=
,
so it can convert them to any format (byte[] or String).  However,
searchable terms must NOT be stored in readable form (because different
searchers may use different spacing in the readable form).

So, the bottom line is that the schema for a cert should include a
readable form of the cert:
readable =3D cert.toSexp().writeReadable(..., 0, 72, 0)
[input as String; store as DirectoryString]

And the rest in canonical form:
issuerHash =3D cert.getIssuer().toSexp().writeCanonical(...)
[input as byte[]; store as Octet]

Or possibly in transport form, but I'm not sure why this would be better:
issuerHash =3D cert.getIssuer().toSexp().writeTransport(...)
[input as byte[]; store as DirectoryString]

Sameer

> Sameer,
>
> I'll try to explain. Octet, binary and directory strings are the way
> that information is represented on ldap. When u see the information
> using an ldap browser this is what u see:
> 	Octet: {KDVx/6tyUIo9},
> 	Binary: 30 82 50 5F,
> 	DirectoryString(Readable String): luis
> This types are only relevant to make comparations.
> String and byte[] are the to ways that we can send information to the
> ldap. For example, "certificate" is a sdsi certificate the we can send
> it like:
> 	certificate.toString() or
> 	certificate.encode() or
> 	---------------------------
> 	ByteArrayOutputStream bos =3D new ByteArrayOutputStream();
> 	(certificate.toSequence().toSexp()).writeTransport(bos);
>
> 	and then store it like bos.toString() or bos.toByteArray().
>
> I was just asking if u have preferences on that? I'm using Octet and
> store like Strings(toString()). Other thing, i've choose as default to
> the hashes the "md5".
>
> I've everything almost ready, i still have to test the Selectors and th=
e
> ldap filters for Compatible and Name Selector. Maybe tomorrow all will
> be completed.
>
>    -- Luis Pedro
>
>
> =BB   -----Original Message-----
> =BB   From: Sameer Ajmani [mailto:aj...@cs...]
> =BB   Sent: segunda-feira, 1 de Mar=E7o de 2004 1:11
> =BB   To: lp...@ne...
> =BB   Subject: Re: Ldap - Information Stored
> =BB
> =BB   Luis,
> =BB
> =BB   In what context can we choose bwteen String and byte[], and
> =BB   in what other context can we choose bwteen Octet, binary,
> =BB   and dictionary strings?  I'm not sure I undertstand the differenc=
es.
> =BB
> =BB   Sameer
> =BB
> =BB   > Sameer,
> =BB   >
> =BB   > This is just a formal question. The information can be
> =BB   stored on ldap
> =BB   > as String or byte[], wich do u prefer? I prefer String
> =BB   because i can
> =BB   > see the information stored and be sure that all is there. Anoth=
er
> =BB   > thing, on the ldap server the information can be represented li=
ke
> =BB   > OctetStrings, binary, DirectoryStrings, etc...This 3 are
> =BB   the relevant
> =BB   > for us, wich do u prefer? I like the OctetString because
> =BB   of the same
> =BB   > reason that i gave before.
> =BB   >
> =BB   >     -- Luis Pedro
> =BB
> =BB
> =BB   http://ajmani.net
> =BB
> =BB
> =BB
> =BB


http://ajmani.net

[Jsdsi-devel] RE: spki/sdsi xml format

[Carl E. <cm...@ac...>]

 

> -----Original Message-----
> From: Sameer Ajmani [mailto:aj...@cs...] 
> Sent: Saturday, February 28, 2004 2:00 PM
> To: cm...@ac...
> Cc: jsd...@li...
> Subject: RE: spki/sdsi xml format
> 
> Carl,
> I took a look at the UPnP-Sec XML schema, and indeed it 
> appears to be a
> subset of SPKI (I noticed you use hashes wherever possible, where SPKI
> tends to offer a choice between public keys and hashes 
> wherever principals
> can appear).

Yes, we did. We wanted to offer only one choice, wherever possible - to keep
the implementation as simple as possible.

> 
> > I agree that the XML needs to have labeled text items.  XML doesn't
> > recognize a text atom the way sexp does.  This suggests 
> that we should
> > modify the sexp syntax as you proposed, if we want to have easy
> > conversion.
> 
> This seems to suggest that SPKI should be defined in terms of 
> XML first,
> then we should use some canonical conversion to S-expressions 
> :)  I have
> in fact implemented "x2s" in addition to s2x; in fact I have a general
> converter:
> usage: java jsdsi.S2X filename [sexp|xml] [canon|xprt|read|xml]

Cool.  Where can I get it? ..from the project page?

> 
> S2X parses the given file using the specified input format 
> (sexp or xml),
> and outputs its contents to stdout in the specified output format
> (canonical, transport, or readable sexp, or XML).
> 
> 
> > (cert
> > 	(issuer (name <key> <text>))
> > ...)
> 
> Yes, we once discussed changing name certs to be:
> (cert (issuer <principal>) (name <byte-string>) <subject>)
> This is nice because it parallels auth certs:
> (cert (issuer <principal>) (tag <tag-body>) <propagate>? <subject>)

Yup.

> 
> > XML has an advantage that sexp doesn't: namespaces.
> >
> > This turned out to be important in authorization (tag) fields.  The
> > *-forms became normal tags but in another namespace.  If 
> we're going to
> > do an XML version, I believe we should do this. However, that
> > complicates x2s. How will we express namespaces in sexp?  
> My guess is
> > that we should use display hints for that, but that's just a quick
> > guess.  I'll let others discuss that for now.
> 
> Hmm... this is a good point -- I haven't tested *-forms in 
> S2X yet, and
> I'm sure this would break it :)  Display type is one option, but it
> overloads its real meaning.  Alternately, we could create 
> namespaces by
> convention: just prefix the string with "namespace:".

Yes, we could. We don't have XML's namespace ID abbreviation and rewriting -
and I don't believe we want it.  So, in X2S we'd have to expand the
abbreviations in place.  With XML namespaces, that gets very big very fast!


Alternatively, we could treat the XML abbreviation as if it were a fully
qualified namespace.

Alternatively, we could use SDSI namespaces - where a hash value is the
namespace ID.

So, syntax hhhhhhhhhhhhhhh:foo could be used both for namespace qualified
element names and for

	(name (hash sha1 hhhhhhhhhhh) foo)

However, I would hesitate jumping into a design decision in the heat of
brainstorming like this.

What do we need from a namespace?

Can we use the implicit hierarchy in both XML and sexp to save space?

Should we use abbreviations the way XML does?

 - Carl

P.S. What does x2s do with XML attributes?

> 
> Sameer
> 
> 

Re: [Jsdsi-devel] Installing Maven, Eclipse and JSDSI on Windows 2000

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

Cool :-)

One strange thing: the directories src/test and src/java appear are not
> nested beneath src in my Eclipse project view -- do you know why this is?
Do you mean in the Package Explorer? If so this is its 'correct' behaviour
as they come from different source trees.

Another question:  did the process below install the Maven Eclipse plug
> in, or is this separate?  If it's separate, how do I install the plug in?
The maven-1.0-rc1 includes the eclipse plugin - even though the plugin
is described as an optional one in the maven documentation.

Finally, if I add a new class, will it be added to the Maven build process
> automatically by Eclipse, or do I need to do something manually?
If you add new classes within 'src/java' or 'src/test' both Maven and Eclipse will be happy.


I'll try to get time in the morning to copy the instructions below to an
html page

Regards,


Sean

On Sat, 2004-02-28 at 22:48, Sameer Ajmani wrote:
> Sean,
> 
> It works!  Thanks a lot for your help.  I've included a few small edits
> below.
> 
> One strange thing: the directories src/test and src/java appear are not
> nested beneath src in my Eclipse project view -- do you know why this is?
> 
> Another question:  did the process below install the Maven Eclipse plug
> in, or is this separate?  If it's separate, how do I install the plug in?
> 
> Finally, if I add a new class, will it be added to the Maven build process
> automatically by Eclipse, or do I need to do something manually?
> 
> Thanks again,
> Sameer
> 
> 
> > Here's a step by step guide that I just did to get Maven working on
> > Windows 2000 (a box that has a correctly installed JDK).
> >
> > 1. Download maven-1.0-rc1.zip
> > (http://maven.apache.org/start/download.html)
> >
> > 2. Extract the downloaded zip to your target directory, e.g. C:\java\
> > - resulting in c:\java\maven-1.0-rc1
> >
> > 3. set MAVEN_HOME to 'C:\java\maven-1.0-rc1' via the 'Control
> > Panel\System\Advanced\Environment Variables\User Variables'
> >
> > 4. Add %MAVEN_HOME%\bin to 'Path' environment variable similar to
> > above
> 
> This Path variable must be in User Variables.
> If a Path variabel alreayd exists, add ";%MAVEN_HOME%\bin" to the end of
> it.
> 
> > 5. Open a console and run 'set' to check that the environment
> > variables are set correctly. (An easy way to open a command prompt is
> > 'Start\Run...', enter 'command' and press 'ok')
> >
> > 6. From the command prompt run 'install_repo.bat
> > %HOMEPATH%\.maven\repository' - On some boxes the environment variable
> > is HOME, you can check this by running the 'set' command and looking
> > for which entry points to 'C:\Documents and Settings\YOURUSERNAME'
> >
> > 7. At the command prompt run 'maven -g' to check that Maven is running
> > - all the maven goals are listed...
> >
> > 8. Download and install Eclipse (Latest stable version 3 build is
> > currently 3.0-M7)
> >
> > 9. Run Eclipse
> >
> > 10. Set-up jsdsi cvs repository in Eclipse for browsing (make sure to
> > use extssh or ext if you will want to write to the repository later)
> >
> > 11. In the CVS repository browser select the HEAD branch of
> > cvsroot/jsdsi
> >
> > 12. Under the above, select the jsdsi directory and right-click
> >
> > 13. Select 'Check Out As...'
> >
> > 14. Make sure 'Check out as a project configured using the New Project
> > Wizard' is selected
> >
> > 15. Press Finish
> >
> > 16. Select 'Java' and 'Java Project' and press 'Next'
> >
> > 17. Enter project name 'jsdsi' in the text box and press 'Next'
> > (optionally enter an alternate project location in the 'Project
> > Contents' information area)
> >
> > 18. When asked to switch Perspective select yes
> 
> I didn't get asked this, perhaps because I already instaleld Eclipse
> earlier.
> 
> Need a step after #17: Click Finish.
> 
> >
> > 19. Using a text editor, e.g. Notepad create a text file called
> > 'build.properties' in your home directory ('C:\Documents and
> > Settings\YOURUSERNAME'). The contents of the file is a single entry:
> >
> > maven.eclipse.workspace=ECLIPSE_WORKSPACE_PATH
> >
> > Where ECLIPSE_WORKSPACE_PATH should be replaced by the path to your
> > Eclipse Workspace (the default being 'ECLIPSE_HOME\workspace') As an
> > example:
> >
> > maven.eclipse.workspace=C:\programs\eclipse-3.0-M7\workspace
> >
> > 19. Save your 'build.properties' file.
> >
> > 20. Go back to the command prompt
> >
> > 21. 'cd' to the location where you checked-out jsdsi to during step 17
> > - The default location is 'ECLIPSE_HOME\workspace\jsdsi', where
> > ECLIPSE_HOME is the location of your Eclipse installation
> 
> Note that for directory names longer than 8 characters, cd requires the
> name of the directory to be just the first six letters, followed by
> "~1".  For example, "cd F:\Program Files" fials,; instead do "cd
> F:\Progra~1".  (if there happens to be more than directory with the same
> prefix, they're numbered sequentially.  What happens if there's a space
> inthe first six letters?)
> 
> > 22. Within the jsdsi directory run 'maven eclipse:add-maven-repo' -
> > This adds a variable to Eclipse so it knows where your Local Maven
> > Repository is.
> >
> > 23. Next run 'maven eclipse' - This creates the correct eclipse
> > '.project' and '.classpath' files.
> >
> > 24. In eclipse, 'refresh' your jsdsi project.
> >
> > 25. All should now be correctly set-up...
> >
> >
> > Hope this help,
> >
> >
> > Sean
> >
> > (This is something to move to the site I should guess - ideally with
> > some screenshots)
> >
> > --
> > Dr. Sean Radford, MBBS, MSc
> > sra...@ae...
> > http://www.aegeus-technology.com
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> > Build and deploy apps & Web services for Linux with
> > a free DVD software kit from IBM. Click Now!
> > http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> > _______________________________________________
> > Jsdsi-devel mailing list
> > Jsd...@li...
> > https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
> 
> 
> http://ajmani.net
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] Installing Maven, Eclipse and JSDSI on Windows 2000

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

Sean,

It works!  Thanks a lot for your help.  I've included a few small edits
below.

One strange thing: the directories src/test and src/java appear are not
nested beneath src in my Eclipse project view -- do you know why this is?

Another question:  did the process below install the Maven Eclipse plug
in, or is this separate?  If it's separate, how do I install the plug in?

Finally, if I add a new class, will it be added to the Maven build process
automatically by Eclipse, or do I need to do something manually?

Thanks again,
Sameer


> Here's a step by step guide that I just did to get Maven working on
> Windows 2000 (a box that has a correctly installed JDK).
>
> 1. Download maven-1.0-rc1.zip
> (http://maven.apache.org/start/download.html)
>
> 2. Extract the downloaded zip to your target directory, e.g. C:\java\
> - resulting in c:\java\maven-1.0-rc1
>
> 3. set MAVEN_HOME to 'C:\java\maven-1.0-rc1' via the 'Control
> Panel\System\Advanced\Environment Variables\User Variables'
>
> 4. Add %MAVEN_HOME%\bin to 'Path' environment variable similar to
> above

This Path variable must be in User Variables.
If a Path variabel alreayd exists, add ";%MAVEN_HOME%\bin" to the end of
it.

> 5. Open a console and run 'set' to check that the environment
> variables are set correctly. (An easy way to open a command prompt is
> 'Start\Run...', enter 'command' and press 'ok')
>
> 6. From the command prompt run 'install_repo.bat
> %HOMEPATH%\.maven\repository' - On some boxes the environment variable
> is HOME, you can check this by running the 'set' command and looking
> for which entry points to 'C:\Documents and Settings\YOURUSERNAME'
>
> 7. At the command prompt run 'maven -g' to check that Maven is running
> - all the maven goals are listed...
>
> 8. Download and install Eclipse (Latest stable version 3 build is
> currently 3.0-M7)
>
> 9. Run Eclipse
>
> 10. Set-up jsdsi cvs repository in Eclipse for browsing (make sure to
> use extssh or ext if you will want to write to the repository later)
>
> 11. In the CVS repository browser select the HEAD branch of
> cvsroot/jsdsi
>
> 12. Under the above, select the jsdsi directory and right-click
>
> 13. Select 'Check Out As...'
>
> 14. Make sure 'Check out as a project configured using the New Project
> Wizard' is selected
>
> 15. Press Finish
>
> 16. Select 'Java' and 'Java Project' and press 'Next'
>
> 17. Enter project name 'jsdsi' in the text box and press 'Next'
> (optionally enter an alternate project location in the 'Project
> Contents' information area)
>
> 18. When asked to switch Perspective select yes

I didn't get asked this, perhaps because I already instaleld Eclipse
earlier.

Need a step after #17: Click Finish.

>
> 19. Using a text editor, e.g. Notepad create a text file called
> 'build.properties' in your home directory ('C:\Documents and
> Settings\YOURUSERNAME'). The contents of the file is a single entry:
>
> maven.eclipse.workspace=ECLIPSE_WORKSPACE_PATH
>
> Where ECLIPSE_WORKSPACE_PATH should be replaced by the path to your
> Eclipse Workspace (the default being 'ECLIPSE_HOME\workspace') As an
> example:
>
> maven.eclipse.workspace=C:\programs\eclipse-3.0-M7\workspace
>
> 19. Save your 'build.properties' file.
>
> 20. Go back to the command prompt
>
> 21. 'cd' to the location where you checked-out jsdsi to during step 17
> - The default location is 'ECLIPSE_HOME\workspace\jsdsi', where
> ECLIPSE_HOME is the location of your Eclipse installation

Note that for directory names longer than 8 characters, cd requires the
name of the directory to be just the first six letters, followed by
"~1".  For example, "cd F:\Program Files" fials,; instead do "cd
F:\Progra~1".  (if there happens to be more than directory with the same
prefix, they're numbered sequentially.  What happens if there's a space
inthe first six letters?)

> 22. Within the jsdsi directory run 'maven eclipse:add-maven-repo' -
> This adds a variable to Eclipse so it knows where your Local Maven
> Repository is.
>
> 23. Next run 'maven eclipse' - This creates the correct eclipse
> '.project' and '.classpath' files.
>
> 24. In eclipse, 'refresh' your jsdsi project.
>
> 25. All should now be correctly set-up...
>
>
> Hope this help,
>
>
> Sean
>
> (This is something to move to the site I should guess - ideally with
> some screenshots)
>
> --
> Dr. Sean Radford, MBBS, MSc
> sra...@ae...
> http://www.aegeus-technology.com
>
>
>
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel


http://ajmani.net

Re: [Jsdsi-devel] Installing Maven, Eclipse and JSDSI on Windows 2000

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

Hmm... I think that must be due to evironment variable processing
order...

I suspect that you have PATH defined in System Variables only.

You need to define PATH in System and User Variables...

Mine are:

System Variables:
Path - %SystemRoot%\system32;%SystemRoot%\System32\Whem

User Variables:
MAVEN_HOME - C:\java\maven-1.0-rc1
Path - %JAVA_HOME%\bin;%MAVEN_HOME%\bin


Windows will then concatenate the 2 Path definitions correctly (well
should)


Good luck,

Sean

On Sat, 2004-02-28 at 20:44, Sameer Ajmani wrote:
> Sean,
> 
> This step-by-step is excellent, and should definitely be in our
> documentation.  I apologize for my impatience earlier -- I'm just unused
> to dealing with Windows' shell, and I got frustrated.
> 
> I'm currently stuck here:
> 
> > 4. Add %MAVEN_HOME%\bin to 'Path' environment variable similar to above
> >
> > 5. Open a console and run 'set' to check that the environment variables
> > are set correctly. (An easy way to open a command prompt is
> > 'Start\Run...', enter 'command' and press 'ok')
> >
> > 6. From the command prompt run 'install_repo.bat
> > %HOMEPATH%\.maven\repository' - On some boxes the environment variable
> > is HOME, you can check this by running the 'set' command and looking for
> > which entry points to 'C:\Documents and Settings\YOURUSERNAME'
> 
> set's output includes:
> 
> HOMEPATH=\Documents and Settings\Sameer Ajmani
> JAVA_HOME=F:\Program Files\j2sdk1.4.2_03
> MAVEN_HOME=F:\Program Files\Apache Software Foundation\Maven 1.0-rc1
> PATH=F:\WINNT\system32;F:\WINNT;F:\WINNT\System32\Wbem;%MAVEN_HOME%\bin
> 
> What's strange here is that PATH has %MAVEN_HOME%\bin, not F:\Program
> Files\Apache Software Foundation\Maven 1.0-rc1\bin -- it's as though
> variable substitution didn't happen.  This means calls to install_repo.bat
> and maven.bat fail:
> 
> F:\DOCUME~1\SAMEER~1>install_repo.bat
> 'INSTALL_REPO.bat' is not recognized as an internal or external command,
> operable program or batch file.
> 
> F:\DOCUME~1\SAMEER~1>dir %MAVEN_HOME%\bin
> The system cannot find the file specified.
> 
> F:\DOCUME~1\SAMEER~1>dir %MAVEN_HOME%
> The system cannot find the file specified.
> 
> F:\DOCUME~1\SAMEER~1>echo %MAVEN_HOME%
> F:\Program Files\Apache Software Foundation\Maven 1.0-rc1
> 
> F:\DOCUME~1\SAMEER~1>echo %MAVEN_HOME%\bin
> F:\Program Files\Apache Software Foundation\Maven 1.0-rc1\bin
> 
> Any clues?
> 
> Thanks,
> Sameer
> 
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

[Jsdsi-devel] RE: spki/sdsi xml format

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

Carl,
I took a loog at the UPnP-Sec XML schema, and indeed it appears to be a
subset of SPKI (I noticed you use hashes wherever possible, where SPKi
tends to offer a coice between public keys and hashes wherever principals
can appear).

> I agree that the XML needs to have labeled text items.  XML doesn't
> recognize a text atom the way sexp does.  This suggests that we should
> modify the sexp syntax as you proposed, if we want to have easy
> conversion.

This seems to suggest that SPKI should be defined in terms of XML first,
then we should use some canonical conversion to S-expressions :)  I have
in fact implemented "x2s" in addition to s2x; in fact I have a general
converter:
usage: java jsdsi.S2X filename [sexp|xml] [canon|xprt|read|xml]

S2X parses the given file using the specified input format (sexp or xml),
and outputs its contents to stdout in the specified output format
(canonical, transport, or readable sexp, or XML).


> (cert
> 	(issuer (name <key> <text>))
> ...)

Yes, we once discussed changing name certs to be:
(cert (issuer <principal>) (name <byte-string>) <subject>)
This is nice because it parallels auth certs:
(cert (issuer <principal>) (tag <tag-body>) <propagate>? <subject>)

> XML has an advantage that sexp doesn't: namespaces.
>
> This turned out to be important in authorization (tag) fields.  The
> *-forms became normal tags but in another namespace.  If we're going to
> do an XML version, I believe we should do this. However, that
> complicates x2s. How will we express namespaces in sexp?  My guess is
> that we should use display hints for that, but that's just a quick
> guess.  I'll let others discuss that for now.

Hmm... this is a good point -- I haven't tested *-forms in S2X yet, and
I'm sure this would break it :)  Display type is one option, but it
overloads its real meaning.  Alternately, we could create namespaces by
convention: just prefix the string with "namespace:".

Sameer

[Jsdsi-devel] [Fwd: RE: spki/sdsi xml format]

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

Part of my discussion with Carl Ellison about JSDSI/XML:

-------- Original Message --------
Subject: RE: spki/sdsi xml format
From: "Carl Ellison" <cm...@ac...>
Date: Sat, February 28, 2004 9:36 pm
To: <aj...@cs...>

Have you looked at the XML syntax we used in UPnP Security?  It's an XML
syntax for a subset of SPKI/SDSI.

I agree that the XML needs to have labeled text items.  XML doesn't
recognize a text atom the way sexp does.  This suggests that we should
modify the sexp syntax as you proposed, if we want to have easy
conversion.

However, I would recommend that you define x2s and define the XML syntax
(looking at what we did in UPnP for a sample).  Among other things, we
undid the cute but hard-to-explain construct:

(cert
	(issuer (name <key> <text>))
...)

XML has an advantage that sexp doesn't: namespaces.

This turned out to be important in authorization (tag) fields.  The
*-forms became normal tags but in another namespace.  If we're going to
do an XML version, I believe we should do this. However, that
complicates x2s. How will we express namespaces in sexp?  My guess is
that we should use display hints for that, but that's just a quick
guess.  I'll let others discuss that for now.

 - Carl

------------------

P.S. I've subscribed to jsdsi-devel but that hasn't come through yet, so
this message may not go out to that list. Feel free to forward it,
rather than have me CC it.


> -----Original Message-----
> From: Sameer Ajmani [mailto:aj...@cs...]
> Sent: Saturday, February 28, 2004 1:08 PM
> To: cm...@ac...
> Cc: jsd...@li...
> Subject: spki/sdsi xml format
>
> Hi Carl,
>
> I hope you're doing well.
>
> Some recent discussion has come up on the jsdsi-devel list
> regarding the
> XML format for SPKI/SDSI objects.  Lots of schemas have been proposed,
> including at least one RFC, but you and I once discussed a simple
> "sexp-to-xml" translation (and in fact you demonstrated this
> with an s2x
> program).  I've recently implemented my own version of s2x in
> JSDSI, using
> this mapping:
>
> Given sexp s = (type item1 item2 ... itemN),
> s2x(s) =
> <type>
> s2x(item1)
> s2x(item2)
> ...
> s2x(itemN)
> </type>
>
> If s is a sexp-string, then it is converted to readable
> (advanced) form
> and stored as character data inside the surrounding element.
>
> For example:
> s = (name (hash md5 |abc123def456|) "Carol Jones" friends)
> s2x(s) =
> <name>
> <hash>md5 |abc123def456|</hash>
> "Carol Jones" friends
> </name>
>
> What's good about this is that reading or writing XML
> required no semantic
> knowledge of SPKI/SDSI.  What's bad is that storing sexp-strings as
> character data means that they're not logically separated.
> For example, a
> human looking at "<hash>md5 |abc123def456|</hash>" does not
> necessarily
> know what the string sin the middle mean.  Notice that this
> is no problem
> to parse: the parser simply reads such character data into as
> many sexp
> strings as are encoded (in this case two).
>
> There are a couple of solutions.  One is to wrap each string
> in an element:
> <hash><string>md5</string><string>|abc123def456|</string></hash> Or
> even:
> <hash><string val="md5"/><string val="|abc123def456|"/></hash>
> But this is ugly.
>
> I believe the better solution is to address the semantic
> deficiency at its
> source by annotating each string:
> <hash><algo>md5</algo><value>|abc123def456|</value></hash>
> Since we want to keep the XML-Sexp mapping semantic-free,
> this requires
> the corresponding Sexp to become:
> (hash (algo md5) (value |abc123def456|))
>
> I think this is good.  In general, this means SPKI/SDSI
> S-expressions are
> restricted as follows:
> <sexp-list> = "(" <sexp-string> <list-body> ")" ;
> <list-body> = <sexp-list>* | <sexp-string> ;
>
> That is, a SPKI/SDSI Sexp-list always starts with a
> Sexp-string (its type)
> that is followed by zero or more Sexp-lists OR exactly one
> Sexp-string.
>
> This would require some adjustments to the SPKI/SDSI grammar, but I
> believe it will make objects easier to understand and it will make the
> conversion to XML even simpler.
>
> What to you think?
> Sameer
>
>
> http://ajmani.net
>
>


http://ajmani.net