XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by Guangxi W » Sat, 31 Jan 2004 08:55:04


I am currently working with a business partner on a B2B application using
SOAP and XML Signature, and have encountered a seemingly interoperability
issue. I am using SignedXML from .NET Framework 1.1 and WSE 1.0SP1. The
partner uses DataPower's XS40 XML Security Gateway. We exchanged
certificates in advance.

Here is what we know so far:

1. The partner can verify the signatures created by the SignedXML class from
WSE 1.0SP1.
2. The partner can verify the singatures created by the XS40 XML Security
Gateway (of courcse).
3. We can verify the signatures created by both WSE 1.0SP1 and .NET
Framework 1.1 using WSE 1.0SP1.
4. We CANNOT verify the signatures created by the XS40 XML Security Gateway.

The SignedInfo element of the signed SOAP messages from the partner is
nicely formatted and includes non-significant white spaces such as CRLF and
tabs. I set PreserveWhitespace to True before loading the SOAP message. The
SOAP message's declaration indicates it is using UTF-8 encoding, but I am
not sure if the SOAP message is actually UTF-8 encoded.

Has anyone encountered similar issues when verifying signatures generated in
Java in general, and by XS40 XML Security Gateway in particular? Can you
share your experience, good or bad?

Can anyone provide pointers to where I can find information to resolve the
issue?

Thanks a million in advance.

--- Guangxi
 
 
 

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by Michel Gal » Sat, 31 Jan 2004 10:15:08

Two possibilities ... was the signature generated based on UNICODE-hashed
data?
Also order of signature bytes (big versus little endian) might be an issue.

ASN parsing of signatures often reveals the problem .. some technologies add
authenticated attributes in the signature blobs that might cause other less-robust
implementations to have problems with .. just a few ideas ..

- Mitch Gallant

 
 
 

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by Guangxi W » Sat, 31 Jan 2004 10:57:24

hanks Mitch for your post.

I am relatively new to the cryptography world, so I need a bit more
guidance. How can I determine if the signature was based on UNICODE-hashed
data? And how to determine if the signature bytes are big endian or little
endian? Is there any way to programmatically parse the signature using .NET
or WSE?

The digital signatures from the partner are supposedly to conform to the W3
Digital Signature specification (http://www.w3.org/2000/09/xmldsig#). Below
is the Signature element contained in the signed SOAP message. The KeyInfo
element is removed from the signature, and the signature value is reduced.
Notice that the SignedInfo element is contains CRLF and other
non-significant white spaces.

<Signature xmlns="http://www.w3.org/2000/09/xmldsig#"
xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/07/secext">
<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#Body">
<Transforms>
<Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>U6ix8wug6U8XlJ48SDokGP6Jzys=</DigestValue>
</Reference>
</SignedInfo>

<SignatureValue>ZPVrzaQrjpX7pzpmMiKdcTjYvoW+Axo+5MZUAyw...</SignatureValue><
/Signature>

Per W3 documentation, the signature value is calculated over the SignedInfo
element. .NET's SignedXML seems to perform the signature validation against
the SignedInfo element before performing the reference validation against
the signed content. The CheckSignature method of the WSE's SignedXML class
failed during the signature validation before going to the reference
validation.

Thanks,

--- Guangxi

"Michel Gallant" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
issue.
add
less-robust
news: XXXX@XXXXX.COM ...
using
interoperability
from
Security
Gateway.
and
The
am
generated in
the


 
 
 

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by Michel Gal » Sat, 31 Jan 2004 11:35:12

ot really up to date on XML (yet), but you can check the digest against the content
using a hash calculator. I designed a web-based MD5/SHA-1 hash calculator for
strings or any file, with UNICODE capability. It is intented for general debugging.
It requires IE5+ and IE must be configured to use MS JVM (migrating to a .NET smart-app soon):
http://pages.istar.ca/~neutron/messagedigest
Since the digest values in XMP are b64 encoded, you would need to convert from b64 first (I'm
adding b64 display option to the utility above soon).

Is the SignatureValue in XMP/Soap a standard PKCS#1 v1.5 sig (i.e. 128 bytes for a 1024 bit RSA
key?)
- Mitch Gallant


"Guangxi Wu" < XXXX@XXXXX.COM > wrote in message news: XXXX@XXXXX.COM ...


 
 
 

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by Jean-Marc » Sat, 31 Jan 2004 21:46:00


> Not really up to date on XML (yet) [...]

You need to read a bit more of the spec, Michel.

Dsig Compliant XML signatures *MUST* be generated from the UTF-8
representation of the data, even if the signed document uses another
encoding, so the cause should not be what you describe.
Both implementation involved have been tested well enough to be sure
they respect that, or that's a big failure of interoperability testing
suite.

