On Wed, 29 May 2024 02:25:18 GMT, Valerie Peng <valer...@openjdk.org> wrote:
> Well, I am somewhat concerned about the incompatibility between the CTS > support in SunJCE provider (CS3) and the ambiguity of CTS support in various > PKCS11 libraries. The default for PKCS11 is CS1 which is based on NSS but may > not apply to other PKCS11 libraries. Also, if SunPKCS11 provider (using NSS) > is placed before the SunJCE provider, wouldn't this lead to unexpected > failure since they are using different variation? Instead of enabling CTS > support by default, maybe we should only enable it when the configuration has > the variation attribute set since users are required to know which CTS > variation the underlying PKCS11 library implements... We designed this feature with the idea that the SunPKCS11 provider has to translate to CS3 always and maintain compatibility with SunJCE. If the token configuration is correct, the translation will be right and you can interchange one provider with the other for the `AES*/CTS/NoPadding` algorithms. If the token configuration is not correct, the failure will be noticed, for example, when the SunPKCS11 provider is used for Kerberos CTS authentication. Other uses might be affected as well. We thought that defining a default value based on a widely used implementation of the PKCS 11 standard —used as a reference by other implementations— was reasonable and convenient for the user. There can be tokens implementing a different variation, it's impossible to rule out. I'm personally okay with not having a default value and forcing users to define the configuration property to enable CTS. Perhaps we can document in the CSR/guide that the NSS Software Token requires CS1 as an example. @fra nferrax what do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/18898#issuecomment-2136424880
