Date: Thu, 28 May 1998 10:25:16 -0300
From: Rodrigo Sodre <rsodre@br.oracle.com>
To: java-security@web1.javasoft.com
Subject: Signer applet
Greetings.
We're developing an applet that must sign some data befote its storage
in a databank. The client user fills some forms and then download a
certified applet, already loaded with the data to be signed. Well, in
this moment the private key must be used (it will be used DSA algorith
and keys since it is already implemented) and we are considering two
approaches:
1) The applet will generate the public/private key pair, ask the
client to type a password to encrypt the private key (we will
implement the cipher class since Sun's KeyStorage implementation
uses a weak one), AND BOTH WOULD BE STORED IN THE DATABANK. When
signing, THE APPLET WOULD BE ALREADY LOADED WITH THE DATA AND THE
ENCRYPTED PRIVATE KEY. The user types its password, the private key
is then decrypted, used for signing, and then discarded. When the
server receives the signed form, it would retrive the public key
and verify the signature. If OK, the form is stored, otherwise an
error message would be shown to the user by the applet.
2) In the second approach, when generating the pair, ONLY THE PUBLIC
KEY IS SENT AND THE PRIVATE KEY IS ENCRYPTED AND STORED IN A FILE
IN THE USER MACHINE. When signing, THE APPLET WOULD REQUEST THIS
FILE, ask the password and the following steps are the same.
The first approach is far more easy to be used by the client user:
he/she doesn't need to provide a file containing the private key, it can
be used in any machine with a browser (and not only in the machines
where the file would be stored), no special access rights must be given
to the applet (the certificate is used only for authenticity).
What seems strange to me is the private key remains with another entity,
even encripted. But in both approaches the client is trusting the applet
not to reveal the plain private key to anyone, so the first argument may
not justify approach 2. I guess I'm excessive paranoic.
Please send comments about these approaches, and other ones if possible.
Thanks in advance and best regards.
Rodrigo Sodre - rsodre@br.oracle.com