CertSelectors

AuthCertSelector(Principal issuer, Auth a)

Should match all AuthCerts that are issued by issuer and whose Auth implies a. For backwards compatibility, AuthCertSelector(Principal issuer) should be defined as:

{
  this(issuer, new Auth(Tag.NONE_TAG,false));
}

IssuerCertSelector(Principal issuer)

Should match all Certs issued by issuer. None of the Prover algorithms requires this, but it might be useful.

Impact on CertStores

We want anyone implementing a JSDSI CertStore to support as many of these CertSelectors as possible.

Parsing

Parsing should be done using Rats (see below) rather than hand-implemented code. The latter is just too ugly and hard to maintain. Can unparsing be done automatically, too? [ rats ]

We might want to define the lexical level of JSDSI to be S-expressions, then define a parser that understands the string form of S-expressions and generates the appropriate objects. For example, our input file might have:

jsdsi.Hash HASH = LIST("hash" a:STRING v:STRING) {
  return new jsdsi.Hash(a, v);
}

Algorithm-specific objects

We should move the crypto-algorithm-specific stuff out of the SPKI objects. Not sure how to do this, but it's annoying to have to maintain an "RSAPublicKey" class that's separate from the Java version of that class. But then again, we need a way to translate public keys into SPKI/SDSI format. Perhaps what we need here is a KeyFactory (Java's cl ass for encoding and decoding keys)? But we also need a generic way to pass Principals around, and this is usually just a wrapper for a public key.

Algorithm strings

Keeping all the algorithm strings straight is a pain. Keys, signatures, and other objects each have an algorithm string. This has to be encoded in a SPKI-friendly way (i.e., certain chars are not allowed). But this algo name may be different from the one that the crypto provider uses! (cf. rsa-pkcs1-md5 and MD5/RSA/PKCS#1). We could invent some canonical translation, but that seems silly.