But from the copy I have of the public interop test files, it seems they
all use 'encoding="UTF-8"', so they're far from completely testing that
aspect. :-(

Guangxi, in order to see where the problem comes from, it would be
better if you join a file generated by XS40 XMLas an attachment,
compressed inside a zip file, so that it's garanteed not to be modified
in transport.

You seem to be worried about the encoding.
But have you actually tested if your capacity of validating the file
depends on the fact they contain chinese characters ?
 
 
 

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by Michel Gal » Sun, 01 Feb 2004 02:55:04


That is certainly true :) i haven't worked through the detailed syntax in the XMLDsig standard,
but sometimes it is simply easier to trouble-shoot knowing where the content is, the associated
digest and the signature on the digest instead of relying too formally on what the spec states.
After all, these are fairly early days for XMLsigs so things certainly will take a while to shake
down.

- Mitch Gallant
MVP Security
 
 
 

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by Michel Gal » Wed, 04 Feb 2004 14:52:55


OK, I have read a bit more :), but not the entire formal spec yet!

Searching quickly via google there are similar questions (notwithstanding the formal spec)
to the following:
What data is actually represented by the <HashValue> tag pointing to a Reference ?
To be very specific, consider the sample here:
http://www.yqcomputer.com/

It simply adds one Reference to a local data string item:
<Reference URI="#MyObjectId"><DigestMethod Algorithm=" http://www.yqcomputer.com/ #sha1"
/><DigestValue>/Vvq6sXEVbtZC8GwNtLQnGOy/VI=</DigestValue></Reference>

referring to:
<Object Id="MyObjectId"><My Element xmlns="samples">This is some text</MyElement></Object>

Now the b64 string "/Vvq6sXEVbtZC8GwNtLQnGOy/VI=" when decoded agrees exactly with
reference.DigestValue for that Reference object. Fine.

However, what is the canonicalized string that is actually hashed to give that hash?
To see the actual C14 form, I also did this :
XmlDsigC14NTransform transformer = new XmlDsigC14NTransform();
transformer.LoadInput(doc); // load the XmlDocument to transform
Stream transformed = (Stream)transformer.GetOutput(typeof(Stream));
StreamReader str = new StreamReader(transformed) ;
and dumped the str to view it, but it looks exactly the same as the input XML string.

Anybody have any idea? Once I understand this, understanding the bigger data hash(between
<SignedInfo> tags) that is actually signed to formed SignedValue is not a problem.

Thanks,
- Mitch Gallant
 
 
 

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by Jean-Marc » Wed, 04 Feb 2004 23:25:21


I decided to trim down the groups in the cross-post.

I think the only one really relevant is
microsoft.public.dotnet.security
so that's the only one I keep in the followup.

About UTF-8, actually the dsig spec only has a "should" about
representing the data in UTF-8, it's C14 that really imposes it.

Dsig only says :
4.3.1
CanonicalizationMethod is a required element that specifies the
canonicalization algorithm applied to the SignedInfo element prior to
performing signature calculations. [...] Text based canonicalization
algorithms (such as CRLF and charset normalization) should be provided
with the UTF-8 octets that represent the well-formed SignedInfo element

6.5 Canonicalization Algorithms
[...] Various canonicalization algorithms require conversion to
[UTF-8].The two algorithms below understand at least [UTF-8] and
[UTF-16] as input encodings. We RECOMMEND that externally specified
algorithms do the same. Knowledge of other encodings is OPTIONAL.

>[...]

Then you need to read the C14 spec ... XML strings which respect some
criteria of cleanness in a simple document without namespace will not be
changed at all by C14.

C14 imposes UTF-8, the spec gives a sample that describes the result of
that:

http://www.yqcomputer.com/ :
3.6 UTF-8 Encoding
Input Document :
<?xml version="1.0" encoding="ISO-8859-1"?><doc>©</doc>
Canonical Form :
<doc>#xC2#xA9</doc>
Note: The content of the doc element is NOT the string #xC2#xA9 but
rather the two octets whose hexadecimal values are C2 and A9,

If the input document were chinese, all of it's chinese content would
likewise have to be converted to utf-8 before calculating the signature.

The other most signative aspects in C14 are the copy of the document
namespace definitions inside the subset you create, expansion of
entities (all &xxx;) and the "cleaning" of the tag and attributes, but
NOT of the value of the tag.
This mean:
<e1 />
<e2 ></e2>
<e3 name = "elem3" id="elem3" />
changes to :
<e1></e1>
<e2></e2>
<e3 id="elem3" name="elem3"></e3>
<e4 id="elem4" name="elem4"></e4>
but the "pretty print" space at start of line were *not* suppressed.

