Message-Id: <199908271705.KAA18561@laguna.eng.sun.com>
Date: Fri, 27 Aug 1999 10:05:41 -0700 (PDT)
From: Jan Luehe <luehe@laguna.eng.sun.com>
Subject: Re: Need for "NoDigest" Signatures, other comments
To: java-security@java.sun.com, mmeyer@aurorasim.com
Matthew:
> In general, I am pleased with the current JCA/JCE specification, and am
> building my systems to these interfaces. One issue I encountered with
> building on SSL implementation to these interfaces involves the manner
> in which the SSL/TLS specification defines a digital signature with the
> RSA algorithm. If the CertificateVerify message is sent from a client
> for authentication, for example, than an RSA signature which involves a
> concatenated hash of MD5 + SHA signatures of various handshake
> quantities is used. A similar signature is used in the case that
> temporary RSA keys are used for key exchange and the server must sign
> the temporary keys with his long term signature keys. The current JCA
> specification does not currently define such a signature. One solution
> might be to define a "No Digest" signature which more less involves raw
> encryption with the private key and the appropriate padding scheme. The
> algorithm descriptor might be NoDigestwithRSA. The input then, would be
> an arbitrary hash.
In our TLS implementation, we faced a similar issue.
We had to implement a DSA signature that would sign
the (already digested) handshake messages, without digesting
them again.
What we did is supply an implementation of "RawDSA", which
extends off of the JCA Signature class and considers its input
data as part of a digest.
You could do something similar: Digest the data separately
and then pass them to the "Raw" Signature object.
> Another solution would be for RSA-based JCE ciphers
> to allow encryption operations with a private key.
Note that this is already supported in JCE.
The "Cipher.init()" method takes an instance"of "java.security.Key",
which could be a public, private, or secret key.
> This needs to be
> defined/required, however, and I don't believe the current providers
> allow for this. Note that a "SSLSignature" which implements
> Signature wouldn't work for the CertificateVerify message, because the
> inputs to the two hashing algorithms are in fact different. There are
> workarounds, such as making an RSAPrivateKey look like an RSAPublicKey,
> and vice versa, but they only work for keys which live in software and
> whose values can be queried.
>
> Finally, I am not seeing the defined algorithm/padding names for RSA
> encryption with the JCE, and looking at a few providers I am seeing in
> fact some small differences in how they name their RSA. Am I missing
> the appropriate document somewhere, or is this just a loose end that
> needs to be cleaned up in JCE?.
Yes, this needs to be added to the existing spec.
Thanks!
Jan