<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>
<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>