RH1940064: Enable XML Signature provider in FIPS mode

[franferrax]

Search this PR in Red Hat Jira

RH1940064: Enable XML Signature provider in FIPS mode

A pull request for RH2156945: Enable XML Signature provider in FIPS mode [rhel-8, openjdk-17]. This work depends on the lock-down of disallowed algorithms from non-FIPS providers (765baf2, 6e74f28, #1, #5, #16, #19).

In order to enable the XMLDSig security provider, we must add the following line to java.security:

fips.provider.7=XMLDSig

Notes

I have been reviewing org.jcp.xml.dsig.internal.dom.XMLDSigRI, the implementation of the XMLDSig provider, and it seems to use JCA generic APIs, allowing us to provide all the cryptographic operations through SunPKCS11 (the only provider allowed for such operations when in FIPS-mode, for compliance reasons).

The following DOMSignContext / DOMValidateContext properties accept a Provider instance to use cryptographic operations from it:

• org.jcp.xml.dsig.internal.dom.MacProvider
• org.jcp.xml.dsig.internal.dom.SignatureProvider

Although these properties seem to be unknown / undocumented, there is a usage sample in Apache Santuario tests, in src/test/java/javax/xml/crypto/test/dsig/XMLSignatureTest.java:194-229.

However, we don't need to remove these properties, since a user that tries to pass them while in FIPS-mode, is in one of the following scenarios:

• They pass a SunPKCS11 Provider instance (this is fine)
• They pass a SunJCE Provider instance (SunJCE has the lock-down in place, so any cryptographic operation is removed, and the user will face an error at some point)
• They add another custom provider to the FIPS configuration in java.security, and pass an instance of that Provider (this is unsupported, and we can't assert their configuration is FIPS compliant, regardless of the DOMSignContext / DOMValidateContext properties usage)

After editing java.security to enable the XMLDSig provider, I executed the XMLDSigWithSecMgr test in a RHEL VM configured in FIPS-mode. Then I confirmed through debugging that SunPKCS11 is being used for digest, sign and verify operations.

Finally, I also checked for direct instantiation of provider classes, such as that which caused #16, in sun.security.pkcs11.P11Util.getSunJceProvider(). I was unable to spot any direct usage of SunJCE, which would cause errors due to removed algorithms in FIPS.

[gnu-andrew]

Any idea why the actions haven't run? Are they enabled on your fork?

[franferrax]

Any idea why the actions haven't run? Are they enabled on your fork?

I don't know what is happening with the PR run, the actions seem to have run in my fork's version of the commit: franferrax/jdk@b68e966 (in run 3802858214).

[gnu-andrew]

Strange. The test results look good so I can't see any issue with this going in.