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

[Weijun Wang]

I think you're worried about if KeyStore::getAttributes and Entry::getAttributes would return different values before a provider has the chance to implement the former. This is something we need to be very care of. Maybe the default implementation of KeyStoreSpi::engineGetAttributes should throw an UnsupportedOperationException. When Entry::getAttributes was introduced it was a new concept in KeyStore, so it made sense to return an empty collection. But now, it's not and it's worth thinking of a different default behavior.

--Max

> On Jun 4, 2019, at 9:21 AM, Michael StJohns <mstjohns at comcast.net> wrote:
> 
> 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