0

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."

Yeldar Kurmangaliyev
  • 265
  • 1
    Linearize them before signature so you optimize for the smallest possible payload? – Luc Franken Jun 14 '16 at 08:39
  • @LucFranken I am sorry for confusing you. After some tests, we learned that the problem occurs after linearization of signature. Please, read the updated question. – Yeldar Kurmangaliyev Jun 14 '16 at 08:45
  • Much better question now. I am not sure but I found this example: https://www.npmjs.com/package/xml-dsig where I see that (compared to your example) there is only one root element: docs in their case, which corresponds to your root tag. So the signature is part of their root tag. Are your sure your dll produces the right output? I just found this example but it seems they are different that's why letting you know. I think your library should also take care of the serialization, those things are strongly connected. – Luc Franken Jun 14 '16 at 09:50
  • @LucFranken You were right - I made a mistake in my question. Actually, Signature tag is located in the end of root document. I have updated the question. The problem is still actual. – Yeldar Kurmangaliyev Jun 14 '16 at 11:08

1 Answers1

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).

kdgregory
  • 5,250
  • 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 Jun 14 '16 at 19:24