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

Wed Jul 18 20:35:45 PDT 2012

For example, check this one

http://www.aleksey.com/pipermail/xmlsec/2008/008517.html

Aleksey


On 7/18/12 8:30 PM, Aleksey Sanin wrote:
> 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
>>>>
>>>>     
>>>
>>>
>>>   
>>
> 
> _______________________________________________
> xmlsec mailing list
> xmlsec at aleksey.com
> http://www.aleksey.com/mailman/listinfo/xmlsec
>