# Re: "Java Plug-In Security Warning" dialog gone / broken under 1.2.2 px (FCS)?

Jan Luehe (luehe@laguna.eng.sun.com)
Fri, 23 Jul 1999 09:55:43 -0700 (PDT)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Kyle Reed: "keytool and jarsigner"
- Previous message: Jan Luehe: "Re: plz Help !!! I have a problem using SunJCE provider"

    Message-Id: <199907231655.JAA07449@laguna.eng.sun.com>

    Date: Fri, 23 Jul 1999 09:55:43 -0700 (PDT)

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

    Subject: Re: "Java Plug-In Security Warning" dialog gone / broken under  1.2.2 px  (FCS)?

    To: jerome.dochez@eng.sun.com, Stanley.Ho@eng.sun.com

Jerome, Stanley:

> I may be more appropiate to answer this question because I was
> the one who suggested to use CAPI. I don't think CertCompareCertificateName
> is appropiate because you may have certificates from the same CA with the
> same name with different public keys.

This would open a security hole, as anybody could create a self-signed
certificate with the name of any of the Root CAs in IE's database,
thereby fooling the Plug-in user about the identity of the applet
signer.

> I guess the more appropiate way to
> avoid the problem is to compare the public key of the certificate.
> If the root CA matches the public key that used to sign the signature
> of the file, then the file should be valid. Of course, this introduces
> usage of other CAPI APIs that may not work.

Right.

What we could do is enumerate the Root CA certs in IE's database
and use each to verify the Root CA cert in the applet's cert chain.
Or stop at the cert preceding the Root CA cert in the applet's chain
and try to verify that cert with the certs in IE's database.

What it comes down to: we did not want to use any unreliable CAPI APIs
that seem to work in one version of Windows, but not in another,
and were the source of a security hole in JRE 1.2.2 RC.

> The root of the problem here is that we are suggesting customers
> to use certificate for Netscape Object Signing and verify it with the
> root CA for Microsoft Authenicode. While the certificates for Netscape
> Object Signing and Microsoft Authenicode can be obtained from the same
> CA like Verisign, there is no gurantee that the root CA cert for Object
> signing and Authenicode will be the same -- which is what happens in
> this case, although they will match most of the time.

Right, this was the underlying assumption.

The VeriSign case is a special one. I have no idea why
they issued all those Class 3 Root CA certs with different validity
dates (extending to 2004, 2018, and 2028).
Thawte seems to have a more consistent story: All their Root CAs
are valid until 2020, so the problem would not have shown up in their
case.

> The ultimate
> solution in the long run may probably be providing our own list of root
> CA cert with the JDK/JRE, so we can verify the RSA signed file without
> using the CAPI or IE's root CA store, and it will work for all platforms.

Of course, if we start shipping all those Root CAs in our own
keystore, there will be some liability issues that we did not
want to address with this release.

> Avoiding the CAPI bug in NT is not a good solution because each
> version of IE has its own version of CAPI which contains a different
> set of bugs. In other words, it is not easy to have a fix to work on
> 95/98/NT for all versions of IE.

I agree.

Jan

- Next message: Kyle Reed: "keytool and jarsigner"
- Previous message: Jan Luehe: "Re: plz Help !!! I have a problem using SunJCE provider"