On 6/3/2019 11:05 AM, Weijun Wang wrote:
The storepass and the keypass are usually the same but they are independent. If
the Mac is there and a non-null storepass is provided at loading, then
integrity checking is performed. We do allow storepass being null in
KeyStore::load and the method spec says:
* @param password the password used to check the integrity of
* the keystore, the password used to unlock the keystore,
* or {@code null}
And now we support password-less pkcs12, i.e. key is protected, by cert is not,
and there is no Mac.
Right - and compare and contrast to PKCS11, you don't generally have a
password on the private key entry, but you do on the key store. Hmm...
Rather than change the API for KeyStore, or maybe in addition to
changing the API, you do:
If you pass in a null password (0 length password, known password
'attributesonly'?) in a PasswordProtection class in getEntry() for a
PKCS12 key store, you (optionally) get a KeyStore.Entry of an internal
concrete type that contains only the attributes.
This allows you not to have to retrofit other KeyStore implementations
to support a getAttributes() method.
And I *think* that works well with PKCS11.
Mike
--Max
On Jun 3, 2019, at 10:53 PM, Michael StJohns <mstjo...@comcast.net> wrote:
On 6/3/2019 10:18 AM, Sean Mullan wrote:
On 6/2/19 10:28 PM, Weijun Wang wrote:
I am playing with KeyStore.Entry.Attribute and found out it's only retrievable
with Entry::getAttributes. This means for a PrivateKeyEntry that is protected
with a password, you will have to provide that password to get the entry first
to get the attributes.
Is this by design? So there is no way to add public attributes to these
entries? If I read PKCS12 correctly, the attributes is out of the bag value.
Therefore even if I cannot decrypt a pkcs8ShroudedKeyBag, the attributes are
still visible.
Or am I missing something?
Probably not. Maybe we need something like a KeyStore.getAttributes(String
alias) method?
--Sean
From what I remember, the whole thing of the PKCS12 is protected by a MAC
which is calculated from the PKCS12 password which is generally the same as the
PKCS8 password for the entry. This is somewhat the same model that was in
place for the JKS version of the key store. Is it possible that the password
is necessary to validate the attribute integrity and that's why it's there?
Mike
