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