jsdsi-devel

[Jsdsi-devel] JSDSI plan

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

JSDSI developers,

We've had a lot of activity lately.  It's time we start thinking about how
to coordinate our efforst, so that we don't conflict.  Here's what I see
in the immediate future:

Sean: Eclipsify and Mavenize JSDSI.  First priority is just to get the
vital Eclipse files (.project, .classpath) in the repository (we'll have
to agree on classpaths to any externasl jars, such as Cryptix), and make
sure the tests all run properly (we may have to move the data files used
by the tests).  Let us know when this part is done, so we can resume
working.  Also, feel free to add a jsdsi.process package (or whatever name
you think is appropriate) for the various classes you described to me
earlier.  I'm still a little concerned about the security implications of
SuffixTag, so be sure to document it clearly if you choose to implement
it.

Luis: Once Sean says the repository is ready, feel free to add a
jsdsi.ldap package and add your new files there.  Let's discuss how to
integrate LDAP with the cert path parameters on jsdsi-devel.

Michael: it seems you're busy with other things right now.  Is there some
part of JSDSI you'd like to work on?

Sameer: investigate better parsing techniques; add documentation and tests
for core classes.  Create jsdsi.xml package using some canonical sexp to
xml translation.

All: add tests to jsdsi.test for any classes you write.

All: if you need to change a class in jsdsi or jsdsi.sexp, please consult
me first.

Sameer

http://ajmani.net

Re: [Jsdsi-devel] JSDSI plan

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

All sounds good to me.

I will do the Mavenisation tomorrow or Friday. We don't need to agree on
classpaths to external jars as we just reference them in the (your)
Maven Repository - by the way I run my own 'remote maven repository' so
makeing new project jar dependencies available for others is easy.

What version number shall will give this? I would suggest something like
0.5

Sean

On Tue, 2004-02-24 at 22:49, Sameer Ajmani wrote:
> JSDSI developers,
> 
> We've had a lot of activity lately.  It's time we start thinking about how
> to coordinate our efforst, so that we don't conflict.  Here's what I see
> in the immediate future:
> 
> Sean: Eclipsify and Mavenize JSDSI.  First priority is just to get the
> vital Eclipse files (.project, .classpath) in the repository (we'll have
> to agree on classpaths to any externasl jars, such as Cryptix), and make
> sure the tests all run properly (we may have to move the data files used
> by the tests).  Let us know when this part is done, so we can resume
> working.  Also, feel free to add a jsdsi.process package (or whatever name
> you think is appropriate) for the various classes you described to me
> earlier.  I'm still a little concerned about the security implications of
> SuffixTag, so be sure to document it clearly if you choose to implement
> it.
> 
> Luis: Once Sean says the repository is ready, feel free to add a
> jsdsi.ldap package and add your new files there.  Let's discuss how to
> integrate LDAP with the cert path parameters on jsdsi-devel.
> 
> Michael: it seems you're busy with other things right now.  Is there some
> part of JSDSI you'd like to work on?
> 
> Sameer: investigate better parsing techniques; add documentation and tests
> for core classes.  Create jsdsi.xml package using some canonical sexp to
> xml translation.
> 
> All: add tests to jsdsi.test for any classes you write.
> 
> All: if you need to change a class in jsdsi or jsdsi.sexp, please consult
> me first.
> 
> Sameer
> 
> http://ajmani.net
> 
> 
> 
> 
> 
> -------------------------------------------------------
> SF.Net is sponsored by: Speed Start Your Linux Apps Now.
> Build and deploy apps & Web services for Linux with
> a free DVD software kit from IBM. Click Now!
> http://ads.osdn.com/?ad_id=1356&alloc_id=3438&op=click
> _______________________________________________
> Jsdsi-devel mailing list
> Jsd...@li...
> https://lists.sourceforge.net/lists/listinfo/jsdsi-devel
-- 
Dr. Sean Radford, MBBS, MSc
sra...@ae...
http://www.aegeus-technology.com

Re: [Jsdsi-devel] JSDSI plan

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

> I will do the Mavenisation tomorrow or Friday. We don't need to agree on
> classpaths to external jars as we just reference them in the (your)
> Maven Repository - by the way I run my own 'remote maven repository' so
> makeing new project jar dependencies available for others is easy.

