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
_______________________________________________ xmlsec mailing list [EMAIL PROTECTED] http://www.aleksey.com/mailman/listinfo/xmlsec
