Failure to validate Response Signature

[Cantor, Scott]

On 10/4/12 5:00 PM, "Rainer Hoerbe" <rainer at hoerbe.at> wrote:
>
>No, there are only <ds:X509Data> and <ds:X509Certificate> elements. Does
>that mean that the trust engine does only following steps in this case?
>- extract <ds:X509Certificate> from response signature (a.k.a. IdP
>"Credential")
>- extract entityID in <issuer> from response and fetch the
><EntityDescriptor> addressed by it from metadata. It contains a
><X509Certificate> element (a.k.a. "verification key")
>- compare both <X509Certificate> elements

No, actually it compares the keys. The actual steps are:

- ask the metadata plugin to give it all of the valid keys it can return
for that issuer
- try the resulting keys in sequence to verify the signature

But in the first step, it uses the key from the KeyInfo in the message as
an input to the lookup process in the metadata. So what it does is say to
return only keys that "match" that criteria, which in the case of a public
key means "return a key only if it matches the input key exactly".

So in this case, either they don't really match, or some other criteria
for matching is getting in the way, and short of key names, I don't know
what that would be. If the certificates match exactly, there'd be no
explanation I can think of. I don't recall any cases in which something
like that has been reported and it hasn't turned out to be something
unrelated, usually the metadata not being what was assumed.

-- Scott