From: George Chung <gchung@openhorizon.com>
To: "'Jan Luehe'" <Jan.Luehe@Eng>,
Subject: RE: Certificate chaining w/javakey generated DSA certificates
Date: Wed, 17 Sep 1997 14:59:42 -0700
Jan and David,
I'm working on your previous replies (thanks for the prompt responses!). In
the meantime, can you take a look at my responses below and see if I'm
"getting it"?
On Wednesday, September 17, 1997 10:49 AM, Jan Luehe
[SMTP:Jan.Luehe@Eng.Sun.COM] wrote:
> You need not follow up the chain, if you already trust
> the signer's public key, which is provided (as a certificate)
> in the PKCS#7 formatted signature block file of the jar file.
>
> If the signature verifies, and the signer's public key is stored
> in your identity database as "trusted", you're done.
This implies that appletviewer/HotJava must compare the applet signer's
certificate/public key with the certificate/public key in the local
identity database. Otherwise, an attacker could just send a signature and a
self-certified certificate saying that he's "TrustedPerson".
Experimentation bears this out. Is this correct?
> Of course, it is assumed that before you stored the signer's
> public key in your identity database, you verified the certificate
> that it came with.
But this is the hard part, right? Am I correct in assuming that this
verification of certificates isn't enforced by any available tool in the
JDK? Is this where chaining support is broken? For certificates that are CA
signed, javakey will happily install a certificate for an identity without
the corresponding certificate of the CA installed in the identityDB.
Javakey will also happily install a certificate for an identity signed by
someone purporting to be CA but signing it with the wrong private key. Even
though the identity database has CA's correct certificate installed, this
forgery is not detected.
So if I understand correctly, the basis of trust in appletviewer/HotJava is
not certificate chaining to a CA but the existence of a certificate
associated with a trusted identity in the local identity db. Authentication
of a jar corresponds to an equality check between the public key in the
identity db and the public key in the signed jar and a subsequent signature
verification.
Would it be safe to assume that in the future certificate chaining will be
supported such that all I need in my identity db is the CA's certificate?
And that the certificates that travel with signed jar files can simply be
authenticated using the CA's public key (rather than having to live in my
local identity db)? And that we can have policies such as "an applet signed
by FooBar authenticated with a certificate that this CA has signed can do
this and that."?
Am I starting to get it? Again, please bear with me...I'm not trying to be
a nit-picky, I'm just trying to understand the spirit, intent, and
direction of of the JCA.
Best Regards,
George Chung
Open Horizon, Inc.