OpenSAML user discussion

["Scott Cantor" <>]

> What is the purpose of being able to verify the signature 
> using only the keying material included within it?

Because otherwise it would be assuming that all deployments are based on out
of band key exchange in which the actual signing key is known. SAML doesn't
constrain anybody to any specific trust model, so it's possible to use PKI
to validate certificates that are sent with the message and are not
otherwise known to the RP. The RP of course must know what the "names" of
those certificates must be based on other configuration, but not the actual
keys.

> You can't trust the message to tell you which keying material to use to 
> trust itself.

Validating signatures is not a trust operation, it's a cryptographic one.
Binding the key used to verify the signature with the signer is a trust
operation and is not part of this code.

It's perfectly reasonable to rely on the message to tell you what key to
verify it with, since if it lies, it's not as though it's going to work. But
if the binding of the actual key to the signer is not known, then you would
have to examine the packaging of the key (the cert) once you verify it.

In other words, if you feed OpenSAML the key and it works, you're probably
done since you probably had a good reason for giving it the key. If you ask
it to verify the signature blind, then you probably have to follow that up
by getting the certificate(s) out and validating them.

> Yet there doesn't appear to be any warning about not trusting 
> the KeyInfo element if there's no additional mechanism to 
> prevent abitrary keying.  Clearly the goal is not just "this 
> content hasn't changed since key A signed it," but, rather, 
> "this content hasn't changed since the key that you expect to 
> have signed it has signed it"

Neither SAML nor XML Signature address trust. Your question is about trust,
not signatures, but OpenSAML only does the latter. Shibboleth, to use one
example, implements the former, as do all SAML implementations that aren't
merely toolkits.

-- Scott