Can we just remove all restrictions so that
set{Entry|CertEntry|KeyEntry} always overwrites everything? It's the
caller's duty to protect existing entries. For example, keytool.
This is a behavior change, but I doubt any program dares to depend on it.
Thanks
Max
On 4/13/13 1:31 AM, Matthew Hall wrote:
If I cannot overwrite an existing alias, how am I supposed to refresh
expired certificates and keys with new copies of themselves, without
creating a race that could lose an entry if the VM dies at a bad moment?
All the weird and byzantine KeyStore restrictions feel too much like the
APIs trying to be too clever, and they end up restricting me from doing
things that I want to be able to support in my application. I would
prefer if the API allowed me to perform any key management actions I
might need, even if they might not always seem rational to the designers.
Consequences of misuse can be mentioned in the Javadoc, and you can wrap
your KeyStore in appropriate protective code to manage it properly.
Matthew.
--
Sent from my mobile device.
Bruce Rich <br...@us.ibm.com> wrote:
Although no one really remembers why, I suspect in a prehistoric
world where you only had TrustedCertificateEntry and
PrivateKeyEntry, you might allow an upgrade from TCE to PKE with the
assumption that the certificate is the same and we are really just
adding the private key.
So in that scenario, it makes sense that you might allow an
overwrite, rather than requiring the user to delete the certificate
(by its alias) first and then add the PrivateKeyEntry (which
includes cert chain) back with the same alias.
And then when SecretKeyEntry came along, it picked up the
PrivateKeyEntry override of an alias either by accident or because
it was assumed to be a superpower possessed by *KeyEntry beings.
Seems like a bug/unintended feature to me. The general case
should be that you can't overwrite an extant alias. Just thinking
out loud, here.
Bruce A Rich
brich at-sign us dot ibm dot com
From: Brad Wetmore <bradford.wetm...@oracle.com>
To: Sean Mullan <sean.mul...@oracle.com>
Cc: security-dev@openjdk.java.net
Date: 04/11/2013 08:57 PM
Subject: Re: Why cannot overwrite a KeyEntry with a TrustCertEntry?
Sent by: security-dev-boun...@openjdk.java.net
------------------------------------------------------------------------
On 4/11/2013 7:47 AM, Sean Mullan wrote:
> On 04/11/2013 04:36 AM, Weijun Wang wrote:
>> Hi All
>>
>> The KeyStore::setCertificateEntry has
>>
>> * @exception KeyStoreException if the keystore has not been
initialized,
>> * or the given alias already exists and does not identify an
>> * entry containing a trusted certificate,
>> * or this operation fails for some other reason.
>>
>> which means you cannot overwrite a KeyEntry with a
TrustCertEntry. While
>> setKeyEntry allows a TrustCertEntry been overwritten by a KeyEntry.
>>
>> This has been true from the beginning, but why?
>
> I'm not sure, but the exact reason is probably now lost in the
sands of
> time ;)
>
>> On the other hand, setEntry mentions no restriction, although the
>> current implementations (jks, pkcs12) fail when overwriting a
KeyEntry
>> with a TrustCertEntry.
>
> The only thing I can think of is that it protects against accidental
> overwriting of your private key, which might be a good thing, if you
> haven't backed it up.
That was added in April 1998.
4129553: KeyStore should store any type of "Key", not just "PrivateKey"
I *THINK* what Sean states was the reason, but before my time.
Brad
