I have an XML document like this:
<?xml version="1.0" encoding="utf-8"?><root><a>1</a></root>
I sign this document using a DLL-library, provided by crypto provider, and get a document like this:
<?xml version="1.0" encoding="utf-8"?><root><a>1</a>
<ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
<ds:SignedInfo>
<ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha1"/>
<ds:Reference>
<ds:Transforms>
<ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/>
<ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/>
</ds:Transforms>
<ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha1"/>
<ds:DigestValue>...</ds:DigestValue>
</ds:Reference>
</ds:SignedInfo>
<ds:SignatureValue>...</ds:SignatureValue>
<ds:KeyInfo>
<ds:X509Data>
<ds:X509Certificate>...</ds:X509Certificate>
</ds:X509Data>
</ds:KeyInfo>
</ds:Signature>
</root>
After that, I linearize this signature:
<?xml version="1.0" encoding="utf-8"?><root><a>1</a><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha1"/><ds:Reference><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#sha1"/><ds:DigestValue>...</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>...</ds:SignatureValue><ds:KeyInfo><ds:X509Data><ds:X509Certificate>...</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature></root>
Should the third document be valid?
I have an argue with a service provider which declines to verify my documents if I linearize them after signature. However, afaik, all algorithms should canonicalize XML before signing, hashing or verifying, so that logically equivalent documents result in the same hash / signature.
At the same time, their developer tells me that its true, but structural whitespaces are not removed during c14n, i.e. out-of-tags whitespaces are retained and included into hash calculations.
Who is right?
The main problem is that I am using IBM WebSphere Integration Bus which automatically linearizes any XML, and there is no way to disable this feature. IBM support tells "your code should never rely on XML structure; XML is about data, not text; it is not our problem, if your code is not working after linearization etc."
1 Answer 1
The service provider is correct, and the DLL that you use for signing the document is incorrectly inserting whitespace.
Here's the relevant part of the XML specification:
An XML processor must always pass all characters in a document that are not markup through to the application
The newlines inserted by the signing code are not considered markup: they exist between elements and therefore are considered part of the text (the XML spec calls this "mixed content").
If you can't change the behavior of the signing code, you will have to pass its output to the service without "re-linearizing".
For more information, read http://www.xml.com/axml/target.html#sec-white-space -- this is a copy of the XML 1.0 spec that has been annotated by Tim Bray, one of the original spec editors. He has two notes (1 and 2) that explain the decisions that the spec team made regarding "non-significant" whitespace (TL;DR: there's no such thing).
-
I ran into this kind of issue years ago when trying to get a WS-Security implementation going. The signature was generated and then the document was linearized prior to encryption. Man was that a PITA to debug. The solution was to linearize the doc first.JimmyJames– JimmyJames2016年06月14日 19:24:33 +00:00Commented Jun 14, 2016 at 19:24
Signature
tag is located in the end of root document. I have updated the question. The problem is still actual.