<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>Hi Simeon,</p>
<p><br>
</p>
<div class="moz-cite-prefix">On 1/31/23 7:44 AM, Simeon Maxein via
users wrote:<br>
</div>
<blockquote type="cite"
cite="mid:eccc5b8f-6769-a3fb-8e30-668cb78f750f@chamaeleon.de"><br>
<br>
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,</blockquote>
<p><br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:eccc5b8f-6769-a3fb-8e30-668cb78f750f@chamaeleon.de"> 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.
<br>
<br>
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.
<br>
</blockquote>
<p><br>
</p>
<p>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.</p>
<p> But that's all that needs to be done on the OpenSAML side, at
least for the <a moz-do-not-send="true"
href="https://www.rfc-editor.org/rfc/rfc9231#name-rsassa-pss-without-paramete">"parameter-less"
variants of RSASSA-PSS</a>. More supporting code would have to
be added to support signing with the <a moz-do-not-send="true"
href="https://www.rfc-editor.org/rfc/rfc9231#name-rsassa-pss-with-parameters">variant
that does take parameters</a>, probably similar to how we added
params for the RSA-OAEP encryption algorithm.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:eccc5b8f-6769-a3fb-8e30-668cb78f750f@chamaeleon.de">
<br>
<br>
<br>
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).
<br>
</blockquote>
<p><br>
</p>
<p>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.<br>
</p>
<p>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.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:eccc5b8f-6769-a3fb-8e30-668cb78f750f@chamaeleon.de">
<br>
So to reduce my chance of making a blunder, I'd appreciate
feedback on whether this is a sensible approach </blockquote>
<p><br>
</p>
<p>It's very sensible, given that OpenSAML hadn't added the
AlgorithmDescriptor yet.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:eccc5b8f-6769-a3fb-8e30-668cb78f750f@chamaeleon.de">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?
<br>
</blockquote>
<p><br>
</p>
<p>No one had brought it up yet, so we simply hadn't considered it.</p>
<p>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:</p>
<p><a class="moz-txt-link-freetext" href="https://www.rfc-editor.org/rfc/rfc9231">https://www.rfc-editor.org/rfc/rfc9231</a></p>
<p>I'll also open another issue to look at the issue in the
AlgorithmRegistry regarding the indexing and see what makes sense.</p>
<p>Thanks,<br>
Brent<br>
</p>
<br>
</body>
</html>