There were a couple of threads about it on the users list. One for the SP from May 2022 and for the IdP in Jan 2023 (the latter is why i opened the ticket). Not sure if they are members, but it seems driven by some new-ish European requirements, particularly in Germany:

This is very unfortunate, as RSA-PSS is one of the signature algorithms the BSI approved for governmental software in Germany. Furthermore the MUK identity provider, which is to become the central login for business related eGovernment services in Germany as per OZG, decided to require this signature algorithm.
This does not seem to be a fringe use case so I am surprised that there are no plans for Shibboleth to support RSA-PSS.

and

The German cybersecurity agency (BSI) demands the use of either ECDSA or RSASSA-PSS for signing SAML messages in federal applications.

They can use BC for now, I guess. The poster on the IdP created his own AlgorithmDescriptor and it was working, so he must have installed BC.

I guess somebody asked about it on list, but I don’t think they were members, and this is never going to interop with anybody, so I don’t think it’s a priority for us. Even if it were a member, I suspect they could just use BC for now.

According to Sean Mullan @ Oracle on the Santuario dev list, these algorithm names are actually not supported and the docs are in error.

There are apparently questions/ambiguity about what these should mean vs “regular” RSA. He opened an OpenJDK ticket to remove them from docs:

https://bugs.openjdk.org/browse/JDK-8313797

The fix version there is noted as 21, so possibly the docs error will persist until the next LTS. Not clear. Oh joy.

His practical answer for doing these algorithms is to use the JCA algorithm name “RSASSA-PSS” + a PSSParameterSpec. Santuario will have to be updated to this new methodology, which should work seamlessly with BC. Not yet clear if or when they will do a release with that update.

I suppose I/we could volunteer to do a patch, but I don’t currently know the JSR 105 part of the codebase - which we do not use - so might be more time-consuming than it appears. Don’t know how much we care, since the current versions of Santuario will work, albeit only with BC installed.

There seems to be a possible bug in Oracle Java 17, either the docs or the JDK. The docs for the SunRsaSign provider:

https://docs.oracle.com/en/java/javase/17/security/oracle-providers.html#GUID-17E3589E-E4BA-4881-9B12-9880DD2D128D

clearly indicate support for the 5 RSASSA-PSS SHA-2 variants that have implicit parameters:

But they don’t work in practice, throwing NoSuchAlgorithm. My local program that iterates the providers from java.security.Security confirms that they are indeed not there. They are supported by BC, so for now the runtime algorithm and signature test are conditional on loading BC.

I’m going to send mail to the Santuario mailing list to ask about this. The docs are clearly at odds with the behavior.

There are also 4 SHA-3 variants supported by Santuario, and those are not documented as supported by vanilla Java 17, only by BC.

Implemented support for:

Digests:

Signature:

These are the ones in RFC 9231 that we didn’t yet have and that are currently supported by Santuario 2.3.2.