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

[Michael StJohns]

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