XML signature still fails to verify

[componentspace]

Description

An XML signature in a SAML response fails to verify using System.Security.Cryptography.Xml.SignedXml.

I believe the XML signature should verify as it does when using a Java application.

The attached ZIP includes:

samlresponse-fails.xml - signed XML that fails to verify samlresponse-verifies.xml - signed XML that does verify, for comparison

Program.cs - .NET console application demonstrating the problem VerifySignature.java - Java application that can successfully verify the signatures for both files

The samlresponse-fails.xml includes a SAML response that's signed and a SAML assertion that's also signed. It's the SAML response signature that fails to verify in the .NET console application but does verify in the Java application.

The samlresponse-verifies.xml includes a SAML response that's signed and this verifies in both the .NET console application and the Java application.

The .NET console application was built using .NET 8.0 and System.Security.Cryptography.Xml v8.0.0.

This is exactly the same issue reported in #31117 back in 2019. That issue was incorrectly identified as a duplicate of a different issue.

I believe the issue is related to the use of carriage return entity references in the XML.

For example:





Open the XML files included in the attached ZIP using Notepad etc to see the entity references.

xml-signature-issue.zip

Reproduction Steps

Build and run the Program.cs in the ZIP using .NET 8 and System.Security.Cryptography.Xml v8.0.0.

Expected behavior

The SAML response XML signature in samlresponse-fails.xml should verify.

Actual behavior

The SAML response XML signature in samlresponse-fails.xml fails to verify. The same signature verifies using Java.

Regression?

No

Known Workarounds

None

Configuration

.NET SDK: Version: 8.0.202 Commit: 25674bb2f4 Workload version: 8.0.200-manifests.8cf8de6d

Runtime Environment: OS Name: Windows OS Version: 10.0.22631 OS Platform: Windows RID: win-x64 Base Path: C:\Program Files\dotnet\sdk\8.0.202\

Other information

I suspect the canonicalization of XML that includes carriage return entity references isn't handled properly.

[dotnet-policy-service[bot]]

Tagging subscribers to this area: @dotnet/area-system-security, @bartonjs, @vcsjones See info in area-owners.md if you want to be subscribed.

[artur-reaboi]

It is important to note that standard eIDAS Node implementation (which is in Java), inserts those encoded characters in base64 encoded digests and certificates. This results in us being unable to validate SAML messages signed by widely used eIDAS Nodes.

[mpbraithwaite]

Would love to see this addressed. We have had to support customers that have had \r\n characters in their ADFS field values and using SAML authentication.

[AlexCozlovschi]

This would be very helpful, we have are receiving messages from different users, and they are all have their own implementation on Java, PHP, Python, we are using C# .Net Core for confirmations and management, but this problem makes our work much harder, my colleagues are asking to switch our stack to JAVA, because it has better compatibility. I still insist on keeping C#, and this modification could be the main argument.

[peterilis]

We would love a fix here as well, it is affecting customers setting up SAML integrations against us.

[VikingRedleg]

I also would appreciate a fix to this issue.

[neilpendlington]

Massively frustrating issue that caused an expensive amount of investigation in our organisation. For us, the problem surfaced whilst using .NET framework 4.8 proving that the issue is long-standing in the .NET ecosystem. Or potentially if the issue lies in the Windows Cryptography subsystem, it's even more important there's a fix made available.