Any reason to not use the certificate algorithm for XMLSignature?

[michewl]

Hello,

while working on our project we changed the signing certificate to ECDSA. However this triggered an exception during sso:

libSAML2:03/25/2021 12:47:28:918 PM UTC: Thread[http-nio-8100-exec-2,5,main]: TransactionId[2aa5b630-3bee-4bfa-97ae-b5743b4a5314-6034]
ERROR: UtilProxySAMLAuthenticatorLookup.retrieveAuthenticationFromCache: Unable to do sso or federation.
com.sun.identity.saml2.common.SAML2Exception: java.security.ProviderException: Unsupported algorithm EC
	at com.sun.identity.saml2.xmlsig.FMSigProvider.sign(FMSigProvider.java:222)
[...]

Reduced stacktrace. Full stack trace see ec-stacktrace.log.

I have been looking at the code and found that the certificate algorithm is not considered which I found odd. Instead the implementation does the following:

• Use a configured value (com.sun.identity.saml.xmlsig.xmlSigAlgorithm)
  • It seems it will always be configured with http://www.w3.org/2000/09/xmldsig#rsa-sha1. I could not find yet where this comes from.
  • This initializes a RSA based instance which then throws the above exception
• Use either dsa-sha1 or rsa-sha1
  • The decision is made based on the PrivateKey, not the X509Certificate

Our solution to this would be to use X509Certificate#getSigAlgName() and map it to the required URI. The current implementation would remain as fallback should the mapping not find any URI.

Are there any concerns about evaluating the certificate as first source for the algorithm URI or are there any side effects we are currently not aware of?

We would appreciate your ideas and thoughts on this. Thank you.

---

UPDATE:
See here for the proposed implementation. Unfortunately we could not find a better way to map the URI to the algorithm name.