Re: JAR: Archive Signing Scheme

Marianne Mueller (mrm@eng.sun.com)
Fri, 31 Jan 1997 11:27:15 -0800

Date: Fri, 31 Jan 1997 11:27:15 -0800
Message-Id: <199701311927.LAA17157@puffin.eng.sun.com>
From: Marianne Mueller <mrm@eng.sun.com>
To: eich@wor.de
Subject: Re: JAR: Archive Signing Scheme

> - Is it correct, that the Java virtual machine (of the browser) checks
> every class, before executin any network loaded code?

No, the JVM is not presently checking for signature of objects. That
is, the JVM is not dynamically checking for signatures of classes,
when it loads a class.

Instead, what happens now is this. You create a signed archive, and
distribute it as a jar file. (Refer to
http://java.sun.com/security/usingJavakey.html for info on how to do
this.)

When the jar file is read by a Java-signature-enabled browser, it
tries to verify the signature. There are several steps.

1. it un-jars the jar archive
2. it tries to verify the signature
3. it loads the Java classes

Step 1. is self-explanatory: the archive is split into files.

For step 2, an important dependency is whether or not the browser has
access to the certificate for the signer. The certificate holds the
public key of the signer, and this is needed to verify the signature.
If the local Java installation has been setup so that it already has
the certificate containing the public key of the signer, then it's
possible for the browser to do this check. If the browser does not
have the certificate of the signer, then it can't perform this check.
For this reason, you need to distribute the certificates
"offline" so to speak. That is, independent of how you distribute
a signed archive, you need to distribute the certificate that contains
your public key, to the parties that want to use your signed code.

So, assuming the client has your certificate, it can then attempt to
verify the signature. Either the signature will check out OK, or it
won't. At that point, it's up to the policy of the browser (or other
Java application) how they treat the code. In the case of the JDK 1.1
appletviewer, if the signature checks out OK, then the code is loaded
as trusted code, and given full access to the client machine. If the
signature does not check out OK, then the code is loaded as untrusted
code, and it is restricted to the applet sandbox. See
http://java.sun.com/sfaq/ for more info on those restrictions.

The appletviewer is like a browser, but it only understands one HTML
tag, the <applet> tag.

Other browsers, such as Netscape Navigator and Internet Explorer,
could integrate support for Java digital signatures, and it's our
understanding that this is the plan, but I don't know of any publicly
announced plans. I suggest you contact the browser vendors directly
and ask them what their schedule is for integrating support for Java
digital signatures.

> - Can I tell the browser not to execute any code, that isn't properly
> signed?

With JDK 1.1, the "trust" level of a signer is maintained as part of
the identity database. By default, the identity database is created
in your home directory, in a file named identitydb.obj. When you
create an identity that is to be used for signing, you create it
either as a trusted identity, or as an untrusted identity. Refer to
"Using Javakey" for more details on this, and also, please refer to
the Policy Guidelines at http://java.sun.com/security/policy.html for
some hints on how you might want to safeguard your keys and
certificates.

So, in the case of the appletviewer, if an identity is marked as
"trusted" in the identity database, and the signature can be verified,
then the code will execute with full permissions. If an identity is
marked as untrusted, then regardless of whether or not it signs some
code, that code will still be restricted to the applet sandbox.

> - About when will such browsers (esp. Netscape Navigator and Internet
> Explorer) be released?

Please contact the browser vendors directly with this question - I
don't know of any publicly announced dates.

> - What is the maximum signature-key length supported in
> Non-US-Versions?
> - or: Are signature key lengths restricted the same way like crypto keys
> by US export laws?

There isn't a restriction on key length for DSA, since DSA is a
signature-only algorithm. However, practically speaking, the key
length "1024" should be sufficient for your uses.

Thanks for your interest, and we would be interested to hear how
your application comes along.

Marianne