[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
