Using RSASSA-PSS with IdPv4

[Brent Putman]

Hi Simeon,


On 1/31/23 7:44 AM, Simeon Maxein via users wrote:
>
>
> We would like to accommodate them, but Shibboleth IdP v4 does not 
> seem to support RSASSA-PSS out of the box. Validating AuthnRequest 
> messages signed with this algorithm actually appears to work fine,


Yes, OpenSAML ultimately just passes the signature to Santuario, the 
XML Security library.  It appears to support RSASSA-PSS and Java 11+ 
now also does apparently, so on the inbound side it should work fine.


> but the IdP will not use this algorithm for signing its own outbound 
> messages even when it is requested through an 
> alg:SigningMethod-element in the SPs metadata.
>
> I looked around in the IdPs implementation and found that this is due 
> to a check in the global AlgorithmRegistry, where sha256-rsa-MGF1 is 
> not present by default. Since this registry is populated through a 
> ServiceLoader looking for AlgorithmDescriptor service providers, I 
> added my own AlgorithmDescriptor implementation derived from 
> SignatureAlgorithm into the classpath, as well as an appropriate 
> META-INF/services/org.opensaml.xmlsec.algorithm.AlgorithmDescriptor 
> file.


Yes, that is the correct mechanism to add OpenSAML support for new 
algorithms.  Santuario and the Java runtime must also support the 
algorithm, of course. The latter is checked at runtime in the 
AlgorithmRegistry at library init.

  But that's all that needs to be done on the OpenSAML side, at least 
for the "parameter-less" variants of RSASSA-PSS 
<https://www.rfc-editor.org/rfc/rfc9231#name-rsassa-pss-without-paramete>.   
More supporting code would have to be added to support signing with the 
variant that does take parameters 
<https://www.rfc-editor.org/rfc/rfc9231#name-rsassa-pss-with-parameters>, 
probably similar to how we added params for the RSA-OAEP encryption 
algorithm.


>
>
>
> However, I'm a bit concerned whether this is safe in Shibboleth IdP 
> (apart from not being officially tested) - in particular because 
> AlgorithmRegistry keeps a map of signature algorithms by key type and 
> digest, and sha256-rsa-MGF1 clashes with rsa-sha256 in that regard, 
> and which algorithm ends up in this map depends on the order in which 
> the provider-configuration files are discovered (which is at best 
> complicated and at worst unspecified).


You are correct that the AlgorithmRegistry has an issue there. This is 
pretty old code (3.0?) which dates to before the newer algorithms where 
around (or at least on anyone's radar), so it wasn't factored in that 2 
or more signing algorithms could have the same key type and digest.  
Nominally, we'll need to look at adjusting that, probably by adding 
into the indexing any additional params of the algorithm and then 
adding a new overloaded lookup method that allows specifying a non-null 
instance of those params.

However, as Scott pointed out, apparently nothing in OpenSAML is 
actually using that (yet).  I had thought we did use it, for example 
for allowing a alg:DigestMethod in an entity's metadata to hint at 
which signing algorithm to pick. (Of course it would be better if the 
metadata just indicated the actual alg:SigningMethod to use.)  But 
unless both Scott and I are missing it, we never actually implemented 
that.  So there's not actually currently an issue in the IdP that would 
be triggered by this bug.


>
> So to reduce my chance of making a blunder, I'd appreciate feedback 
> on whether this is a sensible approach 


It's very sensible, given that OpenSAML hadn't added the 
AlgorithmDescriptor yet.


> Also, I couldn't find information about plans for official / out of 
> the box support for RSASSA-PSS - is there just not enough interest in 
> this yet?


No one had brought it up yet, so we simply hadn't considered it.

Adding out-of-the-box support is easy, as you saw, so I'll open an 
issue to take a look at the newer algorithms and add any and all that 
make sense.  I'm primarily referencing this RFC, which I have consulted 
in the past, but which has a pretty recent new version that obsoletes 
the old ones:

https://www.rfc-editor.org/rfc/rfc9231

I'll also open another issue to look at the issue in the 
AlgorithmRegistry regarding the indexing and see what makes sense.

Thanks,
Brent

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20230201/6046ada7/attachment.htm>