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 <mstjo...@comcast.net> wrote:
>
> On 6/3/2019 7:27 PM, Weijun Wang wrote:
>>
>>> 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.
>
> 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
