You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@santuario.apache.org by Brent Putman <pu...@georgetown.edu> on 2023/08/04 04:27:34 UTC
Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
This is not a Santuario issue per se, but it's sort of related and
there are people on the list like Colm and Sean who might have info...
In OpenSAML was working on adding support for the RSASSA-PSS algorithms
(only those with implicit params) from RFC 9231:
https://shibboleth.atlassian.net/browse/OSJ-372
The TL/DR is: The docs for the SunRsaSign provider in at least Java 17
claim to support algorithm IDs like "SHA256withRSAandMGF1". But in
practice they all throw NoSuchAlgorithmException.
Iterating the providers in the JDK and the algorithm IDs supported
confirms that they are not listed.
Those are the algorithm IDs expected by Santuario in JCEMapper for the
corresponding URIs from RFC 9231, such as
http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1.
This seems like a huge discrepancy between the JDK docs and the JDK
behavior. Anyone know anything? Unless I'm missing something, seems
like a possible bug in the JDK, at least with respect to the docs.
(Such algorithm IDs are supported and do work when using Bouncy Castle
as a security provider.)
Thanks,
Brent
Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
Posted by Sean Mullan <se...@oracle.com>.
Great - thanks for testing!
—Sean
On Oct 11, 2023, at 11:43 PM, Brent Putman <pu...@georgetown.edu>> wrote:
Hi,
Sorry this took longer to get to than I anticipated. I wanted to report back on this before the upcoming Santuario releases.
I have tested OpenSAML against a local build of xmlsec 3.0.3-SNAPSHOT, under JDK 17 which is the baseline for our current branch. The new RSASSA-PSS stuff seems to work ok. I have unit tests that exercise signing and validation of all 9 of the PSS algorithm URIs, so I'd say it looks good as far as I can tell as this point.
Thanks for working on this!
Thanks,
Brent
On 9/13/23 1:31 PM, Brent Putman wrote:
Hi Sean,
Thanks for working on this. I'll see about doing some local build testing in the next few days.
Thanks,
Brent
On 9/12/23 8:45 AM, Sean Mullan wrote:
Hi Brent,
I have fixed this issue [1] and it will be in the next 2.3.4 and 3.0.3 releases of Santuario. However, if you have a chance to pull the latest sources and do a local build to see if it addresses your concerns, that would be great and provide more assurance that it is working.
Thanks,
Sean
[1] https://issues.apache.org/jira/browse/SANTUARIO-604
On 8/10/23 4:26 PM, Brent Putman wrote:
On 8/10/23 1:15 PM, Sean Mullan wrote:
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.
Ok, thanks! Yes, I agree that it's the best solution, and should be transparent to users of the library.
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.
Yes, and even if it was in 22, it wouldn't help us much (OpenSAML/Shib) as we baseline only on LTS releases and so the release of our new 5.0 in the next few weeks will be on 17.
Also for some reason, I thought you were a Santuario Committer, so sorry if I implied you could do the work. :)
Ah, understood. Yeah, only Scott from our team is currently a Santuario committer.
--Brent
Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
Posted by Brent Putman <pu...@georgetown.edu>.
Hi,
Sorry this took longer to get to than I anticipated. I wanted to
report back on this before the upcoming Santuario releases.
I have tested OpenSAML against a local build of xmlsec 3.0.3-SNAPSHOT,
under JDK 17 which is the baseline for our current branch. The new
RSASSA-PSS stuff seems to work ok. I have unit tests that exercise
signing and validation of all 9 of the PSS algorithm URIs, so I'd say
it looks good as far as I can tell as this point.
Thanks for working on this!
Thanks,
Brent
On 9/13/23 1:31 PM, Brent Putman wrote:
> Hi Sean,
>
> Thanks for working on this. I'll see about doing some local build
> testing in the next few days.
>
> Thanks,
> Brent
>
>
> On 9/12/23 8:45 AM, Sean Mullan wrote:
>> Hi Brent,
>>
>> I have fixed this issue [1] and it will be in the next 2.3.4 and
>> 3.0.3 releases of Santuario. However, if you have a chance to pull
>> the latest sources and do a local build to see if it addresses your
>> concerns, that would be great and provide more assurance that it is
>> working.
>>
>> Thanks,
>> Sean
>>
>> [1] https://issues.apache.org/jira/browse/SANTUARIO-604
>>
>> On 8/10/23 4:26 PM, Brent Putman wrote:
>>>
>>> On 8/10/23 1:15 PM, Sean Mullan wrote:
>>>> 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.
>>>
>>>
>>> Ok, thanks! Yes, I agree that it's the best solution, and should be
>>> transparent to users of the library.
>>>
>>>
>>>> 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.
>>>
>>>
>>> Yes, and even if it was in 22, it wouldn't help us much
>>> (OpenSAML/Shib) as we baseline only on LTS releases and so the
>>> release of our new 5.0 in the next few weeks will be on 17.
>>>
>>>
>>>> Also for some reason, I thought you were a Santuario Committer, so
>>>> sorry if I implied you could do the work. :)
>>>
>>>
>>> Ah, understood. Yeah, only Scott from our team is currently a
>>> Santuario committer.
>>>
>>> --Brent
>>>
Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
Posted by Brent Putman <pu...@georgetown.edu>.
Hi Sean,
Thanks for working on this. I'll see about doing some local build
testing in the next few days.
Thanks,
Brent
On 9/12/23 8:45 AM, Sean Mullan wrote:
> Hi Brent,
>
> I have fixed this issue [1] and it will be in the next 2.3.4 and
> 3.0.3 releases of Santuario. However, if you have a chance to pull
> the latest sources and do a local build to see if it addresses your
> concerns, that would be great and provide more assurance that it is
> working.
>
> Thanks,
> Sean
>
> [1] https://issues.apache.org/jira/browse/SANTUARIO-604
>
> On 8/10/23 4:26 PM, Brent Putman wrote:
>>
>> On 8/10/23 1:15 PM, Sean Mullan wrote:
>>> 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.
>>
>>
>> Ok, thanks! Yes, I agree that it's the best solution, and should be
>> transparent to users of the library.
>>
>>
>>> 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.
>>
>>
>> Yes, and even if it was in 22, it wouldn't help us much
>> (OpenSAML/Shib) as we baseline only on LTS releases and so the
>> release of our new 5.0 in the next few weeks will be on 17.
>>
>>
>>> Also for some reason, I thought you were a Santuario Committer, so
>>> sorry if I implied you could do the work. :)
>>
>>
>> Ah, understood. Yeah, only Scott from our team is currently a
>> Santuario committer.
>>
>> --Brent
>>
Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
Posted by Sean Mullan <se...@oracle.com>.
Hi Brent,
I have fixed this issue [1] and it will be in the next 2.3.4 and 3.0.3
releases of Santuario. However, if you have a chance to pull the latest
sources and do a local build to see if it addresses your concerns, that
would be great and provide more assurance that it is working.
Thanks,
Sean
[1] https://issues.apache.org/jira/browse/SANTUARIO-604
On 8/10/23 4:26 PM, Brent Putman wrote:
>
> On 8/10/23 1:15 PM, Sean Mullan wrote:
>> 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.
>
>
> Ok, thanks! Yes, I agree that it's the best solution, and should be
> transparent to users of the library.
>
>
>> 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.
>
>
> Yes, and even if it was in 22, it wouldn't help us much (OpenSAML/Shib)
> as we baseline only on LTS releases and so the release of our new 5.0 in
> the next few weeks will be on 17.
>
>
>> Also for some reason, I thought you were a Santuario Committer, so
>> sorry if I implied you could do the work. :)
>
>
> Ah, understood. Yeah, only Scott from our team is currently a Santuario
> committer.
>
> --Brent
>
Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
Posted by Brent Putman <pu...@georgetown.edu>.
On 8/10/23 1:15 PM, Sean Mullan wrote:
> 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.
Ok, thanks! Yes, I agree that it's the best solution, and should be
transparent to users of the library.
> 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.
Yes, and even if it was in 22, it wouldn't help us much (OpenSAML/Shib)
as we baseline only on LTS releases and so the release of our new 5.0
in the next few weeks will be on 17.
> Also for some reason, I thought you were a Santuario Committer, so
> sorry if I implied you could do the work. :)
Ah, understood. Yeah, only Scott from our team is currently a
Santuario committer.
--Brent
Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
Posted by Sean Mullan <se...@oracle.com>.
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
>
Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
Posted by Brent Putman <pu...@georgetown.edu>.
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.
>
> 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.
Again, thanks for taking the time to look into this. Much appreciated.
--Brent
Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
Posted by Sean Mullan <se...@oracle.com>.
On 8/8/23 3:33 PM, Brent Putman wrote:
> Hi Sean,
>
> If that's the answer, then I guess we'll have to live with it. It would
> have been nicer to see the opposite resolution - make the impl fit the
> docs, esp since the JDK does already fundamentally support the
> underlying algorithm. Is there any notion that these will be
> implemented in a future JDK release?
>
> I suppose what this means going forward is that right now, Santuario
> will only be able to support the corresponding algorithm URIs via Bouncy
> Castle.
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.
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.
--Sean
>
> Thanks,
> Brent
>
>
> On 8/8/23 2:35 PM, Sean Mullan wrote:
>> Hi Brent,
>>
>> The JDK docs for the SunRsaSign provider are incorrect, and we don't
>> support those algorithm names. A bug has been filed to correct that:
>> https://bugs.openjdk.org/browse/JDK-8313797
>>
>> I am still looking into your other questions, will get back to you
>> when I have more info.
>>
>> --Sean
>>
>> On 8/4/23 3:26 PM, Brent Putman wrote:
>>> Ok, great, thanks for looking into it!
>>>
>>> --Brent
>>>
>>>
>>> On 8/4/23 3:12 PM, Sean Mullan wrote:
>>>> Yeah, I get it, I need to chat with some folks here first that worked
>>>> on this before I can give you a better response.
>>>>
>>>> --Sean
>>>>
>>>> On 8/4/23 2:55 PM, Brent Putman wrote:
>>>>> Hi Sean,
>>>>>
>>>>> I understood that was how to do the RSA PSS algorithm with explicit
>>>>> parameters, which in Java is done with a PSSParameterSpec. For XML
>>>>> Signature that corresponds with this RFC URI:
>>>>>
>>>>> http://www.w3.org/2007/05/xmldsig-more#rsa-pss
>>>>>
>>>>> I'm instead talking here about the ones that have implicit/defaulted
>>>>> parameters, where the MGF, salt length and trailer field are
>>>>> defaulted (and the digest method is carried as usual in the
>>>>> algorithm ID). Such as this one:
>>>>>
>>>>> http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1
>>>>>
>>>>> So it's not my understanding that in Java one passes
>>>>> PSSParameterSpec with those, such as "SHA256withRSAandMGF1". All
>>>>> params are defaulted with those - that's the whole purpose of those
>>>>> variants. (And it would be problematic I think to pass the param
>>>>> spec with those, because you could specify in the params say SHA-512
>>>>> as the digest method, which could be inconsistent with the JCA
>>>>> algorithm ID, as the one above.)
>>>>>
>>>>> But most importantly, I'm not doing any of this. It's Santuario
>>>>> that specifies how the actual Java cryptography works, and for those
>>>>> URIs it uses the Java algorithm ID variants in question, not
>>>>> "RSASSA-PSS". When I attempt the #sha256-rsa-MGF1 URI, it throws
>>>>> under Java 17 with NoSuchAlgorithm. I am merely observing from
>>>>> additional testing that those algorithm IDs are in fact documented
>>>>> in Java 17 for SunRsaSign, but yet do not actually work.
>>>>>
>>>>> The code in Santuario's JCEMapper and SignatureBaseRSA agrees with
>>>>> this understanding. Running with BC loaded works fine also, so they
>>>>> have the same understanding.
>>>>>
>>>>> Thanks
>>>>> Brent
>>>>>
>>>>>
>>>>> On 8/4/23 2:13 PM, Sean Mullan wrote:
>>>>>> Hi Brent,
>>>>>>
>>>>>> You need to pass the MGF and other parameters in a PSSParameterSpec
>>>>>> to the Signature algorithm, like so:
>>>>>>
>>>>>> Signature sig = Signature.getInstance("RSASSA-PSS", "SunRsaSign")
>>>>>> sig.setParameter(new PSSParameterSpec("SHA-256", "MGF1",
>>>>>> MGF1ParameterSpec.SHA256, 32, PSSParameterSpec.TRAILER_FIELD_BC));
>>>>>>
>>>>>> I think the JDK docs could be improved to clarify this, so I'll
>>>>>> file a bug to have this fixed.
>>>>>>
>>>>>> --Sean
>>>>>>
>>>>>> On 8/4/23 12:27 AM, Brent Putman wrote:
>>>>>>> This is not a Santuario issue per se, but it's sort of related and
>>>>>>> there are people on the list like Colm and Sean who might have
>>>>>>> info...
>>>>>>>
>>>>>>> In OpenSAML was working on adding support for the RSASSA-PSS
>>>>>>> algorithms (only those with implicit params) from RFC 9231:
>>>>>>>
>>>>>>> https://shibboleth.atlassian.net/browse/OSJ-372
>>>>>>>
>>>>>>> The TL/DR is: The docs for the SunRsaSign provider in at least
>>>>>>> Java 17 claim to support algorithm IDs like
>>>>>>> "SHA256withRSAandMGF1". But in practice they all throw
>>>>>>> NoSuchAlgorithmException.
>>>>>>>
>>>>>>> Iterating the providers in the JDK and the algorithm IDs supported
>>>>>>> confirms that they are not listed.
>>>>>>>
>>>>>>> Those are the algorithm IDs expected by Santuario in JCEMapper for
>>>>>>> the corresponding URIs from RFC 9231, such as
>>>>>>> http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1.
>>>>>>>
>>>>>>> This seems like a huge discrepancy between the JDK docs and the
>>>>>>> JDK behavior. Anyone know anything? Unless I'm missing
>>>>>>> something, seems like a possible bug in the JDK, at least with
>>>>>>> respect to the docs.
>>>>>>>
>>>>>>> (Such algorithm IDs are supported and do work when using Bouncy
>>>>>>> Castle as a security provider.)
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Brent
>>>>>>>
>>>>>>>
>>>>>>>
Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
Posted by Brent Putman <pu...@georgetown.edu>.
Hi Sean,
If that's the answer, then I guess we'll have to live with it. It would
have been nicer to see the opposite resolution - make the impl fit the
docs, esp since the JDK does already fundamentally support the
underlying algorithm. Is there any notion that these will be
implemented in a future JDK release?
I suppose what this means going forward is that right now, Santuario
will only be able to support the corresponding algorithm URIs via
Bouncy Castle.
Thanks,
Brent
On 8/8/23 2:35 PM, Sean Mullan wrote:
> Hi Brent,
>
> The JDK docs for the SunRsaSign provider are incorrect, and we don't
> support those algorithm names. A bug has been filed to correct that:
> https://bugs.openjdk.org/browse/JDK-8313797
>
> I am still looking into your other questions, will get back to you
> when I have more info.
>
> --Sean
>
> On 8/4/23 3:26 PM, Brent Putman wrote:
>> Ok, great, thanks for looking into it!
>>
>> --Brent
>>
>>
>> On 8/4/23 3:12 PM, Sean Mullan wrote:
>>> Yeah, I get it, I need to chat with some folks here first that worked
>>> on this before I can give you a better response.
>>>
>>> --Sean
>>>
>>> On 8/4/23 2:55 PM, Brent Putman wrote:
>>>> Hi Sean,
>>>>
>>>> I understood that was how to do the RSA PSS algorithm with explicit
>>>> parameters, which in Java is done with a PSSParameterSpec. For XML
>>>> Signature that corresponds with this RFC URI:
>>>>
>>>> http://www.w3.org/2007/05/xmldsig-more#rsa-pss
>>>>
>>>> I'm instead talking here about the ones that have implicit/defaulted
>>>> parameters, where the MGF, salt length and trailer field are
>>>> defaulted (and the digest method is carried as usual in the
>>>> algorithm ID). Such as this one:
>>>>
>>>> http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1
>>>>
>>>> So it's not my understanding that in Java one passes
>>>> PSSParameterSpec with those, such as "SHA256withRSAandMGF1". All
>>>> params are defaulted with those - that's the whole purpose of those
>>>> variants. (And it would be problematic I think to pass the param
>>>> spec with those, because you could specify in the params say SHA-512
>>>> as the digest method, which could be inconsistent with the JCA
>>>> algorithm ID, as the one above.)
>>>>
>>>> But most importantly, I'm not doing any of this. It's Santuario
>>>> that specifies how the actual Java cryptography works, and for those
>>>> URIs it uses the Java algorithm ID variants in question, not
>>>> "RSASSA-PSS". When I attempt the #sha256-rsa-MGF1 URI, it throws
>>>> under Java 17 with NoSuchAlgorithm. I am merely observing from
>>>> additional testing that those algorithm IDs are in fact documented
>>>> in Java 17 for SunRsaSign, but yet do not actually work.
>>>>
>>>> The code in Santuario's JCEMapper and SignatureBaseRSA agrees with
>>>> this understanding. Running with BC loaded works fine also, so they
>>>> have the same understanding.
>>>>
>>>> Thanks
>>>> Brent
>>>>
>>>>
>>>> On 8/4/23 2:13 PM, Sean Mullan wrote:
>>>>> Hi Brent,
>>>>>
>>>>> You need to pass the MGF and other parameters in a PSSParameterSpec
>>>>> to the Signature algorithm, like so:
>>>>>
>>>>> Signature sig = Signature.getInstance("RSASSA-PSS", "SunRsaSign")
>>>>> sig.setParameter(new PSSParameterSpec("SHA-256", "MGF1",
>>>>> MGF1ParameterSpec.SHA256, 32, PSSParameterSpec.TRAILER_FIELD_BC));
>>>>>
>>>>> I think the JDK docs could be improved to clarify this, so I'll
>>>>> file a bug to have this fixed.
>>>>>
>>>>> --Sean
>>>>>
>>>>> On 8/4/23 12:27 AM, Brent Putman wrote:
>>>>>> This is not a Santuario issue per se, but it's sort of related and
>>>>>> there are people on the list like Colm and Sean who might have
>>>>>> info...
>>>>>>
>>>>>> In OpenSAML was working on adding support for the RSASSA-PSS
>>>>>> algorithms (only those with implicit params) from RFC 9231:
>>>>>>
>>>>>> https://shibboleth.atlassian.net/browse/OSJ-372
>>>>>>
>>>>>> The TL/DR is: The docs for the SunRsaSign provider in at least
>>>>>> Java 17 claim to support algorithm IDs like
>>>>>> "SHA256withRSAandMGF1". But in practice they all throw
>>>>>> NoSuchAlgorithmException.
>>>>>>
>>>>>> Iterating the providers in the JDK and the algorithm IDs supported
>>>>>> confirms that they are not listed.
>>>>>>
>>>>>> Those are the algorithm IDs expected by Santuario in JCEMapper for
>>>>>> the corresponding URIs from RFC 9231, such as
>>>>>> http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1.
>>>>>>
>>>>>> This seems like a huge discrepancy between the JDK docs and the
>>>>>> JDK behavior. Anyone know anything? Unless I'm missing
>>>>>> something, seems like a possible bug in the JDK, at least with
>>>>>> respect to the docs.
>>>>>>
>>>>>> (Such algorithm IDs are supported and do work when using Bouncy
>>>>>> Castle as a security provider.)
>>>>>>
>>>>>> Thanks,
>>>>>> Brent
>>>>>>
>>>>>>
>>>>>>
Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
Posted by Sean Mullan <se...@oracle.com>.
Hi Brent,
The JDK docs for the SunRsaSign provider are incorrect, and we don't
support those algorithm names. A bug has been filed to correct that:
https://bugs.openjdk.org/browse/JDK-8313797
I am still looking into your other questions, will get back to you when
I have more info.
--Sean
On 8/4/23 3:26 PM, Brent Putman wrote:
> Ok, great, thanks for looking into it!
>
> --Brent
>
>
> On 8/4/23 3:12 PM, Sean Mullan wrote:
>> Yeah, I get it, I need to chat with some folks here first that worked
>> on this before I can give you a better response.
>>
>> --Sean
>>
>> On 8/4/23 2:55 PM, Brent Putman wrote:
>>> Hi Sean,
>>>
>>> I understood that was how to do the RSA PSS algorithm with explicit
>>> parameters, which in Java is done with a PSSParameterSpec. For XML
>>> Signature that corresponds with this RFC URI:
>>>
>>> http://www.w3.org/2007/05/xmldsig-more#rsa-pss
>>>
>>> I'm instead talking here about the ones that have implicit/defaulted
>>> parameters, where the MGF, salt length and trailer field are
>>> defaulted (and the digest method is carried as usual in the
>>> algorithm ID). Such as this one:
>>>
>>> http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1
>>>
>>> So it's not my understanding that in Java one passes
>>> PSSParameterSpec with those, such as "SHA256withRSAandMGF1". All
>>> params are defaulted with those - that's the whole purpose of those
>>> variants. (And it would be problematic I think to pass the param
>>> spec with those, because you could specify in the params say SHA-512
>>> as the digest method, which could be inconsistent with the JCA
>>> algorithm ID, as the one above.)
>>>
>>> But most importantly, I'm not doing any of this. It's Santuario
>>> that specifies how the actual Java cryptography works, and for those
>>> URIs it uses the Java algorithm ID variants in question, not
>>> "RSASSA-PSS". When I attempt the #sha256-rsa-MGF1 URI, it throws
>>> under Java 17 with NoSuchAlgorithm. I am merely observing from
>>> additional testing that those algorithm IDs are in fact documented
>>> in Java 17 for SunRsaSign, but yet do not actually work.
>>>
>>> The code in Santuario's JCEMapper and SignatureBaseRSA agrees with
>>> this understanding. Running with BC loaded works fine also, so they
>>> have the same understanding.
>>>
>>> Thanks
>>> Brent
>>>
>>>
>>> On 8/4/23 2:13 PM, Sean Mullan wrote:
>>>> Hi Brent,
>>>>
>>>> You need to pass the MGF and other parameters in a PSSParameterSpec
>>>> to the Signature algorithm, like so:
>>>>
>>>> Signature sig = Signature.getInstance("RSASSA-PSS", "SunRsaSign")
>>>> sig.setParameter(new PSSParameterSpec("SHA-256", "MGF1",
>>>> MGF1ParameterSpec.SHA256, 32, PSSParameterSpec.TRAILER_FIELD_BC));
>>>>
>>>> I think the JDK docs could be improved to clarify this, so I'll
>>>> file a bug to have this fixed.
>>>>
>>>> --Sean
>>>>
>>>> On 8/4/23 12:27 AM, Brent Putman wrote:
>>>>> This is not a Santuario issue per se, but it's sort of related and
>>>>> there are people on the list like Colm and Sean who might have
>>>>> info...
>>>>>
>>>>> In OpenSAML was working on adding support for the RSASSA-PSS
>>>>> algorithms (only those with implicit params) from RFC 9231:
>>>>>
>>>>> https://shibboleth.atlassian.net/browse/OSJ-372
>>>>>
>>>>> The TL/DR is: The docs for the SunRsaSign provider in at least
>>>>> Java 17 claim to support algorithm IDs like
>>>>> "SHA256withRSAandMGF1". But in practice they all throw
>>>>> NoSuchAlgorithmException.
>>>>>
>>>>> Iterating the providers in the JDK and the algorithm IDs supported
>>>>> confirms that they are not listed.
>>>>>
>>>>> Those are the algorithm IDs expected by Santuario in JCEMapper for
>>>>> the corresponding URIs from RFC 9231, such as
>>>>> http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1.
>>>>>
>>>>> This seems like a huge discrepancy between the JDK docs and the
>>>>> JDK behavior. Anyone know anything? Unless I'm missing
>>>>> something, seems like a possible bug in the JDK, at least with
>>>>> respect to the docs.
>>>>>
>>>>> (Such algorithm IDs are supported and do work when using Bouncy
>>>>> Castle as a security provider.)
>>>>>
>>>>> Thanks,
>>>>> Brent
>>>>>
>>>>>
>>>>>
Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
Posted by Brent Putman <pu...@georgetown.edu>.
Ok, great, thanks for looking into it!
--Brent
On 8/4/23 3:12 PM, Sean Mullan wrote:
> Yeah, I get it, I need to chat with some folks here first that worked
> on this before I can give you a better response.
>
> --Sean
>
> On 8/4/23 2:55 PM, Brent Putman wrote:
>> Hi Sean,
>>
>> I understood that was how to do the RSA PSS algorithm with explicit
>> parameters, which in Java is done with a PSSParameterSpec. For XML
>> Signature that corresponds with this RFC URI:
>>
>> http://www.w3.org/2007/05/xmldsig-more#rsa-pss
>>
>> I'm instead talking here about the ones that have implicit/defaulted
>> parameters, where the MGF, salt length and trailer field are
>> defaulted (and the digest method is carried as usual in the
>> algorithm ID). Such as this one:
>>
>> http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1
>>
>> So it's not my understanding that in Java one passes
>> PSSParameterSpec with those, such as "SHA256withRSAandMGF1". All
>> params are defaulted with those - that's the whole purpose of those
>> variants. (And it would be problematic I think to pass the param
>> spec with those, because you could specify in the params say SHA-512
>> as the digest method, which could be inconsistent with the JCA
>> algorithm ID, as the one above.)
>>
>> But most importantly, I'm not doing any of this. It's Santuario
>> that specifies how the actual Java cryptography works, and for those
>> URIs it uses the Java algorithm ID variants in question, not
>> "RSASSA-PSS". When I attempt the #sha256-rsa-MGF1 URI, it throws
>> under Java 17 with NoSuchAlgorithm. I am merely observing from
>> additional testing that those algorithm IDs are in fact documented
>> in Java 17 for SunRsaSign, but yet do not actually work.
>>
>> The code in Santuario's JCEMapper and SignatureBaseRSA agrees with
>> this understanding. Running with BC loaded works fine also, so they
>> have the same understanding.
>>
>> Thanks
>> Brent
>>
>>
>> On 8/4/23 2:13 PM, Sean Mullan wrote:
>>> Hi Brent,
>>>
>>> You need to pass the MGF and other parameters in a PSSParameterSpec
>>> to the Signature algorithm, like so:
>>>
>>> Signature sig = Signature.getInstance("RSASSA-PSS", "SunRsaSign")
>>> sig.setParameter(new PSSParameterSpec("SHA-256", "MGF1",
>>> MGF1ParameterSpec.SHA256, 32, PSSParameterSpec.TRAILER_FIELD_BC));
>>>
>>> I think the JDK docs could be improved to clarify this, so I'll
>>> file a bug to have this fixed.
>>>
>>> --Sean
>>>
>>> On 8/4/23 12:27 AM, Brent Putman wrote:
>>>> This is not a Santuario issue per se, but it's sort of related and
>>>> there are people on the list like Colm and Sean who might have
>>>> info...
>>>>
>>>> In OpenSAML was working on adding support for the RSASSA-PSS
>>>> algorithms (only those with implicit params) from RFC 9231:
>>>>
>>>> https://shibboleth.atlassian.net/browse/OSJ-372
>>>>
>>>> The TL/DR is: The docs for the SunRsaSign provider in at least
>>>> Java 17 claim to support algorithm IDs like
>>>> "SHA256withRSAandMGF1". But in practice they all throw
>>>> NoSuchAlgorithmException.
>>>>
>>>> Iterating the providers in the JDK and the algorithm IDs supported
>>>> confirms that they are not listed.
>>>>
>>>> Those are the algorithm IDs expected by Santuario in JCEMapper for
>>>> the corresponding URIs from RFC 9231, such as
>>>> http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1.
>>>>
>>>> This seems like a huge discrepancy between the JDK docs and the
>>>> JDK behavior. Anyone know anything? Unless I'm missing
>>>> something, seems like a possible bug in the JDK, at least with
>>>> respect to the docs.
>>>>
>>>> (Such algorithm IDs are supported and do work when using Bouncy
>>>> Castle as a security provider.)
>>>>
>>>> Thanks,
>>>> Brent
>>>>
>>>>
>>>>
Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
Posted by Sean Mullan <se...@oracle.com>.
Yeah, I get it, I need to chat with some folks here first that worked on
this before I can give you a better response.
--Sean
On 8/4/23 2:55 PM, Brent Putman wrote:
> Hi Sean,
>
> I understood that was how to do the RSA PSS algorithm with explicit
> parameters, which in Java is done with a PSSParameterSpec. For XML
> Signature that corresponds with this RFC URI:
>
> http://www.w3.org/2007/05/xmldsig-more#rsa-pss
>
> I'm instead talking here about the ones that have implicit/defaulted
> parameters, where the MGF, salt length and trailer field are defaulted
> (and the digest method is carried as usual in the algorithm ID). Such
> as this one:
>
> http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1
>
> So it's not my understanding that in Java one passes PSSParameterSpec
> with those, such as "SHA256withRSAandMGF1". All params are defaulted
> with those - that's the whole purpose of those variants. (And it would
> be problematic I think to pass the param spec with those, because you
> could specify in the params say SHA-512 as the digest method, which
> could be inconsistent with the JCA algorithm ID, as the one above.)
>
> But most importantly, I'm not doing any of this. It's Santuario that
> specifies how the actual Java cryptography works, and for those URIs it
> uses the Java algorithm ID variants in question, not "RSASSA-PSS". When
> I attempt the #sha256-rsa-MGF1 URI, it throws under Java 17 with
> NoSuchAlgorithm. I am merely observing from additional testing that
> those algorithm IDs are in fact documented in Java 17 for SunRsaSign,
> but yet do not actually work.
>
> The code in Santuario's JCEMapper and SignatureBaseRSA agrees with this
> understanding. Running with BC loaded works fine also, so they have the
> same understanding.
>
> Thanks
> Brent
>
>
> On 8/4/23 2:13 PM, Sean Mullan wrote:
>> Hi Brent,
>>
>> You need to pass the MGF and other parameters in a PSSParameterSpec to
>> the Signature algorithm, like so:
>>
>> Signature sig = Signature.getInstance("RSASSA-PSS", "SunRsaSign")
>> sig.setParameter(new PSSParameterSpec("SHA-256", "MGF1",
>> MGF1ParameterSpec.SHA256, 32, PSSParameterSpec.TRAILER_FIELD_BC));
>>
>> I think the JDK docs could be improved to clarify this, so I'll file a
>> bug to have this fixed.
>>
>> --Sean
>>
>> On 8/4/23 12:27 AM, Brent Putman wrote:
>>> This is not a Santuario issue per se, but it's sort of related and
>>> there are people on the list like Colm and Sean who might have info...
>>>
>>> In OpenSAML was working on adding support for the RSASSA-PSS
>>> algorithms (only those with implicit params) from RFC 9231:
>>>
>>> https://shibboleth.atlassian.net/browse/OSJ-372
>>>
>>> The TL/DR is: The docs for the SunRsaSign provider in at least Java
>>> 17 claim to support algorithm IDs like "SHA256withRSAandMGF1". But in
>>> practice they all throw NoSuchAlgorithmException.
>>>
>>> Iterating the providers in the JDK and the algorithm IDs supported
>>> confirms that they are not listed.
>>>
>>> Those are the algorithm IDs expected by Santuario in JCEMapper for
>>> the corresponding URIs from RFC 9231, such as
>>> http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1.
>>>
>>> This seems like a huge discrepancy between the JDK docs and the JDK
>>> behavior. Anyone know anything? Unless I'm missing something, seems
>>> like a possible bug in the JDK, at least with respect to the docs.
>>>
>>> (Such algorithm IDs are supported and do work when using Bouncy
>>> Castle as a security provider.)
>>>
>>> Thanks,
>>> Brent
>>>
>>>
>>>
Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
Posted by Brent Putman <pu...@georgetown.edu>.
Hi Sean,
I understood that was how to do the RSA PSS algorithm with explicit
parameters, which in Java is done with a PSSParameterSpec. For XML
Signature that corresponds with this RFC URI:
http://www.w3.org/2007/05/xmldsig-more#rsa-pss
I'm instead talking here about the ones that have implicit/defaulted
parameters, where the MGF, salt length and trailer field are defaulted
(and the digest method is carried as usual in the algorithm ID). Such
as this one:
http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1
So it's not my understanding that in Java one passes PSSParameterSpec
with those, such as "SHA256withRSAandMGF1". All params are defaulted
with those - that's the whole purpose of those variants. (And it would
be problematic I think to pass the param spec with those, because you
could specify in the params say SHA-512 as the digest method, which
could be inconsistent with the JCA algorithm ID, as the one above.)
But most importantly, I'm not doing any of this. It's Santuario that
specifies how the actual Java cryptography works, and for those URIs it
uses the Java algorithm ID variants in question, not "RSASSA-PSS". When
I attempt the #sha256-rsa-MGF1 URI, it throws under Java 17 with
NoSuchAlgorithm. I am merely observing from additional testing that
those algorithm IDs are in fact documented in Java 17 for SunRsaSign,
but yet do not actually work.
The code in Santuario's JCEMapper and SignatureBaseRSA agrees with this
understanding. Running with BC loaded works fine also, so they have
the same understanding.
Thanks
Brent
On 8/4/23 2:13 PM, Sean Mullan wrote:
> Hi Brent,
>
> You need to pass the MGF and other parameters in a PSSParameterSpec
> to the Signature algorithm, like so:
>
> Signature sig = Signature.getInstance("RSASSA-PSS", "SunRsaSign")
> sig.setParameter(new PSSParameterSpec("SHA-256", "MGF1",
> MGF1ParameterSpec.SHA256, 32, PSSParameterSpec.TRAILER_FIELD_BC));
>
> I think the JDK docs could be improved to clarify this, so I'll file
> a bug to have this fixed.
>
> --Sean
>
> On 8/4/23 12:27 AM, Brent Putman wrote:
>> This is not a Santuario issue per se, but it's sort of related and
>> there are people on the list like Colm and Sean who might have info...
>>
>> In OpenSAML was working on adding support for the RSASSA-PSS
>> algorithms (only those with implicit params) from RFC 9231:
>>
>> https://shibboleth.atlassian.net/browse/OSJ-372
>>
>> The TL/DR is: The docs for the SunRsaSign provider in at least Java
>> 17 claim to support algorithm IDs like "SHA256withRSAandMGF1". But
>> in practice they all throw NoSuchAlgorithmException.
>>
>> Iterating the providers in the JDK and the algorithm IDs supported
>> confirms that they are not listed.
>>
>> Those are the algorithm IDs expected by Santuario in JCEMapper for
>> the corresponding URIs from RFC 9231, such as
>> http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1.
>>
>> This seems like a huge discrepancy between the JDK docs and the JDK
>> behavior. Anyone know anything? Unless I'm missing something,
>> seems like a possible bug in the JDK, at least with respect to the
>> docs.
>>
>> (Such algorithm IDs are supported and do work when using Bouncy
>> Castle as a security provider.)
>>
>> Thanks,
>> Brent
>>
>>
>>
Re: Issue with support of RSASSA-PSS algorithms with implicit params in Oracle Java 17
Posted by Sean Mullan <se...@oracle.com>.
Hi Brent,
You need to pass the MGF and other parameters in a PSSParameterSpec to
the Signature algorithm, like so:
Signature sig = Signature.getInstance("RSASSA-PSS", "SunRsaSign")
sig.setParameter(new PSSParameterSpec("SHA-256", "MGF1",
MGF1ParameterSpec.SHA256, 32, PSSParameterSpec.TRAILER_FIELD_BC));
I think the JDK docs could be improved to clarify this, so I'll file a
bug to have this fixed.
--Sean
On 8/4/23 12:27 AM, Brent Putman wrote:
> This is not a Santuario issue per se, but it's sort of related and there
> are people on the list like Colm and Sean who might have info...
>
> In OpenSAML was working on adding support for the RSASSA-PSS algorithms
> (only those with implicit params) from RFC 9231:
>
> https://shibboleth.atlassian.net/browse/OSJ-372
>
> The TL/DR is: The docs for the SunRsaSign provider in at least Java 17
> claim to support algorithm IDs like "SHA256withRSAandMGF1". But in
> practice they all throw NoSuchAlgorithmException.
>
> Iterating the providers in the JDK and the algorithm IDs supported
> confirms that they are not listed.
>
> Those are the algorithm IDs expected by Santuario in JCEMapper for the
> corresponding URIs from RFC 9231, such as
> http://www.w3.org/2007/05/xmldsig-more#sha256-rsa-MGF1.
>
> This seems like a huge discrepancy between the JDK docs and the JDK
> behavior. Anyone know anything? Unless I'm missing something, seems
> like a possible bug in the JDK, at least with respect to the docs.
>
> (Such algorithm IDs are supported and do work when using Bouncy Castle
> as a security provider.)
>
> Thanks,
> Brent
>
>
>