Digest calculation with Java endpoint

[carbonrobot]

I am connecting to a java endpoint that calculates the digest in a different way. I believe it has something to do with an option to sign the Timestamp element itself or the Timestamp content.

For the following xml fragment:

<wsu:Timestamp wsu:Id="TS-f3c103e9-1897-43d8-8cf6-274bdb647678">
  <wsu:Created>2016-02-24T15:32:12.693Z</wsu:Created>
  <wsu:Expires>2016-02-24T15:37:12.693Z</wsu:Expires>
</wsu:Timestamp>

Java produces the following transform:

<ds:Reference URI="#TS-f3c103e9-1897-43d8-8cf6-274bdb647678">
    <ds:Transforms>
       <ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#">
          <ec:InclusiveNamespaces xmlns:ec="http://www.w3.org/2001/10/xml-exc-c14n#" PrefixList="wsse soap"/>
       </ds:Transform>
   </ds:Transforms>
   <ds:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
   <ds:DigestValue>1rjXQQWVMM5KBWY8uswUynk6PCk=</ds:DigestValue>
</ds:Reference>

However, the same xml fragment produces a different digest value using xml-crypto. I am assuming it has something to do with canonicalization between node and java.

In java, there is an option to sign the "contents" or the "element". By default it signs the contents, although its difficult to tell what that really means.

Is there a known issue when interop between java/soap and other libs? Is there someway to solve the mismatch?

[yaronn]

Some things to try:

• remove all white space and sign in bot platforms (just to see if it is the cause)
• explicitly add the ws, soap namespaces on the Timestamp element OR tell java not to use the InclusiveNamespace canonicalization

If you are in position to use the Java signature API (and not only via SOAP calls) thank it might be easy to do more tests in the same fashion to understand what exactly is the blocking issue.

From what I've seen usually signature is for the full element and only in encryption it is common to have an option to encrypt the full element or only the content. So I don't think this is the issue.

[carbonrobot]

Thanks for the suggestions. On pure guesswork, I managed to produce the same digest value using the following:

Original

<wsu:Timestamp wsu:Id="TS-5e08c654-0c4a-49f9-ab36-a3371afbe50e">
   <wsu:Created>2016-02-25T14:39:42.631Z</wsu:Created>
   <wsu:Expires>2016-02-25T14:44:42.631Z</wsu:Expires>
</wsu:Timestamp>

Modified by hand to produce a matching digest to the java code

<wsu:Timestamp xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd" xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-utility-1.0.xsd" wsu:Id="TS-5e08c654-0c4a-49f9-ab36-a3371afbe50e">
   <wsu:Created>2016-02-25T14:39:42.631Z</wsu:Created>
   <wsu:Expires>2016-02-25T14:44:42.631Z</wsu:Expires>
</wsu:Timestamp>

Although I can modify the java client, I can't do anything about the receiving service, which used Java. No matter what SOAP we throw at it, it only works against a Java client (both .net and xml-crypto fail).

The Java libs for doing c14n are based on byte[]s, and it does the canonicalization against the bytestream while returning the digest value in situ, so its very difficult to just pull out the related code and build a nice little test harness.

The ultimate goal is getting the signature from xml-crypto to be accepted by the java endpoint we have.

[yaronn]

it seems you were able to modify the soap which xml-crypto works on to produce a digest which matches java, right? Can you explain why this cannot be used always?

[carbonrobot]

I was not able to, I just used a string version of the above as input.

[yaronn]

not sure I fully understand. you have a java web service which expects a
signed soap message. it only works with java clients, and rejects
singatures created by .net and javascript. is this correct? now you said
you were able to make xml-crypto create a signature which is identical to
the java one by adding those namespaces. does the server accepts this
message? why not always add these namespaces to you soap (you did not
mention which library you use for that). I know it sounds very specific
solution but sometimes it's a good option.

On Thu, Feb 25, 2016 at 9:19 PM, Charlie Brown notifications@github.com
wrote:

I was not able to, I just used a string version of the above as input.

—
Reply to this email directly or view it on GitHub
#92 (comment).

I'm on Twitter (@YaronNaveh http://twitter.com/#!/YaronNaveh)

[carbonrobot]

not sure I fully understand. you have a java web service which expects a
signed soap message. it only works with java clients, and rejects
singatures created by .net and javascript. is this correct?

Yes

now you said
you were able to make xml-crypto create a signature which is identical to
the java one by adding those namespaces

I was able to create the same digest token by running that xml string through an SHA1. It matches what the java client sends to the server. I am not able to send an exact replica of what the java client sends using any or all of node-soap/ws.js/xml-crypto

I started by using your ws.js library to send a signed message to the server. It was always rejected with the error: "Digest values do not match". I took a sample of the soap requests that get sent with our existing java soap client and compared them to what ws.js produces. Technically, it shouldnt matter that the xml is different, because they should both be using the same canonicalization rules before digest, and yet, I would still get an error.

So I have been trying to understand why the endpoint thinks the digest is invalid. The first step was figuring out how java was calculating its digest value.

[yaronn]

I think the main issue is that java uses InclusiveNamespaces which xml-crypto (and .net) do not. most servers do not care about it, seems the server you use is sensitive to this.

The way all xml signature libraries work is:

1. you have some xml:

<x xmlns="foo" xmlns:p="bar"><y>123</y></x>

1. you tell your library you want to sign <y>
2. your library produce a canonicalized version of it:

<y xmlns="foo">123</y></x>

1. that version is converted to bytes (utf8 encoding)
2. a digest is a hash function which is applied on this byte sequence
3. all digest are converted to base64 and put in a signeInfo xml structure
4. that structure is canonicalized and hashed similarly to the elements, and finally signed with the private key which is the SignatureValue

The InclusiveNamespace affect step 3. The value I wrote above applies to .net and xml-crypto but with InclusiveNamespace (which is a legitimate standard but not always supported) the xmlns:p="bar" would also be serialized into the canonicalized xml. So by adding these ambient namespaces into the root of nodes you want to sign you make the non-InclusiceNamespace implicitly behave like the InclusiveNamespace version. I think this should be fine, especially fi you sign an xml which is known to you and not going to change form all a sudden. You can also search about InclusiveNamespaces in this issue tracker as soem otehr approaches were to hard code the namespaces inside xml-crypto canonicalization algorithm.