Why cannot overwrite a KeyEntry with a TrustCertEntry?

[Weijun Wang]

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 <brich at 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.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
>
>
>