santuario-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Berin Lautenbach <>
Subject Re: Possible signature verify bug?
Date Wed, 11 Oct 2006 09:48:33 GMT
That definitely looks wrong.  I will take a look.  It's very wierd - 
this is straight excl c14n and a very simple case.  It's exactly the 
sort of thing the basic test cases look at.


Scott Cantor wrote:

> Berin,
> I think there's a really blatant bug in the C++ c14n code that's running
> during signature verification. I think I only missed it before because I had
> so much defensive code in place to output namespaces. I had a bug in my new
> code that caused a namespace to be left off because the parent declared it,
> and stumbled on to this test case.
> I ran it through a vanilla test case that just parses the DOM and verifies
> the signature, and the Reference isn't digesting properly. When I debugged
> it, the bytes fed into the hash were missing a namespace declaration that
> should have been pulled in from the parent of the node being referenced.
> I've attached the test case, which is a nested SAML message with the
> signature on the second-level element.
> What's happening is that I have this declared (edited for brevity):
> <samlp:ArtifactResponse xmlns:samlp="..." >
> 	<samlp:Response xmlns:saml="...">
> 		<saml:Issuer>
> 		<saml:Assertion>
> 			...
> The signature references the <samlp:Response> by ID.
> The bug is that the transform chain produces this:
> 	<samlp:Response>
> 		<saml:Issuer xmlns:saml="...">
> 		<saml:Assertion xmlns:saml="...">
> As you can see, xmlns:samlp isn't included from the parent/root element.
> I think it should be, even though the reference is being transformed with
> exclusive c14n. It's visibly used by the Response element, and so it should
> get pulled in from the enclosing node. If I parse the DOM with that
> namespace declaration manually added, the signature verifies, which tells me
> that's the missing piece.
> The document I attached verifies with the Java xmlsec code from what I can
> tell. Oxygen is ok with it, anyway.
> I haven't done any tests of the c14n engine by itself to produce test
> output, but I would assume that's where the bug is.
> -- Scott
> ------------------------------------------------------------------------
> <samlp:ArtifactResponse xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol" ID="_e5e553f51fe1a009374bdf2186a685d8"
IssueInstant="2006-10-11T03:12:59Z" Version="2.0"><samlp:Status><samlp:StatusCode
Destination="" ID="rident" IssueInstant="1970-01-02T01:01:02.100Z"
Version="2.0" xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"><saml:Issuer></saml:Issuer><ds:Signature
> <ds:SignedInfo>
> <ds:CanonicalizationMethod Algorithm=""/>
> <ds:SignatureMethod Algorithm=""/>
> <ds:Reference URI="#rident">
> <ds:Transforms>
> <ds:Transform Algorithm=""/>
> <ds:Transform Algorithm=""/>
> </ds:Transforms>
> <ds:DigestMethod Algorithm=""/>
> <ds:DigestValue>U562AIbwQ8i5kQcxOjTfYAsqbOs=</ds:DigestValue>
> </ds:Reference>
> </ds:SignedInfo>
> <ds:SignatureValue>n5AGrOWy1WkZWaIVrXlr1iBeZ8YsGJLHsS+n472wmFxHn/GT8PsCDS78UjpIFVxY
> qK4G3O5p7rQwe8IGYeWeG3pjclvXcP6KH1CwjlJL3ndaZqu1tVdYqx3fbTAK5QRV
> gDUlyje2TRAgF1YSyyunRmJgOEXJ+JTe8brCmTrkr0E=</ds:SignatureValue>
> <ds:KeyInfo><ds:X509Data><ds:X509Certificate>MIICjzCCAfigAwIBAgIJAKk8t1hYcMkhMA0GCSqGSIb3DQEBBAUAMDoxCzAJBgNV
> qE5dka4z9W9zytoflW1LmJ8vXpx8Ay/meG4z//J5iCpYVEquA0xl28HUIlownZUF
> 7w7bx0cF/02qrR23AgMBAAGjgZwwgZkwHQYDVR0OBBYEFJZiO1qsyAyc3HwMlL9p
> JpN6fbGwMGoGA1UdIwRjMGGAFJZiO1qsyAyc3HwMlL9pJpN6fbGwoT6kPDA6MQsw
> gYEAMFq/UeSQyngE0GpZueyD2UW0M358uhseYOgGEIfm+qXIFQF6MYwNoX7WFzhC
> LJZ2E6mEvZZFHCHUtl7mGDvsRwgZ85YCtRbvleEpqfgNQToto9pLYe+X6vvH9Z6p
> gmYsTmak+kxO93JprrOd9xp8aZPMEprL7VCdrhbZEfyYER0=</ds:X509Certificate></ds:X509Data></ds:KeyInfo></ds:Signature><samlp:Status><samlp:StatusCode
ID="aident" IssueInstant="1970-01-02T01:01:02.100Z" Version="2.0"><saml:Issuer></saml:Issuer><saml:Subject><saml:NameID>John
Doe</saml:NameID></saml:Subject><saml:AuthnStatement AuthnInstant="1970-01-02T01:01:02.100Z"><saml:AuthnContext><saml:AuthnContextClassRef>foo</saml:AuthnContextClassRef></saml:AuthnContext></saml:AuthnStatement></saml:Assertion></samlp:Response></samlp:ArtifactResponse>

View raw message