<html><head/><body><html><head></head><body>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?<br>
<br>
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.<br>
<br>
Consequences of misuse can be mentioned in the Javadoc, and you can wrap your KeyStore in appropriate protective code to manage it properly.<br>
<br>
Matthew.<br>
-- <br>
Sent from my mobile device.<br><br><div class="gmail_quote">Bruce Rich <brich@us.ibm.com> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<font size="2" face="sans-serif">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.</font>
<br /><font size="2" face="sans-serif">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.</font>
<br /><font size="2" face="sans-serif">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.</font>
<br /><font size="2" face="sans-serif"><br />
Bruce A Rich<br />
brich at-sign us dot ibm dot com<br />
</font>
<br />
<br />
<br />
<br /><font size="1" color="#5f5f5f" face="sans-serif">From:
</font><font size="1" face="sans-serif">Brad Wetmore <bradford.wetmore@oracle.com></font>
<br /><font size="1" color="#5f5f5f" face="sans-serif">To:
</font><font size="1" face="sans-serif">Sean Mullan <sean.mullan@oracle.com></font>
<br /><font size="1" color="#5f5f5f" face="sans-serif">Cc:
</font><font size="1" face="sans-serif">security-dev@openjdk.java.net</font>
<br /><font size="1" color="#5f5f5f" face="sans-serif">Date:
</font><font size="1" face="sans-serif">04/11/2013 08:57 PM</font>
<br /><font size="1" color="#5f5f5f" face="sans-serif">Subject:
</font><font size="1" face="sans-serif">Re: Why cannot
overwrite a KeyEntry with a TrustCertEntry?</font>
<br /><font size="1" color="#5f5f5f" face="sans-serif">Sent by:
</font><font size="1" face="sans-serif">security-dev-bounces@openjdk.java.net</font>
<br />
<hr noshade="noshade" />
<br />
<br />
<br /><tt><font size="2"><br />
<br />
On 4/11/2013 7:47 AM, Sean Mullan wrote:<br />
> On 04/11/2013 04:36 AM, Weijun Wang wrote:<br />
>> Hi All<br />
>><br />
>> The KeyStore::setCertificateEntry has<br />
>><br />
>> * @exception KeyStoreException if the keystore has not been initialized,<br />
>> * or the given alias already exists and does not identify an<br />
>> * entry containing a trusted certificate,<br />
>> * or this operation fails for some other reason.<br />
>><br />
>> which means you cannot overwrite a KeyEntry with a TrustCertEntry.
While<br />
>> setKeyEntry allows a TrustCertEntry been overwritten by a KeyEntry.<br />
>><br />
>> This has been true from the beginning, but why?<br />
><br />
> I'm not sure, but the exact reason is probably now lost in the sands
of<br />
> time ;)<br />
><br />
>> On the other hand, setEntry mentions no restriction, although
the<br />
>> current implementations (jks, pkcs12) fail when overwriting a
KeyEntry<br />
>> with a TrustCertEntry.<br />
><br />
> The only thing I can think of is that it protects against accidental<br />
> overwriting of your private key, which might be a good thing, if you<br />
> haven't backed it up.<br />
<br />
That was added in April 1998.<br />
<br />
4129553: KeyStore should store any type of "Key", not just "PrivateKey"<br />
<br />
I *THINK* what Sean states was the reason, but before my time.<br />
<br />
Brad<br />
<br />
<br />
</font></tt>
<br /></blockquote></div></body></html></body></html>