# Re: Relationship between Certificate & other classes

Jan Luehe (luehe@laguna.eng.sun.com)
Thu, 13 Aug 1998 16:05:41 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Previous message: Shahzad Bhatti: "digital certificates"
- Maybe in reply to: Roni Korenshtein: "Relationship between Certificate & other classes"

    Date: Thu, 13 Aug 1998 16:05:41 -0700 (PDT)

    From: Jan Luehe <luehe@laguna.eng.sun.com>

    Subject: Re: Relationship between Certificate & other classes

    To: java-security@java.Sun.COM, ronikoren@yahoo.com

Roni:

> Is this true:
> 1. When Keystore saves a certificate instance
> it simply calls cert.getType() and cert.getEncoded()
> and writes the String and byte array.

Yes (in the FCS version).

> 2. When Keystore loads a certificate instance
> it simply reads a string representing the type
> then it gets an instance of a certificate factory
> which corresponds to this type and calls its
> generateCertificate method passing it the stream
> containing the byte array

Yes.

> 3. there are only 2 ways directly supported by the JCA
> classes to instantiate a certificate:
> 1. by calling a constructor which calls super(type)

Yes.

> 2. by pointing a certificate factory instance of a
> specific type at an input stream containing
> bytes which represent the content of the
> resultant instance

Yes.

> 4. there is only one way to save a certificate instance
> in secondary storage: call getEncoded and
> save it as is or parse it (if you know the structure), extract
> the info from it and save it
> in any other way you want, as long as you have
> a factory that knows how to read this saved format.

Yes. But why would you ever do the latter?

> 5. getType returns a string representing the type
> of certificate this is. this type has 2 meanings:
> 1. it indicates what logical information
> are stored in this cerificate
> 2. it indicates what getEncoded returns which is
> its externalized format.

Yes.

> the current implementation therefore dictates
> that for a given type of "logical" certificate
> there is 1 and no more than 1 standard for writing
> this type out to a file.

Yes. The default encoding is ASN.1, if an ASN.1
specification for that type exists. In the case of
X.509, getEncoded() should always return the ASN.1
encoding of the cert, and a cert factory for X.509
expects the certificate data it parses to be
ASN.1 encoded.

>
> Questions:
>
> 1. why is Cerificate so unique and different from
> the rest of the JCA? why aren't there a
> CertificateGenerator, CertificateSpec,
> AlgorithmParameterSpec, etc' in a manner consistent
> with other JCA components?

Good question.

We may provide certificate generation support in a
separate Java extension package. This would include
CertificateSpec's, etc.

We decided not to provide that functionality in the JDK core,
because we felt that supplying just certificate creation
API methods/classes without support for the underlying (CA)
infrastructure was not sufficient.

> 2. assuming 5 above is correct... why is that?
> as in model-view pattern
> shouldn't there be a separation between
> abstract logical content of the certificate (model)
> and its many possible externalized formats (views)?

Yes,

> 3. KeyStore allows accessing the certChain
> but replacing the certificate chain requires
> the password. why is that?

The (Private)Key object and its supporting chain are always stored
together, in order to allow for checks that the public key in
the user certificate of the certChain actually "matches"
the private key that it is associated with.
It's an additional protection level: This way, you cannot
accidentally override the certChain associated with a (private)
key, which would mean that you "lost" the public key
corresponding to your private key.

> and is the answer consistent with
> the fact that setCertificateEntry does not require
> a password

... because passwords are used to protect (private or
secret) Key objects (and "setCertificateEntry" does not have a Key
object parameter).

> 4. it would be nice if keyStore allowed an object
> of type Object to be stored in the keystore
> in association with the alias.
> it would be even nicer if there could be 2 objects
> one of which was pasword protected.
> if these objects were serializable KeyStore
> would be more user friendly.

But this would mean too much of a restriction for the
implementors of those objects, because they would have
to make their objects serializable. This may
not always be acceptable (as we know from other cases).

> currently if one wants
> to save "other info" associated with the alias
> one has to either create some higher level association which
> wraps KeyStore
> or implement one's own KeyStoreSpi.

Yes. We limited the type of security credentials that can be
stored in a KeyStore to the ones for which we have defined
corresponding factory objects (KeyFactory, CertificateFactory).
This way, not only is the keystore implementation provider-based,
but also the credentials contained in a keystore.

> (5. How does RMI handle Certificates if they're not
> serializable?)

RMI would have to define a wrapper of type "Serializable"
around Certificate objects like this:

class Foo implements Serializable {
private transient Certificate cert;
...
}

It would then override the "writeObject" method to call "getType()"
followed by "getEncoded()", and override the "readObject" method
to instantiate a cert factory of the appropriate type and have
it parse the encoded data. (This is what we do internally in the
JDK, when a class that holds certificates implements "Serializable".)

Hope this helps.

Thanks,

Jan

- Previous message: Shahzad Bhatti: "digital certificates"
- Maybe in reply to: Roni Korenshtein: "Relationship between Certificate & other classes"