Hi Brent,
On 8/8/23 7:39 PM, Brent Putman wrote:
Hi Sean,
On 8/8/23 4:05 PM, Sean Mullan wrote:
As mentioned before, you can implement this in the Santuario layer by
instantiating the algorithms as "RSASSA-PSS" and passing in an
appropriate PSSParameterSpec with the default values as specified by
RFC 6931. I recommend this technique as it should work for either BC
or JDK providers that support the RSASSA-PSS algorithm and the
particular parameters of those algorithms. It isn't a lot of code to
do that.
Sure, I understood what you suggested before wrt to usage of the JDK's
API. But as I said before, I can not personally do this, as I am not
orchestrating the Java JCA calls here - it's Santuario. We (the
OpenSAML/Shibboleth project) are mere users of the Santuario library.
Santuario would have to update its methodology as you describe, and do
new releases. At a minimum, JCEMapper would have to update the
URI->JCA algorithm name mappings (trivial) and SignatureBaseRSA would
have to start supplying a PSSParameterSpec with the implicit values in
the nested subclasses that support those URIs (less trivial, but
probably easy). (And I imagine also need to update the corresponding
classes used in the JSR 105 impl, but I'm not familiar with that.)
So unless/until that happens, users of existing Santuario versions
will be limited to using BC, which (possibly erroneously) uses the
<digest>withRSAandMGF1 algorithm names.
So unlike what I thought when I started this thread, it appears this
IS now a Santuario issue. Are there opinions about whether and when
Santuario should be updated to this new methodology? It seems it ought
to be a backward compatible change for any other provider (like BC)
that supports "RSASSA-PSS", but that assumption needs to be validated.
Yes, sorry I guess I wasn't clear enough. This is a Santuario issue. I
can probably post a PR in the next few days that addresses this. To me
this is the best solution if you want to provide a solution that works
both with BC and the JDK. Even if we did add direct support to the JDK
for the PSS w/o param algorithm URIs as defined in RFC 9231, it would
initially only be supported in the next version of JDK (22), and would
need justification, etc in order to be backported to earlier releases.
So best to have a solution that works across all JDK versions that
already have RSASSA-PSS support.
Also for some reason, I thought you were a Santuario Committer, so sorry
if I implied you could do the work. :)
Further discussion needs to be made in the JDK area as to whether
algorithms like "SHA256withRSAandMGF1" are standard and what that
means; ex - it isn't clear that it is for RSASSA-PSS and not RSA. RFC
6931 is at a higher layer than the RSA specifications, so it is not
the standard we necessarily adhere to at the JCE layer. Thus, more
discussion on that is needed.
Ok, understood. I was guided by what was in the JDK docs and the
existing impls, but you're saying some of this may simply be wrong.
I'll point out in passing that RFC 9231 clearly (and as an RFC I would
think canonically?) defines the corresponding algorithm URIs in
question as RSASSA-PSS without Parameters
<https://www.rfc-editor.org/rfc/rfc9231#name-rsassa-pss-without-paramete>
and they do not contain "SSA" or "PSS" or similar in the trailing
parts. In fact they look much like the JCA algorithm names in terms of
the sub-parts they contain, e.g. "#sha256-rsa-MGF1" vs
"SHA256withRSAandMGF1".
I don't know if the RFC URIs were modeled after the (now retracted)
JCA names (or vice versa) - the RFC isn't Java-specific obviously -
but at least some people across different projects/efforts apparently
thought they were representing the same thing. Just an observation.
Sorry, I don't know the history of RFC 9231 there enough to comment.
--Sean
Again, thanks for taking the time to look into this. Much appreciated.
--Brent
