[xmlsec] Microsoft .NET compatibility

Jesse Pelton jsp at PKC.com
Tue May 6 11:08:15 PDT 2003

For what it's worth, I'm replacing code that signs and verifies using the
.net framework with code that uses XMLSec.  One of my early milestones was
finding that the two implementations interoperate, at least in my case.
(That is, both produce signatures that either one can verify, and both would
fail to verify signatures if appropriate.)

That was some time ago (XMLSec 0.0.11, I think), and I haven't had any
problems since (I'm currently at 1.0.0).  I didn't run into any problems, so
I don't have any insight as to what might be going wrong, but I can report
that it's possible to get the two to play nicely, so it's worth following up
on Aleksey's suggestions.  (Personally, I'd look into .net support for
ExcC14N first, if that's what you're specifying.)

-----Original Message-----
From: Aleksey Sanin [mailto:aleksey at aleksey.com]
Sent: Tuesday, May 06, 2003 1:53 PM
To: Rob Cronin
Cc: xmlsec at aleksey.com
Subject: Re: [xmlsec] Microsoft .NET compatibility

Hi, Rob!

Not sure I have a defenite answer for you: I don't have Microsoft .NET 
around and
I could not try to sign something with it. The only thing I can do is to 
give you some
hints. If you are willing to try some options, read on :)

Since the digest values do match but signature verification fails there 
are only
two possible cases:
    1) the c14n for <dsig:SignedInfo/> element produced different results;
    2) the signature is calculated or stored differently
So lets try to investigate one after another.

1) C14N problems.

The <dsig:SignedInfo/> in your case is very simple and it's easy to 
verify that
xmlsec does the right thing (note the two very usefull options 
'--print-debug' and

 > xmlsec1 verify  --print-debug --store-signatures --dtd-file dtd2.dtd 
--trusted cacert.pem dsigtmp1.xml
== PreSigned data - start buffer:
<SignedInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
          <Reference URI="#Id-3ec382bd-2a43-4978-b70c-c3431f96fe35">
== PreSigned data - end buffer

"Presigned data" are collected and stored in the xmlsec memory buffer 
just before data go to
signature crypto library. From this output I don't see any problems on 
xmlsec side. It would be easy
if similar data could be collected from microsoft (I have no idea is it 
possible or not) and results
could be compared. But again, I just don't see any problems with the 
xmlsec output.

Also I noted that you use ExcC14N which is newer than C14N. I am not 
sure that Microsoft
implemented this spec (at least, they are not mentioned on interop page
http://www.w3.org/Signature/2002/02/01-exc-c14n-interop ). I can imagine 
that they silently
use C14N instead (and of course signature verification fails :) ). I 
would suggest to try
to sign/verify the same document with C14N as 

2) Signature.

If canonicalization is fine then it is possible that there is a 
signature problem. I would rate
a possibility of problems in signature as "unlikely". But it's software 
and everything
is possible. I have no idea how to debug it on xmlsec side. The only 
thing I can suggest is to
try another signature algorithm or hmac. Or may be try some other 
xmldsig toolkit and
see if it can verify this signature or not.


Rob Cronin wrote:

> Hello Aleksey,
> I have an interesting issue that I hope you could help me out with.  I 
> can get Microsoft's tool to sign something and verify it, but I can't 
> get the xmlsec tool to verify a Microsoft tool's signed document.  
> I've narrowed down the problem to different signatures generated by 
> Microsoft and the xmlsec tool.  I have a key, a certificate, and a 
> trusted root certificate.  I call xmlsec as follows:

xmlsec mailing list
xmlsec at aleksey.com

More information about the xmlsec mailing list