On Mon, 2 Aug 2021 19:31:54 GMT, Martin Balao <mba...@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

Reply via email to