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 >>>> [email protected] >>>> >>>> >>> >>> >>> >> > > _______________________________________________ > xmlsec mailing list > [email protected] > http://www.aleksey.com/mailman/listinfo/xmlsec > _______________________________________________ xmlsec mailing list [email protected] http://www.aleksey.com/mailman/listinfo/xmlsec
