[xmlsec] digestvalue failure

Artur BUJDOSO artur.bujdoso at saveas.hu
Wed Mar 3 12:35:58 PST 2004


Thanks for the fast answer.

Yes, it seems that all of my troubles can be namespaces and 
canonicalization. I've C14N-ed just the body and I (obviously) got a 
quite diferent form of document. It still doesn't work, because of 
missing namespaces. Since I've stripped off the namespace definitions of 
SOAP-ENV and so on, it fails to canonize completely, even if it emits a 
document that seems to be canonized.

My other question: would be the solution for this issue is the 
xpath-selected C14N?

My other question....it seems quite simple to me, but it still isn't 
trivial: do I have to calculate a hash including the <Body> tags, (the 
one  mentioned in the Reference) or  just the content between the two tags?

 
The XMLSEC library would be nice to use (and end all of my troubles), 
but this environment has a Zorp-patched 0.9.6 libssl, and it's quite 
unsure what's in it (source not included), and it complains about 
missing features when compiling. I've also tried to install BOTH libssl 
(0.9.6zorp-1 and 0.9.7) but it produced the well-awaited effect: coredump.

What defines do I have to use, in order to use it under 0.9.6? I'll 
still give it a try, I don't want to reinvent the wheel.


Artur



Aleksey Sanin wrote:

>>I have to implement an XML digital signature checker, but unfortunately, 
>>without using the xmlsec library. This environment has a specially 
>>patched (and 0.9.6 only) libssl that renders xmlsec library unusable. 
>>    
>>
>
>I wonder, why? XMLSEC does support 0.9.6 (you need to set a correct define 
>if you don't use autotools) but some algorithms will be disabled because
>they don't exist in 0.9.6. Everything else should work. IMHO, it should be 
>much more simple to fix xmlsec to work with your patched 0.9.6 than write
>verification from scratch.
>
>
>  
>

>>Here's the problem: 
>>
>>I read the xml file, parse it with libxml2, then I try to canonize it with: 
>>
>>xmlC14NDocDumpMemory(xmlDoc, NULL, 1, NULL, doc_txt_ptr); 
>>
>>where xmlDoc is an xmlDocPtr, and doc_txt_ptr is an **xmlChar. 
>>
>>When I dump the canonized content, it seems ok, at least it's readable, 
>>has 0x0a at each line end, has no whitespace but 0x20, etc.... 
>>
>>At the next step, I look for the referenced URI in the document, in my 
>>case, it looks like this: <Reference URI="#Body">. It is a digitally 
>>signed XML SOAP content, so it refers to the section, starts with 
>>"<SOAP-ENV:Body". I check through the document, and cut the part 
>>_starting_ with <SOAP-ENV:Body and _ending_ with: </SOAP-ENV:Body>. The 
>>< is the first byte in my sha1 buffer and the last one is a > (of the 
>>both SOAP-ENV:Body tags). I generate an sha1 hash, then do a base64 
>>encoding. (I encode the bytes, not the UTF8 chars, of course) and it 
>>produces a DigestValue for me. 
>>    
>>
>
>Well, there is no surprise. The C14N for the part of a document *will not*
>be the same as a cut from C14N of the whole document. The problem is namespaces.
>For example, if you have something like this:
>
><Root xmlns="http://example.org/test">
><Data/>
></Root>
>
>then C14N for the whole document will be 
>
><Root xmlns="http://example.org/test">
><Data><Data/>
></Root>
>
>but C14N for the <Data> element only (say, selected with XPath) will be 
>
><Data xmlns="http://example.org/test"><Data/>
>
>Hope this explains the problem but you can find more details in the C14N spec.
>
>
>Aleksey
>  
>




More information about the xmlsec mailing list