Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Is JSS 4.3.2 released? I'm looking for the Mozilla signed jar.

22 views
Skip to first unread message

Bob Foss

unread,
Apr 30, 2010, 9:38:53 AM4/30/10
to
I apologize for asking twice; I suspect my earlier message was buried
since I originally replied to an old thread.


Robert Relyea wrote:
> The NSS team has just RTM'ed NSS 3.12.6.
> The primary feature of NSS 3.12.6 is support for the TLS
Renegotiation Indication Extension, RFC 5746.
>
> Release notes are forthcoming with other additions and bug fixes.
>
> In addition, a new version of JSS has been released, JSS 4.3.2 which
allows application to control the default behaviors in using the extension.
>
> For JSS 4.3.2 see:
>
> https://bugzilla.mozilla.org/show_bug.cgi?id=530575
>

There are no artifacts on the ftp site for JSS 4.3.2:
ftp://ftp.mozilla.org/pub/mozilla.org/security/jss/releases/

Has 4.3.2 been marked RTM?

Unfortunately, Sun's JRE requires signed jars for JCE providers,
so the Mozilla signed jar file is pretty useful.

Thank you.

Nelson B Bolyard

unread,
Apr 30, 2010, 1:17:31 PM4/30/10
to mozilla's crypto code discussion list
On 2010-04-30 06:38 PST, Bob Foss wrote:
> I apologize for asking twice; I suspect my earlier message was buried
> since I originally replied to an old thread.

Yes, it's released, at least in source form.

I herewith speculate that this will have been the final release of JSS.

At about the same time as Oracle's acquisition of Sun, three of Sun's
NSS development team members left Sun. One of them was Sun's lead JSS
developer. I was another of them.

> Unfortunately, Sun's JRE requires signed jars for JCE providers,
> so the Mozilla signed jar file is pretty useful.

Signed bits may be available directly from Sun. It's also conceivable
that IBM or some other other big proponents of Java may be able to sign
those bits if they find it in their interest to do so.

Marsh Ray

unread,
Apr 30, 2010, 1:25:27 PM4/30/10
to mozilla's crypto code discussion list
On 4/30/2010 12:17 PM, Nelson B Bolyard wrote:
>
>> Unfortunately, Sun's JRE requires signed jars for JCE providers,
>> so the Mozilla signed jar file is pretty useful.
>
> Signed bits may be available directly from Sun. It's also conceivable
> that IBM or some other other big proponents of Java may be able to sign
> those bits if they find it in their interest to do so.

Perhaps it would be possible to install your own root cert and sign it
yourself?

Probably not the simplest procedure. If you get it working it would be
nice to post a description for others.

- Marsh

Nelson B Bolyard

unread,
Apr 30, 2010, 1:34:43 PM4/30/10
to mozilla's crypto code discussion list
On 2010-04-30 10:25 PST, Marsh Ray wrote:
> On 4/30/2010 12:17 PM, Nelson B Bolyard wrote:
>>> Unfortunately, Sun's JRE requires signed jars for JCE providers,
>>> so the Mozilla signed jar file is pretty useful.
>> Signed bits may be available directly from Sun. It's also conceivable
>> that IBM or some other other big proponents of Java may be able to sign
>> those bits if they find it in their interest to do so.
>
> Perhaps it would be possible to install your own root cert and sign it
> yourself?
>
> Probably not the simplest procedure. If you get it working it would be
> nice to post a description for others.
>
> - Marsh

Interesting thought. NSS even includes a JAR signing tool that was
originally written for this purpose (among others). But I suspect that
Sun's JVM requires that the signature come from one of a very select few
roots any not just any old trusted root. Hope I'm wrong!

Bob Foss

unread,
Apr 30, 2010, 1:51:45 PM4/30/10
to mozilla's crypto code discussion list

Everything, I've read indicates that a JCE Provider's signing cert must
be signed by a cert from Sun (or maybe IBM).

http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step6

Marsh Ray

unread,
Apr 30, 2010, 2:11:07 PM4/30/10
to mozilla's crypto code discussion list, Bob Foss
On 4/30/2010 12:51 PM, Bob Foss wrote:
>
> Everything, I've read indicates that a JCE Provider's signing cert
> must be signed by a cert from Sun (or maybe IBM).
>
> http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step6

