Is Entry.Attribute meant to be encrypted for a PrivateKeyEntry?

[Weijun Wang]

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.

--Max

> On Jun 3, 2019, at 10:53 PM, Michael StJohns <mstjohns at 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
> 
>