Why cannot overwrite a KeyEntry with a TrustCertEntry?

Bruce Rich brich at us.ibm.com
Fri Apr 12 17:14:26 UTC 2013


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.wetmore at oracle.com>
To:     Sean Mullan <sean.mullan at oracle.com>
Cc:     security-dev at openjdk.java.net
Date:   04/11/2013 08:57 PM
Subject:        Re: Why cannot overwrite a KeyEntry with a TrustCertEntry?
Sent by:        security-dev-bounces at 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



-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/security-dev/attachments/20130412/d0865a90/attachment.htm>


More information about the security-dev mailing list