[Fwd: Re: [xmlsec] Problem with ver 0.0.11]
matthias.jung at xtradyne.com
Wed Dec 4 10:12:24 PST 2002
I think I got your point. I will have a look in the spec later this evening.
I have tried your example using the expression
Unfortunately the digest value of this reference looks like an empty node set was passed to the digest algorithem.
(digest value: "2jmj7l5rSw0yVb/vlWAYkK/YBwk=" , typical sha1 digest of an empty input)
Validation of this signature does not fail because it does not sign any referenced data.
The xml document I used to test this expession has the same structure
than the one I have sent in the last mail.
Another xpointer expression failing in the new version (but did not in the old) is
To me it looks like a valid xpointer expression. Signing a SOAP envelope using this expession causes the same error than described in the last email.
(..\src\transforms.c:1181): error 4: xml operation failed : xmlXPtrEval(xmlns(soap-env=http://schemas.xmlsoap.org/soap/envelop...
Am I just to stupid to think out valid signature templates or is there really something wrong???
What do you think? (Oh, please don't say I am stupid ;-) )
Aleksey Sanin wrote:
> I believe you have a different issue. In you case there is a problem
> According to the spec  you have two possible options for the URI
> - use '#id' syntax where 'id' is an ID attribute of an element;
> - use '#xpointer(expr)' syntax where 'expr' is any valid xpointer
> As far as I can understand the spec you are *not* allowed to use xpointer
> expressions in the '#id' syntax (there is a really simple reason for
> this: if this is
> allowed then XPointer could not decide what does '#1234' mean - is it a
> number or an ID attribute).
> The change in xmlsec library behavior was caused by the fix I put in
>  and I believe
> that the current way of processing Reference URI attribute is correct.
> You can
> get the same results as before by slightly changing your signature to:
> And explicitly adding C14N transform to exclude comments (if you wish
> to do so) because
> '#xpointer()' syntax *includes* all selected comments and '#id' does
> not (see  for details).
> I am sorry for inconvenience caused by this bug fix but I want to make
> xmlsec library
> as more standard complaint as I can.
> With best regards,
>  http://www.w3.org/TR/xmldsig-core/#sec-URI
>  http://www.aleksey.com/pipermail/xmlsec/2002/000368.html
> Matthias Jung wrote:
>> Sorry, I can't agree to this.
>> Signatures, passing validation using the command line tool of xmlsec
>> 0.0.10, will fail when they are verified with version 0.0.11
>> I receive following error message:
>> F:\dev\dbc\Tests\XML\DSig>xmlsec verify --trusted CACert.pem
>> (..\src\transforms.c:1181): error 4: xml operation failed :
>> (..\src\transforms.c:881): error 2: xmlsec operation failed :
>> (..\src\xmldsig.c:1602): error 2: xmlsec operation failed :
>> (..\src\xmldsig.c:1476): error 2: xmlsec operation failed :
>> xmlSecReferenceRead - -1
>> (..\src\xmldsig.c:1175): error 2: xmlsec operation failed :
>> xmlSecSignedInfoRead - -1
>> (..\src\xmldsig.c:733): error 2: xmlsec operation failed :
>> xmlSecSignatureRead - -1
>> Verification of all of my tests using xpointer expressions in xmlsec
>> 0.0.11 fail, something seems to be wrong with xpointer evaluation
>> (strange because this is done by libxml).
>> I am quite sure that compiler flags are exactly the same than in the
>> old version. This should not be the problem.
>> I have attached to this mail a signed xml-file from my testsuite and
>> the certificate file needed to verify the signature (hope they will
>> be posted too).
>> To see if this is an xmlsec problem or not, please check if the
>> signature is valid on your (Windows) xmlsec environment.
>> Cheers Matthias
More information about the xmlsec