RFR: 8271566: DSA signature length value is not accurate in P11Signature

[Martin Balao]

On Mon, 2 Aug 2021 19:31:54 GMT, Martin Balao <mbalao at openjdk.org> wrote:

> As described in JDK-8271566 [1], this patch proposal is intended to fix a problem that arises when using DSA keys that have a 256-bits (or larger) G parameter for signatures (either signing or verifying). There were some incorrect assumptions and hard-coded length values in the code before. Please note that, for example, the tuple (2048, 256) for DSA is valid according to FIPS PUB 186-4.
> 
> Beyond the specific issues in signatures, I decided to provide a broader solution and enable key parameter retrieval for other key types (EC, DH) when possible. This is, when the key is not sensitive. One thing that I should note here is that token keys (those that have the CKA_TOKEN attribute equal to 'true') are considered sensitive in this regard, at least by the NSS Software Token implementation. I don't have access to other vendor implementations but if there is any concern, we can adjust the constraint to NSS-only. However, I'm not sure which use-case would require to get private keys out of a real token, weakening its security. I'd be more conservative here and not query the values if not sure that it will succeed.
> 
> No regressions found in jdk/sun/security/pkcs11. A new test added: LargerDSAKey.
> 
> --
> [1] - https://bugs.openjdk.java.net/browse/JDK-8271566

Yes, I see what you mean. Contrary to P11PrivateKey::getFormat and P11PrivateKey::getEncodedInternal where a 'null' returned value is documented in java.security.Key, we don't have that documentation for the other interfaces such as java.security.interfaces.DSAPrivateKey. That can lead to NPE if the client casts the P11Key to the interface, invokes the method and depends on a non-null value. I will give this some thought and try to come up with something, because the information is already there and (in reality) we need it internally only. It's clear that all these interfaces were not designed with unextractable P11 keys in mind, because it makes sense to me (conceptually) to have a private key from which we can retrieve some values (public, such as the parameters) and not other ones.

-------------

PR: https://git.openjdk.java.net/jdk/pull/4961