Name: rlT66838 Date: 11/04/99


G:\Java Projects\SDR\Local\Metadata>java -version
java version "1.2.2"
Classic VM (build JDK-1.2.2-W, native threads, symcjit)

It turns out that is at least one some undocumented (I think) assumption made
regarding the relationship between Key encodings and X509 certificates. Proper
certificate handling (without a bunch of special cases) depends on
understanding these assumptions, but figuring out what to do seens to be a
matter of trial and error. Specifically:

o The encoding of the DSA public key is structured to be a complete
  SubjectPublicKeyInfo structure for an X509 certificate. That is, the key
includes the OID, algorithm parameters, and subject public key substructures.
  To stay consistent with this assumption, any other signature implementation
(for example, an ElGamal signature algorithm) needs to produce the same
structure. The fact that "X.509" format for an encoded public key
means "SubjectPublicKeyInfo structure" should be clearly documented, perhaps in
the javadoc of Key.

o The fact that "X.509 format" includes algorithm parameters as well as the key
bit string is somewhat confusing without some additional discussion. In fact,
you might give some thought to including a ParameterizedKey interface in
java.security someplace, simply as a convenience and as a place to hang some
javadoc discussion of the relationship between X.509 and Key encodings. In the
best of all worlds, this interface would have a getAlgorithmParameter() method,
and both PublicKey and PrivateKey would extend this interface rather than Key.
Since this approach would break existing Key implementations, it's probably
undesirable, but a ParameterizedKey would help to get the point across.

o There's a critical piece of OID support missing for certificate
implementators: the link between an algorithm and its OID. Consider for example
the process of signing an X.509 certificate. Given the private key I can check
its format and figure out how to extract the necessary signature parameters. I
can even use the key algorithm to generate a new Signature of the appropriate
type. However, I've got no good way of getting the (required) OID of the
signature algorithm without consulting an external list. It'd be much cleaner
if there were a getOID() method in the appropriate places, like Signature and
Cipher objects. The Provider already has the necessary information, although
not in the right form. What about another Provider method, on the order of
getOIDFor(String name) that returned the preferred OID for the given name as it
is known to the Provider?
(Review ID: 97493)
======================================================================