system property to use legacy RSA PSS algorithm names

Add a check for a system property "org.jose4j.jws.use-legacy-rsapss-alg-names" that when "true" will use the older style algorithm names (<digest>with<encryption>and<mgf> -> SHA256withRSAandMGF1, SHA384withRSAandMGF1, and SHA512withRSAandMGF1) for the RSASSA-PSS class of JWS algs (PS256, PS384 and PS512).

For a long long time Java’s default security providers didn’t support RSA PSS at all. So the bouncy castle provider or an HSM was needed, if one wanted to use the PS256, PS384 or PS512 JWS algs.

Java 11 and later versions of Java 8 (>= u251 apparently) have introduced RSA PSS support with the name RSASSA-PSS (and a PSSParameterSpec). With the resolution to Issue ~~#129~~ (out with 0.6.5) jose4j started preferring the new RSASSA-PSS name so as to allow use of the PS256, PS384 and PS512 JWS algs using only the security providers of the Java runtime.

Most, if not all, HSM providers utilize only the older style algorithm names for RSA PSS. Deployments using an HSM and jose4j > 0.6.5 will encounter problems singing with RSA PSS when moving to a Java version that has native RSASSA-PSS support. Basically this is because the RSASSA-PSS name is preferred by jose4j, so it ends up trying to use the Java software PSS implementation with an HSM backed key (that can’t leave the HSM), which doesn’t work.

This is related to Issue ~~#175~~ RSA-PSS support for both JCA algorithm naming standards". The resolution to that was the introduction of a SignatureAlgorithmOverride on ProviderContext that allows for the caller to get past the alg name problem by specifying a name and parameter spec for the particular JWS to use to create the underlying signature rather than the normal defaults. Using that, however, will require application code changes.

Setting the aforementioned system property should allow for deployments using an HSM provider to continue working as before when moving to a Java version with native RSASSA-PSS support.

‌

Comments (4)