http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step61
:
> You will receive an email message containing two plain-text file
> attachments: one file containing this code-signing certificate and
> another file containing its own CA certificate, which authenticates its
> public key. Please also allow five business days from receipt of your
> request for processing.
>
> 5. Use keytool to import the certificates received from the CA.
>
> Once you have received the two certificates from the JCA Code
> Signing Certification Authority, you can use keytool to import them
> into your keystore.
>
> First import the CA's certificate as a "trusted certificate":
>
> keytool -import -alias <alias for the CA cert> \ -file <CA cert file
> name> \ -keystore <keystore file name> \ -storepass <keystore
> password>
>
> Then import the code-signing certificate:
...

This would seem to imply that you can add your own CA for code-signing
purposes.

If you think about it, Sun once had developers too who presumably needed
to test their code without being given access to the official code
signing CA.

- Marsh

Marsh Ray

unread,
Apr 30, 2010, 2:46:42 PM4/30/10
to mozilla's crypto code discussion list
Something was bothering me about this document...

On 4/30/2010 1:11 PM, Marsh Ray wrote:
>
> http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step61
> :
>> You will receive an email message containing two plain-text file
>> attachments: one file containing this code-signing certificate and
>> another file containing its own CA certificate, which authenticates its
>> public key. Please also allow five business days from receipt of your
>> request for processing.

>> ...


>> First import the CA's certificate as a "trusted certificate":

So, it turns out that the entire Java crypto infrastructure is built
atop plain old unauthenticated RFC-822 email after all.

Could any attackers could be so organized as to intercept port 25 email
and quietly substitute their own root CA certificate, thereby gaining
trusted code execution access to the systems which will later be used to
build officially-signed crypto provider packages?

http://en.wikipedia.org/wiki/Operation_Aurora

- Marsh

Bob Foss

unread,
Apr 30, 2010, 3:02:02 PM4/30/10
to mozilla's crypto code discussion list
Marsh Ray wrote:
> On 4/30/2010 12:51 PM, Bob Foss wrote:
>> Everything, I've read indicates that a JCE Provider's signing cert
>> must be signed by a cert from Sun (or maybe IBM).
>>
>> http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step6
>
> http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step61
> :
>> You will receive an email message containing two plain-text file
>> attachments: one file containing this code-signing certificate and
>> another file containing its own CA certificate, which authenticates its
>> public key. Please also allow five business days from receipt of your
>> request for processing.
>>
>> 5. Use keytool to import the certificates received from the CA.
>>
>> Once you have received the two certificates from the JCA Code
>> Signing Certification Authority, you can use keytool to import them
>> into your keystore.
>>
>> First import the CA's certificate as a "trusted certificate":
>>
>> keytool -import -alias <alias for the CA cert> \ -file <CA cert file
>> name> \ -keystore <keystore file name> \ -storepass <keystore
>> password>
>>
>> Then import the code-signing certificate:
> ....

>
> This would seem to imply that you can add your own CA for code-signing
> purposes.
>
> If you think about it, Sun once had developers too who presumably needed
> to test their code without being given access to the official code
> signing CA.
>
> - Marsh

Here you are importing the certificate into a keystore which is
only used to sign your jar file. It's not a keystore that contains
the root CA used to verify all JCE providers when loaded by the JVM.

I'm not sure where they stored away the root CA(s).

I have read that the OpenJDK doesn't have this restriction;
unfortunately, I cannot switch at this time. That will probably
be the long term solution.

Since, the restriction is primarily on the actual crypto algorithms,
I'm going to see if I can rebuild with the 3 SSL classes in a separate
jar ahead in the classpath.

Thank you.

Marsh Ray

unread,
Apr 30, 2010, 3:36:28 PM4/30/10
to dev-tec...@lists.mozilla.org
On 4/30/2010 2:02 PM, Bob Foss wrote:
>
> Here you are importing the certificate into a keystore which is
> only used to sign your jar file. It's not a keystore that contains
> the root CA used to verify all JCE providers when loaded by the JVM.

But if that were the case, why would they send you CA cert and instruct
"First import the CA's certificate as a 'trusted certificate'" and "Then
import the code-signing certificate"?

Regardless, one shouldn't go about trusting CA certs as they land in
your inbox. It's the equivalent of clicking on a link in email to
"verify your PayPal account information".

> I'm not sure where they stored away the root CA(s).

The doc mentions
"sun.security.provider.JavaKeyStore" and
"com.sun.crypto.provider.JceKeyStore"

