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
