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

[Michael StJohns]

On 6/3/2019 7:27 PM, Weijun Wang wrote:
>
>> On Jun 4, 2019, at 1:34 AM, Michael StJohns <mstjohns at 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.

Well, you'd need to describe how the JDK implementation of PKCS12 
behaves.  Which is going to possibly be different than another 
provider's implementation.  But I take your point about hackish.


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

KeyStore depends on KeyStoreSpi and that's going to need the change too 
- but it's going to need to be a concrete method there - correct - or it 
breaks other implementations?   But Entry.Attribute is defined in 
KeyStore and KeyStore references KeyStoreSpi and I kind of hate circular 
dependencies even if java can work around them.

so

public Set<KeyStore.Entry.Attribute> 
KeyStoreSpi::engineGetAttributes(String alias) {

      return containsAlias(alias) ?  Collections.emptySet() : return null; }


and

public final Set<Entry.Attribute> KeyStore::getAttributes(String alias) {

if (!initialized) {
      throw new KeyStoreException ("Uninitialized keystore");
}

return keyStoreSpi.engine.getAttributes(alias);

}


WFM.

Mike