If, in fact, there is something magic about the signatures on
code-signing certs, strace and/or grep should be able to answer that.

> I have read that the OpenJDK doesn't have this restriction;
> unfortunately, I cannot switch at this time. That will probably
> be the long term solution.

I think so, too. :-)

- Marsh

Nelson B Bolyard

unread,
Apr 30, 2010, 3:41:36 PM4/30/10
to mozilla's crypto code discussion list
On 2010/04/30 11:11 PDT, Marsh Ray wrote:
> On 4/30/2010 12:51 PM, Bob Foss wrote:
>>
>> Everything, I've read indicates that a JCE Provider's signing cert
>> must be signed by a cert from Sun (or maybe IBM).
>>
>> http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step6
>
> http://java.sun.com/javase/6/docs/technotes/guides/security/crypto/HowToImplAProvider.html#Step61
> :
>> You will receive an email message containing two plain-text file
>> attachments: one file containing this code-signing certificate and
>> another file containing its own CA certificate, which authenticates its
>> public key. Please also allow five business days from receipt of your
>> request for processing.
>>
>> 5. Use keytool to import the certificates received from the CA.
>>
>> Once you have received the two certificates from the JCA Code
>> Signing Certification Authority, you can use keytool to import them
>> into your keystore.
>>
>> First import the CA's certificate as a "trusted certificate":
>>
>> keytool -import -alias <alias for the CA cert> \ -file <CA cert file
>> name> \ -keystore <keystore file name> \ -storepass <keystore
>> password>
>>
>> Then import the code-signing certificate:

> ...
>
> This would seem to imply that you can add your own CA for code-signing
> purposes.
>
> If you think about it, Sun once had developers too who presumably needed
> to test their code without being given access to the official code
> signing CA.

Marsh, I think you're assuming that that CA cert is self-signed.
I'll bet it chains to a Sun CA, and must do so to work.

Wan-Teh Chang

unread,
Apr 30, 2010, 11:19:09 PM4/30/10
to mozilla's crypto code discussion list
On Fri, Apr 30, 2010 at 6:38 AM, Bob Foss <bob.e...@gmail.com> wrote:
>
> There are no artifacts on the ftp site for JSS 4.3.2:
> ftp://ftp.mozilla.org/pub/mozilla.org/security/jss/releases/
>
> Has 4.3.2 been marked RTM?
>
> Unfortunately, Sun's JRE requires signed jars for JCE providers,
> so the Mozilla signed jar file is pretty useful.

I believe Red Hat's NSS team can also sign the "Mozilla-JSS"
JCE providers.

In fact, you can apply for a signing certificate for "Mozilla-JSS"
for your organization from Sun. The instructions are at
http://www.mozilla.org/projects/security/pki/jss/provider_notes.html#signed-jar

Wan-Teh

Bob Foss

unread,
May 3, 2010, 11:15:08 AM5/3/10
to
Bob Foss wrote:
> Since, the restriction is primarily on the actual crypto algorithms,
> I'm going to see if I can rebuild with the 3 SSL classes in a separate
> jar ahead in the classpath.

I just wanted to post a follow-up, that I was able to build a second
jss-ssl.jar which just contained org.mozilla.jss.ssl.* and put it in
the classpath ahead of jss.jar and use the new API.


For completeness, I attempted also including JSSProvider or
CryptoManager in the jar and when I did that I got the expected error:

java.lang.SecurityException: class "org.mozilla.jss.CryptoManager"'s
signer information does not match signer information of other classes in
the same package
at java.lang.ClassLoader.checkCerts(Unknown Source)
at java.lang.ClassLoader.preDefineClass(Unknown Source)
at java.lang.ClassLoader.defineClass(Unknown Source)
at java.security.SecureClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.defineClass(Unknown Source)
at java.net.URLClassLoader.access$000(Unknown Source)
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClassInternal(Unknown Source)


Thank you.

Nelson B Bolyard

unread,
May 4, 2010, 1:01:01 PM5/4/10
to mozilla's crypto code discussion list
On 2010-04-30 06:38 PST, Bob Foss wrote:

> There are no artifacts on the ftp site for JSS 4.3.2:
> ftp://ftp.mozilla.org/pub/mozilla.org/security/jss/releases/

Check again. You may find it has been updated.

Bob Foss

unread,
May 4, 2010, 3:30:36 PM5/4/10
to

Thank you.

0 new messages