RFR 8222805: sun/security/pkcs11/tls/tls12/TestTLS12.java fails with Unsupported signature algorithm: rsa_pss_rsae_sha256

[Sean Mullan]

On 4/24/19 10:38 AM, Martin Balao wrote:
> Hi Sean,
> 
> On 4/24/19 7:12 AM, Sean Mullan wrote:
>>
>> I am still concerned about the odd workaround for this issue. Can you
>> comment on my previous comment that I raised?:
>>
>> On 4/23/19 4:33 PM, Sean Mullan wrote:> However, I think there may be a
>> more subtle bug or configuration issue
>>> underlying this. It seems like this could come up in real scenarios. You
>>> should never disable a strong algorithm, even if it is unsupported, in
>>> order to establish a TLS session. It should be able to negotiate a
>>> session using a different algorithm.
>>>
> 
> The reason why we disable the algorithm in the test is related to [1].
> What happens is that we need to have SunPKCS11, SUN and JSSE crypto
> providers enabled for a successful TLS communication in FIPS mode. The
> reason we need SUN -which looks as the odd one out there- are X.509
> certificates. However, having SUN enabled (after JSSE experimental FIPS
> changes) means that we support "RSAPSS" for the TLS communication. When
> this algorithm is applied by SUN provider to a SunPKCS11-sensitive key
> (keys are sensitive in FIPS mode and cannot be converted), it fails. As
> I said in [1], we need a good solution beyond the workaround of
> disabling concrete algorithms. I'd be happy to update the test when this
> is fixed.

Ok, thanks for that link. We need to file another bug to track the 
underlying issue then as I don't see anything filed. It seems quite 
likely that this could come up in a real scenario and telling a customer 
to disable RSA-PSS is just not right in my opinion.

Can you please file a bug for that and link it to this test bug? I'm ok 
with you pushing this test workaround fix for now since we need to get 
this resolved soon. I also agree with Xuelei that it would be helpful to 
add more comments in the test as to why the security property workaround 
is needed.

Thanks,
Sean

> 
> Kind regards,
> Martin.-
> 
> --
> [1] -
> https://mail.openjdk.java.net/pipermail/security-dev/2019-March/019469.html
>