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

[Valerie Peng]

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

As for your changes to P11Key class, I wonder why NSS doesn't make the "extractable" attribute false for their token keys? I agree that this change makes sense for NSS given their current impl but not sure how other vendor may be impacted by this. So, how about:
1) keep this change specific to NSS.
2) now that various P11XXXPrivateKey classes can also be sensitive and un-extractable, perhaps we should just make P11PrivateKey class a general class which these P11XXXPrivateKey extends from and store the "sensitiveKey" logic inside the P11PrivateKey constructor. This way, you don't need to change the constructor signature to add this extra boolean argument. The subclasses can just access the field in P11PrivateKey class and decide.
3) for RSA private keys, instead of just use P11PrivateKey, it could still use P11RSAPrivateNonCRTKey if the CRT attributes aren't available due to being a token key. Or, perhaps availability of public exponent attribute would give an indication?

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

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