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



Reply via email to