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 <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
>
>
