[xmlsec] XML Sig verification failure due to Windows .NET c14n and libxml2 c14n difference

[Aleksey Sanin]

Well, since I wrote c14n code for libxml2 I can tell you that
this code is doing the right thing :) This is actually a known
bug that was discovered 10 years ago or so. .NET implementation
doesn't follow the spec but they refuse to change it since it
might break backward compatibility with old broken versions.

Anyway, I might suggest that you use c14n 1.1 spec if you can.
I believe it was implemented correctly in .NET.

Aleksey


On 7/18/12 6:50 PM, Tom Wood wrote:
> Aleksey,
>   I have been extensively using XML Signatures in a project over the
> past few months and have encountered what I believe is a significant
> cross platform
> problem. Fortunately, I have fully characterized the issue and can
> even resolve it (through a hack though, not pretty). But the reasons for
> the problem are troubling
> and I think you would be interested. I am hoping you can shed light on
> this issue or
> at least point me to someone who can.
> 
> Note that I have been working a lot with XMLSec and have compiled it from
> source code and have a good working knowledge of the package and
> interface and
> have even added some debugging source code along the way. The problem
> occurs with
> XML files signed in Windows .NET systems (as well as with at least one
> Java based
> system). 
> 
> -------------------------------
> I have diagnosed a problem wherein an XML signature produced on a Windows
> .NET system could not be verified using XMLSec (both on Linux and Windows).
> The reverse also occurs, where the same XML signed under XMLSec fails to
> verify on the Windows .NET system.  The actual issue lies with C14N, and
> thus
> technically, on the Linux side, involved libXML2, not XMLSec. But I
> think you will be
> interested. I appreciate your taking some time to read through this.
> 
> 
> The root of the problem is actually very simple and only occurs when
> the Signature CanonicalizationMethod is Inclusive C14N
> (http://www.w3.org/TR/2001/REC-xml-c14n-20010315).
> 
> 
> Here is the relevant part of an example <Signature> block.
> 
> <Signature:Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema"
> xmlns:Signature="http://www.w3.org/2000/09/xmldsig#">
> <SignedInfo>
> <CanonicalizationMethod
> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
> <SignatureMethod
> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/>
> <Reference URI="">
> <Transforms><Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></Transforms>
> <DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
> <DigestValue>PtRfa3EJKTr6yeeuokpGu4KvHnGPAcd1YqhZtts+qOs=</DigestValue>
> </Reference>
> </SignedInfo>
> ...
> ...
> 
> Under Windows .NET C14N transformation, the <SignedInfo> node is
> canonicalized to:
> 
> <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
> <CanonicalizationMethod
> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></CanonicalizationMethod>
> <SignatureMethod
> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></SignatureMethod>
> <Reference URI="">
> <Transforms><Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform></Transforms>
> <DigestMethod
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod>
> <DigestValue>PtRfa3EJKTr6yeeuokpGu4KvHnGPAcd1YqhZtts+qOs=</DigestValue>
> </Reference>
> </SignedInfo>
> 
> Under XMLSec (using libXML2 underneath) C14N, the <SignedInfo> node is
> canonicalized to:
> 
> <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#"
> xmlns:Signature="http://www.w3.org/2000/09/xmldsig#"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> <CanonicalizationMethod
> Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></CanonicalizationMethod>
> <SignatureMethod
> Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"></SignatureMethod>
> <Reference URI="">
> <Transforms><Transform
> Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"></Transform></Transforms>
> <DigestMethod
> Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"></DigestMethod>
> <DigestValue>PtRfa3EJKTr6yeeuokpGu4KvHnGPAcd1YqhZtts+qOs=</DigestValue>
> </Reference>
> </SignedInfo>
> 
> The difference between the xmlns attrs in <SignedInfo> of course ruins
> Signature portability across
> these systems.
> 
> It is interesting and useful to point out that if Exclusive C14N is
> used, both systems canonicalize to
> the same <SignedInfo>. It is simply set to <SignedInfo
> xmlns="http://www.w3.org/2000/09/xmldsig#"> and
> so no problem occurs with cross platform verification.
> 
> Note that a hacked XMLSec can verify a signature from the Windows system
> if in midstream it subsititutes the
> Exclusive C14N transform instead of using the requested Inclusive C14N
> (from the XML Signature). I know this
> because I hacked a copy of XMLSec to force use of Exclusive C14N and
> suddenly XML
> signatures from a Windows .NET system verified. So the problem is
> strictly caused by the
> difference in SignedInfo node Canonicalization.
> 
> Can you or anyone your know tell me which code/system is correctly
> appying the inclusive C14N algorithm,
> Windows .NET or libXML2? 
> From my careful reading of the W3C Canonical XML spec,
> I think the result should match the libXML2 result, wherein all
> namespace attributes from
> <Signature> should be propagated into <SignedInfo>, as in
> <SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#"
> xmlns:Signature="http://www.w3.org/2000/09/xmldsig#"
> xmlns:xsd="http://www.w3.org/2001/XMLSchema">
> This is what libXML2 code produces.
> 
> Have you or anyone you know encountered this issue?
> 
> It quite surprises me that I would be the first whom has encountered
> this problem. As I am sure you can appreciate, this is a serious issue
> as cross platform verification is required.
> 
> Thanks in advance,
> Tom Wood
> wood at xmission.com
>