On 12/21/2021 1:26 PM, Sean Mullan wrote:
On Tue, 21 Dec 2021 16:31:57 GMT, Weijun Wang <wei...@openjdk.org> wrote:
Before password-less PKCS12 keystores are supported, certificates in a PKCS12
file are always encrypted. Therefore if one loads the keystore with a null
pass, it contains `PrivateKeyEntry`s without certificates. This has always been
awkward (and most likely useless) so when JDK-8076190 introduced the
password-less feature I also added a line to remove such an entry.
https://github.com/openjdk/jdk/blob/a729a70c0119ed071ff490b0dfd4e3e2cb1a5ae4/src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java#L2272
Unfortunately, the line is not coded correctly, it should have been
`remove(key)` but here it's `remove(value)`.
This code change correctly removes the entry.
That said, this behavior, although weird, has been there from the beginning
since PKCS12 keystore was introduced. If you can find out a usage of a private
key entry without any certificate and think it's worth kept that way, I can
simply remove the `remove` call and leave the entry there.
I still think it's useful even if I can't see the certificate chain. I'd rather
see the entry if it actually exists in the keystore and I think removing it is
odd because it still exists in the keystore. Also, sometimes I use keytool
without a storepass just to see what is in it, and then if I see the
certificates are not showing up, I can try again with the password.
-------------
PR: https://git.openjdk.java.net/jdk/pull/6910
I got curious and took a look at P11KeyStore.java -
https://github.com/openjdk/jdk/blob/master/src/jdk.crypto.cryptoki/share/classes/sun/security/pkcs11/P11KeyStore.java
- and it appears to do exactly the opposite of what you've got here.
E.g. if there's no certificate that matches up with the private key,
then it returns a null - that's in engineGetEntry() around line 963.
Speaking personally, I've always found it a bit annoying that a
KeyStore.PrivateKeyEntry required a certificate(chain). It actually
made dealing with PKCS11 painful as the Java conventions didn't always
conform to the actual structure of the PKCS11 contents.
Not suggesting that a change necessarily needs to be made, but perhaps
you might want to have a consistent behavior between the two?
Mike