[xmlsec] XMLSEC Reference URI question
Aleksey Sanin
aleksey at aleksey.com
Wed Jul 24 18:22:28 PDT 2002
Hi, Moultrie!
I think that there is a "bug" in the document you provided and Apache
toolkit incorrectly implemented XPath transform. According to the XMLDSig
spec (http://www.w3.org/TR/xmldsig-core/#sec-XPath) the XPath transform
is evaluated as follows:
> In other words, the input node-set should be equivalent to the one
that would be created by
> the following process:
> 1. Initialize an XPath evaluation context by setting the initial
node equal to the input XML
> document's root node, and set the context position and size to 1.
> 2. Evaluate the XPath expression (//. | //@* | //namespace::*)
> The evaluation of this expression includes all of the document's
nodes (including comments) in the
> node-set representing the octet stream.
> The transform output is also an XPath node-set. The XPath
expression appearing in the XPath
> parameter is evaluated once for each node in the input node-set.
The result is converted to a
> boolean. If the boolean is true, then the node is included in the
output node-set. If the boolean is
> false, then the node is omitted from the output node-set.
In our case, the XPath expression in the XPath parameter is
"/ISSKeys/Contacts/Contact"
Evaluating this XPath expression returns a non-empty node set and
according to the
XPath spec (http://www.w3.org/TR/1999/REC-xpath-19991116#booleans) it is
converted
to boolean by a call to the boolean() function. From the same spec,
(http://www.w3.org/TR/1999/REC-xpath-19991116#function-boolean)
the boolean() function *always* returns true for non-empty node set:
> a node-set is true if and only if it is non-empty
For the document you sent me, this means that the XPath expression from
the XPath
parameter will be "true" for *all* nodes and *all* nodes should be
included in the output.
And this is exactly what XMLSec library returns!
I totally agree with you that such behavior is absolutely not intuitive
and can cause errors.
XMLDSig working group is now developing a new XPath transform spec
(XPath filter 2) and
this particular issue is fixed there. However, this new spec is not
stable right now and changes
almost every day so I could not recommend to use it in production yet.
Aleksey
Moultrie, Ferrell (ISSAtlanta) wrote:
>xmlsec verify --print-all --trusted new_export.pem test_allkey_04.xml
>
>I've included the PEM-formatted public key, the XML test document and the
>output captured from running the 07/12/02 build of xmlsec plus the one fix
>you sent me earlier. Let me know if you need anything else.
>Thanks!
> Ferrell
>
>-----Original Message-----
>From: Aleksey Sanin [mailto:aleksey at aleksey.com]
>Sent: Wednesday, July 24, 2002 5:48 PM
>To: Moultrie, Ferrell (ISSAtlanta)
>Cc: 'xmlsec at aleksey.com'; Dodd, Tim (ISS Atlanta)
>Subject: Re: [xmlsec] XMLSEC Reference URI question
>
>
>I am not sure I clear understand what kind of problem do you have. Will you
>mind to send me the file you have problems with?
>
>Thanks,
>
>Aleksey
>
>Moultrie, Ferrell (ISSAtlanta) wrote:
>
>
>
>>Aleksey:
>> Ok, I've tried to use an XPath Transform to limit the data being
>>verified. Unfortunately, it doesn't appear to work. Here's what I see
>>happening in the
>>code:
>>
>>xmlSecTransformXPathReadNode( ) [xpath.c:203] takes the input
>>xmlSecTransformPtr and upcasts it to a xmlSecXmlTransformPtr. It then
>>stores the parsed XPath string and the "here" node reference in the
>>xmlSecXmlTransform object it points to (at least there's checking of
>>the pointer assignment sanity here).
>>
>>The caller, xmlSecTransformRead, returns to its caller
>>xmlSecTransformNodeRead with the pointer to the object containing the
>>XPath transform information. The transform is further passed back to
>>xmlSecTransformsNodeRead which calls xmlSecTransformStateUpdate which
>>discovers that the transform type is xmlSecTransformTypeXml and call
>>xmlSecTransformCreateXml. This routine, because the file is already
>>parsed and both curFirstBinTransform and curC14NTransform in the state
>>object are NULL, does nothing and returns!
>>
>>This results in the XPath Transform information being parsed and saved
>>but otherwise ignored. The <Signature> block contains the following
>>transform which is parsed and ignored in the above case:
>>
>> <sig:Transform
>>Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
>> <sig:XPath>/ISSKeys/Contacts/Contact</sig:XPath>
>> </sig:Transform>
>>
>>The result is that adding an XPath transform like above, is ignored.
>>This works properly with the Apache Java tools so I believe that it's a
>>legal way to construct a reference. Eventually, I'd intended to change
>>the XPath reference to a here()-relative reference to solve my compound
>>document problem but this seemed like a quick/easy test --
>>unfortunately it's not working.
>>
>>Is this a bug, or, have I missed something else? Since Apache properly
>>verifies this signature and the code in xmlSecTransformCreateXml seems
>>to be missing any knowledge of this transform, I'm guessing that it's a
>>bug -- but I'll appreciate your advice on how to proceed!
>>
>>Thanks!
>> Ferrell
>>
>>=====================================
>>Ferrell Moultrie (ferrell at iss.net)
>>Software Engineer
>>
>>Internet Security Systems, Inc.
>>6303 Barfield Road
>>Atlanta, Georgia 30328
>>Phone: 404-236-2600
>>Direct: 404-236-2849
>>Fax: 404-236-2632
>>http://www.iss.net
>>
>>Internet Security Systems -- The Power to Protect
>>=====================================
>>_______________________________________________
>>xmlsec mailing list
>>xmlsec at aleksey.com http://www.aleksey.com/mailman/listinfo/xmlsec
>>
>>
>>
>>
>
>
>
>
>------------------------------------------------------------------------
>
>xmlSecSignedInfoRead: failed to validate "Reference"
>= XMLDSig Result (validate)
>== result: FAIL
>== sign method: http://www.w3.org/2000/09/xmldsig#rsa-sha1
>== KEY
>=== method: RSAKeyValue
>=== key name: NULL
>=== key type: Public
>=== key origin: x509
>=== X509 Certificate
>==== Subject Name: /C=US/O=Web Developer/OU=IT/CN=ISS Keygen Test
>==== Issuer Name: /C=US/O=Web Developer/OU=IT/CN=ISS Keygen Test
>==== Issuer Serial: 3CEF18C2
>== SIGNED INFO REFERENCES
>=== REFERENCE
>==== ref type: SignedInfo Reference
>==== result: FAIL
>==== digest method: http://www.w3.org/2000/09/xmldsig#sha1
>==== uri:
>==== type: NULL
>==== id: NULL
>==== start buffer:
><ISSKeys Source="ISS Atlanta">
>
> <Contacts>
> <Contact>
> <Keys Address1="2626 Somewhere Lane" Address2="suite 200A" City="Atlanta" Country="US" Email="keys at iss.net" Fax="778-555-1212" Phone="777.555.1212" PostCode="30064" Weburl="http://web.fubar.net"></Keys>
> <CustomerRelations Address1="1313 k nowwhere Lane" Address2="suite 300A" City="Atlanta" Country="US" Email="customer_relations at iss.net" Fax="778-555-7799" Phone="77 7.555.7788" PostCode="30064" Weburl="http://web.customer_relations_iss.net"></CustomerRelations>
> <Support Address1="1234 Anvil Rd." Address2="suite 440B" City="Atlanta" Country="US" Email="support at iss.net" Fax="778-555-7755" Phone="777.555.7744" PostCode="3 0064" Weburl="http://web.suport_iss.net"></Support>
> <Version>1.0</Version>
> <OCN>163444</OCN>
> <Source>ISS Atlanta</Source>
> <Serial>AC
>C64BB4-A53D-AC83-3E6F-E0AB737DEC9D</Serial>
> <Timestamp>2000-06-14 10:34:09</Timestamp>
> <sig:Signature xmlns:sig="http://www.w3.org/2000/09/xmldsig#">
> <sig:SignedInfo>
> <sig:CanonicalizationMethod Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315"></sig:CanonicalizationMethod>
> <sig:SignatureMethod Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"></sig:SignatureMethod>
> <sig:Reference URI="">
> <sig:Transforms>
> <sig:Transform Algorithm="http://www.w3.org/TR/1999/REC-xpath-19991116">
> <sig:XPath>/ISSKeys/Contacts/Contact</sig:XPath>
> </sig:Transform>
> <sig:Transform Algorithm="http://www.w3.org/TR/2001/REC-xml-c14n-20010315#WithComments"></sig:Transform>
> </sig:Transforms>
> <sig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></sig:DigestMethod>
> <sig:DigestValue>3tPX5xUmcKYHkG3Mv8TBAAYjBIU=</sig:DigestValue>
> </sig:Reference>
> </sig:SignedInfo>
> <sig:SignatureValue>GpbCX9juwQ6k4Hs5j19MSXdtAdxeY9cK06Hb17ugq7f6sIy71gafWWNJ1Na/TKGCrABlgrXWH2VR
>asYcPMEmi1RZKDPUzmPAjznKRozjZTS3nn2BrAl1EKLugiqYmer+IG8SOXXTDSiwbmphtsXK+emU
>FpUVVxfjLrmk8h6hd4k=</sig:SignatureValue>
> <sig:KeyInfo>
> <sig:X509Data>
> <sig:X509Certificate>
>MIICCjCCAXMCBDzvGMIwDQYJKoZIhvcNAQEEBQAwTDELMAkGA1UEBhMCVVMxFjAUBgNVBAoTDVdl
>YiBEZXZlbG9wZXIxCzAJBgNVBAsTAklUMRgwFgYDVQQDEw9JU1MgS2V5Z2VuIFRlc3QwHhcNMDIw
>NTI1MDQ1MzIyWhcNMjcwMTE0MDQ1MzIyWjBMMQswCQYDVQQGEwJVUzEWMBQGA1UEChMNV2ViIERl
>dmVsb3BlcjELMAkGA1UECxMCSVQxGDAWBgNVBAMTD0lTUyBLZXlnZW4gVGVzdDCBnzANBgkqhkiG
>9w0BAQEFAAOBjQAwgYkCgYEAy6ACsVtGJ69fkeKxJUlZqUP4FJFDIrkrUEi04c8UAAmC6jxu9+mM
>uLD+766Ztrjp/2anYX0QS7ReD+Q78ky3a0nmPDIpAzv8P7tUCBc6Yq11w5c1yHSNDdLPxLlX6+JT
>nUXnmXMsfAyC2cnoevc38gfEEkEJnS4iCzUC7WHsNgMCAwEAATANBgkqhkiG9w0BAQQFAAOBgQBy
>08EvqGY4QL5GYhuT5Lx26t7V0Tk9bKxzh9YKxtyTLux0sqDFcAQWu1UpjPSOLwgNhE+uaS+CuyIK
>wsSzMx84gOIk7/fOS5F7oRk2ouC0QPPhY0iT2wXi9Zhvd6CifjNwvCdDe0tinSeQNfvpo0FSlg8c
>GL2eqXYylPEeMvZ5aw==
></sig:X509Certificate>
> </sig:X509Data>
> <sig:KeyValue>
> <sig:RSAKeyValue>
> <sig:Modulus>
>y6ACsVtGJ69fkeKxJUlZqUP4FJFDIrkrUEi04c8UAAmC6jxu9+mMuLD+766Ztrjp/2anYX0QS7Re
>D+Q78ky3a0nmPDIpAzv8P7tUCBc6Yq11w5c1yHSNDdLPxLlX6+JTnUXnmXMsfAyC2cnoevc38gfE
>EkEJnS4iCzUC7WHsNgM=
></sig:Modulus>
> <sig:Exponent>AQAB</sig:Exponent>
> </sig:RSAKeyValue>
> </sig:KeyValue>
> </sig:KeyInfo>
> </sig:Signature>
> </Contact>
> </Contacts>
> <EndUsers>
> <EndUser Address1="666 Rockets way" Address2="Apt. B" City="Scienceville" CompanyName="Spacely Sprockets" Country="US" Email="gjetson at sprokets.net" PostCode="" State="Disturbed" SubjectName=FAIL
>"George Jetson" Title="Whipping Boy">
> <Version>1.0</Version>
> <OCN>163444</OCN>
> <Source>ISS Atlanta</Source>
> <Serial>CE8135D7-8D27-4BC4-BCA6-2DBDE703B6A
>E</Serial>
> <Timestamp>2000-06-14 10:34:09</Timestamp>
> </EndUser>
> </EndUsers>
> <LicensedModules>
> <LicensedModule ContactInfo="ACC64BB4- A53D-AC83-3E6F-E0AB737DEC9D" EndUserInfo="CE8135D7-8D27-4BC4-BCA6-2DBDE703B6AE" Identity="RO" LicenseExpiration="2003-06-14" LicenseType="evaluation" Limit="2147483647" LimitOutOfMaintenance="0" MaintenanceExpiration="2003-06-14">
> <Version>1.0</Version>
> <OCN>163444</OCN>
> <Source>ISS Atlanta</Source>
> <Serial>F61BD0F3-D5D9-2F90-A24D-BF989200D712</Serial>
> <Timestamp>2000-06-14 10:34:09</Timestamp>
> </LicensedModule>
> </LicensedModules>
></ISSKeys>
>==== end buffer:
>= Status:
>== Signatures ok: 0
>== Signatures fail: 1
>== SignedInfo Ref ok: 0
>== SignedInfo Ref fail: 1
>== Manifest Ref ok: 0
>== Manifest Ref fail: 0
>Error: operation failed
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.aleksey.com/pipermail/xmlsec/attachments/20020724/1193fb4a/attachment.htm
More information about the xmlsec
mailing list