> On Jun 4, 2019, at 1:34 AM, Michael StJohns <mstjo...@comcast.net> wrote:
>
> 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 looks a little too hackish to me. We'll need to describe how
PrivateKeyEntry::getPrivateKey behaves and apps would need to check for the
result, etc.
>
> This allows you not to have to retrofit other KeyStore implementations to
> support a getAttributes() method.
>
> And I *think* that works well with PKCS11.
It always works. The Entry::getAttributes will still be there.
Thanks,
Max
>
> 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
>>>
>>>
>
