Re: Is Entry.Attribute meant to be encrypted for a PrivateKeyEntry?
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 wrote:
>
> On 6/3/2019 7:27 PM, Weijun Wang wrote:
>>
>>> On Jun 4, 2019, at 1:34 AM, Michael StJohns 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 KeyStoreSpi::engineGetAttributes(String
> alias) {
>
> return containsAlias(alias) ? Collections.emptySet() : return null; }
>
>
> and
>
> public final Set KeyStore::getAttributes(String alias) {
>
> if (!initialized) {
> throw new KeyStoreException ("Uninitialized keystore");
> }
>
> return keyStoreSpi.engine.getAttributes(alias);
>
> }
>
>
> WFM.
>
> Mike
Re: Is Entry.Attribute meant to be encrypted for a PrivateKeyEntry?
On 6/3/2019 7:27 PM, Weijun Wang wrote:
On Jun 4, 2019, at 1:34 AM, Michael StJohns 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
KeyStoreSpi::engineGetAttributes(String alias) {
return containsAlias(alias) ? Collections.emptySet() : return null; }
and
public final Set KeyStore::getAttributes(String alias) {
if (!initialized) {
throw new KeyStoreException ("Uninitialized keystore");
}
return keyStoreSpi.engine.getAttributes(alias);
}
WFM.
Mike
Re: Is Entry.Attribute meant to be encrypted for a PrivateKeyEntry?
> On Jun 4, 2019, at 1:34 AM, Michael StJohns 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 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
>>>
>>>
>
Re: Is Entry.Attribute meant to be encrypted for a PrivateKeyEntry?
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 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
Re: Is Entry.Attribute meant to be encrypted for a PrivateKeyEntry?
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.
--Max
> On Jun 3, 2019, at 10:53 PM, Michael StJohns 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
>
>
Re: Is Entry.Attribute meant to be encrypted for a PrivateKeyEntry?
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
Re: Is Entry.Attribute meant to be encrypted for a PrivateKeyEntry?
I just filed https://bugs.openjdk.java.net/browse/JDK-8225181. Thanks, Max > On Jun 3, 2019, at 10:18 PM, 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
Re: Is Entry.Attribute meant to be encrypted for a PrivateKeyEntry?
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
Is Entry.Attribute meant to be encrypted for a PrivateKeyEntry?
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? Thanks, Max
