[Fwd: Re: [xmlsec] Problem with ver 0.0.11]

[Matthias Jung]

Aleksey,

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

 <ds:Reference URI="#xmlns(soap-env=http://schemas.xmlsoap.org/soap/envelope/)xpointer(/soap-env:Envelope/soap-env:Body)">
    

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 ;-) )

Matthias



Aleksey Sanin wrote:

> Matthias,
>
> I believe you have a different issue. In you case there is a problem 
> here:
>    
>         ....
>    
> According to the spec [1] you have two possible options for the URI 
> attribute:
>    - use '#id' syntax where 'id' is an ID attribute of an element;
>    - use '#xpointer(expr)' syntax where 'expr' is any valid xpointer 
> expression.
> 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 
> [2] 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 [1] 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,
> Aleksey
>
> [1] http://www.w3.org/TR/xmldsig-core/#sec-URI
> [2] 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 
>> sig_xpointer_child_sequence_xmlsec.xml
>> (..\src\transforms.c:1181): error 4: xml operation failed : 
>> xmlXPtrEval(/1/2)
>> (..\src\transforms.c:881): error 2: xmlsec operation failed : 
>> xmlSecTransformStateParseUri(#/1/2
>> (..\src\xmldsig.c:1602): error 2: xmlsec operation failed : 
>> xmlSecTransformStateCreate
>> (..\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
>> ERROR
>>
>> 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
>>
>
>
>