Re: JDK 1.1

Marianne Mueller (mrm@eng.sun.com)
Tue, 11 Feb 1997 20:25:48 -0800

Date: Tue, 11 Feb 1997 20:25:48 -0800
Message-Id: <199702120425.UAA24251@puffin.eng.sun.com>
From: Marianne Mueller <mrm@eng.sun.com>
To: Wmccoubre@aol.com
Subject: Re: JDK 1.1

(... cc'ing the list so the Q&A is archived ...)

To verify Java signatures in your own standalone application, you
should use the java.security.* APIs. Specifically you would
want to use java.security.Signature.verify. Refer to the API
documentation at
http://java.sun.com/products/JDK/1.1/docs/api/java.security.Signature.html

You wouldn't invoke javakey to verify the signatures, but rather
invoke the Signature methods directly. The process would look
something like

* create an instance of Signature
* initialize it
* send in the data to be verified via the update method
* invoke the verify method

Marianne

> From: Wmccoubre@aol.com
> Date: Fri, 7 Feb 1997 17:02:19 -0500 (EST)
> cc: Wmccoubre@aol.com
>
> Hello,
> Thanks for the swift response. Just to clarify:
>
> >wmccoubre@aol.com wrote:
> >1. I read in the javakey manpages that verification is not implemented. Is
> there a >date as to when this will be supported.
>
> >>Marianne.Mueller@Eng.Sun.COM replied:
> >>Verification is implemented in the JDK 1.1 appletviewer, certainly!
>
> Yes, the appletviewer does currently support verification, but I would like
> to write
> a java application of my own (not a browser) which could verify digital
> signatures signed using Javakey. That is,
> 1, My classloader would use javakey verification to determine if the
> signature
> accompanying the archive file was authentic and none of the
> files in the
> archive were tampered with. (integrity & authentication)
>
> 2. My classloader would attach the identify of the signer of the
> archive
> to each of the classes contained in the archive file (via the
> "setSigners"
> method on classloader).
>
> 3. My security manager would use javakey's database of entities to
> determine if the signer of a particular object is trusted or
> not. In this
> way, the sand-box for trusted java bytecode could be relaxed.
>
>
>
>
>
>
>