Private Keys are cached "forever" leading to inop HTTP-TLS-servers

[Lothar Kimmeringer]

[this is a resend, my last mail seem to have been lost]

Am 15.06.2022 um 13:32 schrieb Bernd Eckenfels:
> This look to me like a bug in the PKCS11 code or - if it is documented -
> in the application. Why do you think it is in JCE?

I'm not sure if there is a SPTB (single point to blame ;-).

  - As mentioned, the contract of java.security.Key doesn't mention any
    requirements if a key should be considered usable for the whole
    duration of the process. This is no wonder given the fact, that the
    Javadoc is from Java 1.1.
  - The PKCS#11-reference documentation doesn't mention anything about
    that, either and there is a part covering PKCS-keystores that
    become unavailable for some time (e.g. USB-based ones) where this
    might be a good place for something like this to be described.

So the inaccuracy in the contract's description can be seen as bug
at least. But the question remains: Has an instance of java.security.Key
to be usable all the time (with keys that rely on resources that can
"go away", I doubt that this is enforceable) and in case they aren't, are
they supposed to become useable again automatically if the resource is
back?

If they are allowed to become unuseable (as explained, I see that as
something that is to be expected IRL) and they don't need
to automatically "repair" themselves, it's a bug in the JVM's TLS
implementation to keep it using even after the first
ProviderException occurred.

If they have to "repair themselves", it's a bug in the HSM's
PKCS#11-library and I have to compose yet another bug-report ;-)
A change in the TLS-implementation might still be considered
(as a feature request that is) to discard the unuseable key
to keep an application using this buggy library running.


Thanks and best regards,

Lothar Kimmeringer