[xmlsec] XMLSEC Reference URI question
Aleksey Sanin
aleksey at aleksey.com
Thu Jul 25 08:42:38 PDT 2002
After quick look, the XMLSec output seems correct. XMLSec produced
exactly what
you've seleceted. However, the error says that digests do not match and
this means that
Apache generated another output. I do see few possible options:
1) Apache calculated wrong nodes set (from XPath expressions)
2) Apache did different C14N for the same nodes set
3) something else more stupid on Apache or XMLSec side
I would vote for option 1) since the C14N is very simple here (no
namespaces, etc.) and
we already have seen problems with XPath transform in Apache. But only
Apache output
"just before digesting" can actually help to identify the problem.
With best regards,
Aleksey
Moultrie, Ferrell (ISSAtlanta) wrote:
> Aleksey:
> Ok .. we've reworked the XPath and xmlsec's buffer start/end now
> shows the correct data (only the selected Contact key and the <Signature> block is omittied). Still, it won't verify. I'd greatly appreciate it
> if you could take one more look and see if you see any other reasons
> why things might not be working as expected. The command used was:
> xmlsec verify --print-all --trusted new_export.pem test_allkey_06.xml
> I've attached the XML file, the PubKey cert and the program output.
> I'm also trying to find out if the signing stuff on the web server can
> provide any more details on what/how it did when building the
> signature -- but I've never touched any of that stuff so I'm having to
> work through our web folks for that information.
> Thanks!
> Ferrell
>
> -----Original Message-----
> From: Aleksey Sanin [mailto:aleksey at aleksey.com]
> Sent: Wednesday, July 24, 2002 10:23 PM
> To: Moultrie, Ferrell (ISSAtlanta)
> Cc: 'xmlsec at aleksey.com'; Dodd, Tim (ISS Atlanta)
> Subject: Re: [xmlsec] XMLSEC Reference URI question
>
> Well, "failing to validate reference" simply means that the
> digests values do not
> match. In this particular case, when Apache calculated digested
> the c14n output
> both digest and signature values (content of <dsig:DigestValue>
> and <dsig:SignatureValue>
> elements) were *not known* yet. Since as we found this XPath
> transform includes
> *all* nodes from the input document when you are veryfing the
> document,
> both <dsig:DigestValue> and <dsig:SignatureValue> elements (and
> the content of these
> elements: the actual base64 encoded digest and signature values!)
> are *included*
> in the digested data.
> And of course, the "sign" and "verify" digests are different
> because the digested
> data are different :)
>
> This explains why XMLSec fails to validate this document and also
> shows that
> any *correct* implementation of XPath transform MUST fail to
> validate it.
> Since you wrote that Apache has no problems with validating this
> document I suspect
> that Apache does not implement the XPath transform correctly :)
>
> Probably you can find our more if you can get the c14n output
> (just before digesting)
> from Apache (something similar to --print-all option in xmlsec). I
> am sorry but
> I could not help you with it since I gave up on installing Apache
> toolkit long time ago (this
> was the main reason why I wrote XMLSec library :) ).
>
> Aleksey
>
>
>
>
> Moultrie, Ferrell (ISSAtlanta) wrote:
>
>> Aleksey:
>> Yes -- you're right. I even recall reading a discussion about
>> this in the discussion of enveloped signatures in the
>> specification. I wondered at the time why they used the
>> convoluted XPath count function rather than a more direct
>> approach -- now I get it.
>> In any event - I suspect that Apache is actually still
>> signing/verifying the entire document just like XMLSEC is
>> *trying* to do. So .. I should be able to verify this document
>> also using XMLSEC. Do you have any idea from the sample our it's
>> output as to why it fails to validate the Reference? This is
>> *always* the hard part of digital signature work -- when it
>> doesn't work -- figuring out *why* it failed. What bit is wrong
>> where ...
>> Thanks!
>> Ferrell
>>
>> -----Original Message-----
>> From: Aleksey Sanin [mailto:aleksey at aleksey.com]
>> Sent: Wednesday, July 24, 2002 9:22 PM
>> To: Moultrie, Ferrell (ISSAtlanta)
>> Cc: 'xmlsec at aleksey.com'; Dodd, Tim (ISS Atlanta)
>> Subject: Re: [xmlsec] XMLSEC Reference URI question
>>
>> 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
>>>
>>>
>>
>
>------------------------------------------------------------------------
>
>FAIL
>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:
><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 knowwhere Lane" Address2="suite 300A" City="Atlanta" Country="US" Email="customer_relations at iss.net" Fax="778-555-7799" Phone="777.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="30064" Weburl="http://web.suport_iss.net"></Support>
> <Version>1.0</Version>
> <OCN>163444</OCN>
> <Source>ISS Atlanta</Source>
> <Serial>ACC64BB4-A53D-AC83-3E6F-E0AB737DEC9D</Serial>
> <Timestamp>2000-06-14 10:34:09</Timestamp>
>
> </Contact>
>==== 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/20020725/be384d95/attachment.htm
More information about the xmlsec
mailing list