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

Aleksey Sanin aleksey at aleksey.com
Wed Jul 18 20:30:17 PDT 2012


I haven't heard about any problems with Java :)

You can google for ".net c14n compatibility" to see results

Aleksey


On 7/18/12 7:39 PM, Tom Wood wrote:
> Aleksey,
>    Thanks so much for the quick answer. That certainly explains everything.
> Seems like a "dirty little secret".  Very disappointing.
> 
> Do you know of anywhere on the Web I can find more information
> documenting this known bug and Microsoft's decision to not fix it?
> Also, would you care to comment about Java based systems
> allowing for the same bug? I could well imagine that for
> interoperability Java developers might have implemented and propagated
> the same c14n bug.
> 
> Thanks again,
> Tom
> 
> 
> Aleksey Sanin wrote:
>> 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
>>>
>>>     
>>
>>
>>   
> 



More information about the xmlsec mailing list