The examples in the doc are very explicit, probably more than reading
all the text.
 
 
 

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by rsal » Thu, 05 Feb 2004 01:11:54

Have you looked to see if WSE supports the style of signature being
used by your partner? I believe the toolkit you are using only
supports WS-Security, for example, and that is not what's being used
here.
/r$
 
 
 

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by rsal » Thu, 05 Feb 2004 01:14:32

> Notice that the SignedInfo element is contains CRLF and other

No, the whitespace is most definitely significant for the signature
and hashing. It is not significant at the "XML layer," but at the
signature level it matters a great deal. See, for example,
http://www.yqcomputer.com/
/r$
 
 
 

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by Guangxi W » Thu, 05 Feb 2004 01:59:54

y understanding is that .NET Framework 1.0 and 1.1 uses inclusive
canonicalization (http://www.w3.org/TR/2001/REC-xml-c14n-20010315), while
WSE 1.0sp1 uses exclusive canonicalization
(http://www.w3.org/2001/10/xml-exc-c14n#). It is very interesting that XS40
can verify the signatures generated using WSE 1.0sp1, but failed to verify
the signatures generated using .NET 1.1, although the signatures generated
by SX40 uses inclusive canonicalization.

It seems to me that the problem might be due to the different canonicalized
SignedInfo element in the two different tools (XS40 and .NET). The
verification code failed to verify the SignatureValue against the SignedInfo
element before verifying the Reference (the SOAP body content). Here is the
output from the SignedXML.SignedInfo.GetXML.OuterXML method (canonicalized
form?):

<SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315" />
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1" />
<Reference URI="#Body">
<Transforms>
<Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"
/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1" />
<DigestValue>U6ix8wug6U8XlJ48SDokGP6Jzys=</DigestValue>
</Reference>
</SignedInfo>

And here is the original SignedInfo element in the signed XML:

<SignedInfo>
<CanonicalizationMethod
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
<SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
<Reference URI="#Body">
<Transforms>
<Transform
Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"/>
</Transforms>
<DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
<DigestValue>U6ix8wug6U8XlJ48SDokGP6Jzys=</DigestValue>
</Reference>
</SignedInfo>

There are couple of differences in the above two SignedInfo elements: the
default namespace for xmldsig, and the extra whitespace before the closing
tags. However, the canonicalized elements do not have the begin/end element
tags in the form of <elem>...</elem> as shown in the examples in the C14
spec.

Thanks,

--- Guangxi

"Michel Gallant" < XXXX@XXXXX.COM > wrote in message
news: XXXX@XXXXX.COM ...
news: XXXX@XXXXX.COM ...
the W3
the formal spec)
Reference ?
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/
frlrfsystemsecuritycryptographyxmlsignedxmlclasstopic.asp
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"
text</MyElement></Object>
exactly with
that hash?
XML string.
data hash(between
problem.


 
 
 

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by Guangxi W » Thu, 05 Feb 2004 02:07:38

Hi Rich,

I am so glad to see you here. I was hoping that you might drop in and help
me figure out the problem I am facing.

I agree with you. The whitespaces are significant in signature verification.
I am just not sure whether they are treated the same in XS40 and .NET. Can
you shed some light on how the SignedInfo element is created in XS40? How
the XML elements (both the SignedInfo and the referenced XML elements) are
canonicalized? From the signed XMLs created by XS40, the SignedInfo element
is nicely formatted with line feeds and indentations. The SignedInfo element
created by .NET, on the other hand, do not contain any non-significant (in
terms of XML content) whitespaces.

Thanks,

--- Guangxi
 
 
 

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by Guangxi W » Thu, 05 Feb 2004 02:09:21

WSE 1.0sp1 does support XML Signature, in addition to WS-Security.
 
 
 

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by rsal » Thu, 05 Feb 2004 03:16:41

> Has anyone encountered similar issues when verifying signatures generated in

Java? What's Java got to do with the XS40? I can answer: nothing.

Microsoft WSE doesn't support standard XML canonicalization, only
exclusive. I wonder why they did that?
/r$
 
 
 

XML Digital Signature interoperability Issue between DataPower's XS40 and .NET Framework 1.1 and WSE 1.0SP1

Post by Guangxi W » Thu, 05 Feb 2004 03:34:28

Thanks for the information about Java and XS40, Rich.

You are right in saying that WSE uses exclusive canonicalization when
creating signatures, and XS40 can verify the signatures created by WSE.
However, WSE does seem to support signature verification using inclusive
canonicalization. One proof of that is WSE can verify signatures generated
by .NET 1.1, which uses inclusive canonicalization.

Thanks,

--- Guangxi



generated in