Cool!

> What version number shall will give this? I would suggest something like
> 0.5

Sure.

Sameer

RE: [Jsdsi-devel] JSDSI plan

[Luis P. <lp...@ne...>]

Sameer, 

I like to put the schema to discussion.

In my project i see the ldap server just as a repository for certs and
because of this i don't have certs associated with users like it usual with
X509 certs. Of course that anyone can make that association if it like but
as to follow the schema.

Here is the schema that i'm using:

 cn (common name for the cert), u can see this as a unique name;
 javaSerializedObject (sdsi cert), i think that is the best way to represent
the certs,
 issuerPubKey (issuer public key)
 subjectPubKey (subject public key)
 name (name)  

The attribute 'name' can be used as optional(if the certs are AuthCerts,
doens't make sense the use of this). issuerPubKey and subjectPubKey are
needed to perform searchs with the currently selectors (Auth, Subject,
Compatible, Name), without having to desserialize the cert.

I think that the certs should be searched on the ldap without getting all to
an object like a MultiMap to apply the selectors.

The 'javaSerializedObject' could, also be an attribute with other name where
is content would be an encoded sdsi cert. 

   -- Luis Pedro
 

RE: [Jsdsi-devel] JSDSI plan

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

Comments inline:

> Here is the schema that i'm using:
>
>  cn (common name for the cert), u can see this as a unique name;

This should be the cryptographic hash (MD5 or SHA1) of the cert.  This is
guaranteed to be unique (with high probability), and it makes it easy to
find the cert if you already have its hash.

>  javaSerializedObject (sdsi cert), i think that is the best way to
> represent the certs,

I disagree...

> The 'javaSerializedObject' could also be an attribute with other name
> where is content would be an encoded sdsi cert.

The standard way to represent any SDSI/SPKI object is as a canonical
S-expression.  Keep in mind people may want to use this LDAP schema with
non-Java libraries: javaSerializedObject is language-specific;
S-expressions are language-independent (and are already part of the SPKI
standard).  I suggest you rename this field to "canonicalSexp".  (Note
that we can define jsdsi.Obj's serialized form to be its canonical Sexp
form.)

>  issuerPubKey (issuer public key)
Is this the hash of the key or its canonical S-expression?  I suggest
hash, as this is probably how people will search for the key.

>  subjectPubKey (subject public key)
Is this the hash of the key or its canonical S-expression?  I suggest
hash, as this is probably how people will search for the key.

What if the subject is a name?

>  name (name)
Is this the issuer name or the subject name?

> The attribute 'name' can be used as optional(if the certs are AuthCerts,
> doens't make sense the use of this). issuerPubKey and subjectPubKey are
> needed to perform searchs with the currently selectors (Auth, Subject,
> Compatible, Name), without having to desserialize the cert.

I don't think your schema actually supports NameCertSelector and
CompatibleCertSelector simultaneously: a name cert's subject might also be
a name, in which case you need separate fields for each.

So, here's my suggestion for a revised schema:

cn - canonical name: same as hashMD5
hashMD5 - the MD5 hash of the cert
hashSHA1 - the SHA1 hash of the cert
canonicalSexp - the cert as a canonical s-expression
issuerMD5 - the MD55 hash of the issuer public key
issuerSHA1 - the SHA1 hash of the issuer public key
issuerName - the name assigned by the issuer, if any
subjectMD5 - the MD55 hash of the subject public key
subjectSHA1 - the SHA1 hash of the subject public key
subjectName - the first name component of the subject, if any
notAfter - the expiration date, so the server can garbage-collect

My reason for supporting both SHA1 and MD5 is that they're both popular. 
However, if this seems too complicated, we can make these separate
records.  So each cert would have two records:

cn - MD5 hash of cert
canonicalSexp
issuer -MD5 of issuer key
issuerName
subject - MD5 of subject key
subjectName
notAfter

cn - SHA1 hash of cert
canonicalSexp
issuer - SHA1 of issuer key
issuerName
subject - SHA1 of subject key
subjectName
notAfter

But these records would have to have different type names (spkiCertMD5 and
spkiCertSHA1, perhaps?) so that people know which hash function to use.

Sameer

RE: [Jsdsi-devel] JSDSI plan

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

I'm not clued up on LDAP really, but here is my 2-pence (sorry cents
worth)..


On Wed, 2004-02-25 at 12:39, Sameer Ajmani wrote:
> Comments inline:
> 
> > Here is the schema that i'm using:
> >
> >  cn (common name for the cert), u can see this as a unique name;
> 
> This should be the cryptographic hash (MD5 or SHA1) of the cert.  This is
> guaranteed to be unique (with high probability), and it makes it easy to
> find the cert if you already have its hash.

I agree


> >  javaSerializedObject (sdsi cert), i think that is the best way to
> > represent the certs,
> 
> I disagree...
> 
> > The 'javaSerializedObject' could also be an attribute with other name
> > where is content would be an encoded sdsi cert.
> 
> The standard way to represent any SDSI/SPKI object is as a canonical
> S-expression.  Keep in mind people may want to use this LDAP schema with
> non-Java libraries: javaSerializedObject is language-specific;
> S-expressions are language-independent (and are already part of the SPKI
> standard).  I suggest you rename this field to "canonicalSexp".  (Note
> that we can define jsdsi.Obj's serialized form to be its canonical Sexp
> form.)
Agree. And making jsdi.Obj implement java.io.Serializable in canonical Sexp form
is on my list of 'things to do'...


> >  issuerPubKey (issuer public key)
> Is this the hash of the key or its canonical S-expression?  I suggest
> hash, as this is probably how people will search for the key.
Agree. 
Though shouldn't you store the MD5/SHA1 of (issuer public-key-hash) 
- If you have the public-key-hash you can search using it. If you have
the publci-key you can still do so (create the public-key-hash and then
MD5/SHA1 it).
If you store the MD5/SHA1 of public-key and only have the
public-key-hash, you wouldn't be able to.

> >  subjectPubKey (subject public key)
> Is this the hash of the key or its canonical S-expression?  I suggest
> hash, as this is probably how people will search for the key.
Agree, as above
> What if the subject is a name?
yes, what if?

> >  name (name)
> Is this the issuer name or the subject name?
> 
> > The attribute 'name' can be used as optional(if the certs are AuthCerts,
> > doens't make sense the use of this). issuerPubKey and subjectPubKey are
> > needed to perform searchs with the currently selectors (Auth, Subject,
> > Compatible, Name), without having to desserialize the cert.
> 
> I don't think your schema actually supports NameCertSelector and
> CompatibleCertSelector simultaneously: a name cert's subject might also be
> a name, in which case you need separate fields for each.
> 
> So, here's my suggestion for a revised schema:
> 
> cn - canonical name: same as hashMD5
> hashMD5 - the MD5 hash of the cert
> hashSHA1 - the SHA1 hash of the cert
> canonicalSexp - the cert as a canonical s-expression
> issuerMD5 - the MD55 hash of the issuer public key
> issuerSHA1 - the SHA1 hash of the issuer public key
> issuerName - the name assigned by the issuer, if any
> subjectMD5 - the MD55 hash of the subject public key
> subjectSHA1 - the SHA1 hash of the subject public key
> subjectName - the first name component of the subject, if any
> notAfter - the expiration date, so the server can garbage-collect
Only issue is whether to store MD5/SHA1 of (issuer public-key-hash). 
- same as regards to subject

> My reason for supporting both SHA1 and MD5 is that they're both popular. 
> However, if this seems too complicated, we can make these separate
> records.  So each cert would have two records:
> 
> cn - MD5 hash of cert
> canonicalSexp
> issuer -MD5 of issuer key
> issuerName
> subject - MD5 of subject key
> subjectName
> notAfter
> 
> cn - SHA1 hash of cert
> canonicalSexp
> issuer - SHA1 of issuer key
> issuerName
> subject - SHA1 of subject key
> subjectName
> notAfter
> 
> But these records would have to have different type names (spkiCertMD5 and
> spkiCertSHA1, perhaps?) so that people know which hash function to use.
> 
> Sameer
> 
> 
> 
> 
> 
> -------------------------------------------------------
> 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