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

Stanley Ho (Stanley.Ho@eng.sun.com)
Fri, 23 Jul 1999 02:38:03 -0700

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: =?EUC-KR?B?vNXBpL/t?=: "plz Help !!! I have a problem using SunJCE provider"
- Previous message: Jerome Dochez: "Re: "Java Plug-In Security Warning" dialog gone / broken under 1.2.2 px"

    From: Stanley.Ho@eng.sun.com (Stanley Ho)

    Message-Id: <199907230938.CAA16445@shorter.eng.sun.com>

    Date: Fri, 23 Jul 1999 02:38:03 -0700

    To: "Jerome Dochez" <jerome.dochez@eng.sun.com>,

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

>Thanks for the answer. This unfortunetely confirm what I was suggesting
>in my first email, if the root CA are not strictly equal, the security
>check will not work. This is extremly sad because that forces people to
>use specific root CA to sign their applet. Furthermore, all deployment
>browsers would need to have to same root CA in their codestore (IE 3,4,5
>right now).
>
>Do you think we could get a better solution with some other crypto API
>(like the one I was suggesting called CertCompareCertificateName) ? I
>don't feel that each time IE comes out with a new root CA, people would
>need to resign their applet with the new CA and deploy the root CA to
>all platforms and browsers.
>
>Also, since the CAPI bug involved only NT, why not using the "old" API
>for 98 and hope it would be fixed for 2000 ?
>
>Jerome

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. 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.

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. 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.

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.

Stanley 8^)

- Next message: =?EUC-KR?B?vNXBpL/t?=: "plz Help !!! I have a problem using SunJCE provider"
- Previous message: Jerome Dochez: "Re: "Java Plug-In Security Warning" dialog gone / broken under 1.2.2 px"