[wsf-dev] signing questions

[Scott Cantor]

> > The TLS:peerSAMLV2 method would be TLS + SAML assertion and that's
> > it. Still "signed" but with TLS.
> 
> Peer means that the message contains a signature that uses the same
> keys that the TLS layer is using, right?   Or am I not understanding
> this correctly?

No, peer means the key used at the transport layer is the one referenced by
the assertion and thus satisfies the confirmation method. There is no XML
signature over the message.

> I like the pun ;)  - basically though, I either need to include the
> public key in the message, or a reference to that public key so that
> the result of the signature can be validated, right?

When you sign something, it's out of scope how the relying party does
anything to validate the signature. It is common to include the key or
certificate. With some models, the relying party might already have the key,
so including it is fine, but not always necessary.

In this case, things are more complex. The assertion is what actually
identifies the key you're supposed to use. The one in the Security header
would actually be redundant, since it has to be the same key. That doesn't
mean you shouldn't put it there, but all roads lead to the same place
anyway.

(Of course that assumes a SAML token is used. If you're just signing with a
key and relying on some other mechanism for the RP to trust your key, then
you certainly would normally put it in the signature.)

> By usually does, you mean that the public key is usually included in
> the KeyInfo?  By hint do you mean a reference to the key?

Yes, it's usually included, typically as a certificate (which both helps and
confuses matters).

No, I mean that KeyInfo is ALWAYS a hint. Whether it's a reference or not,
the RP MUST verify separately that the key used to sign "belongs" to the
signer. KeyInfo cannot do that for you. It's merely a way to shortcut things
so that you don't have to try the wrong keys.

In a model where a SAML HoK assertion is used, the assertion issuer is what
provides that proof of ownership to you, by embedding the key inside the
assertion. That allows a RP to decide that the signer is allowed to act as
the assertion's subject by virtue of trusting the issuer. Of course, that
trust is based on (ta da) the Signature in the assertion, and binding that
key to the issuer (rinse, repeat).

The problem is that you still have to compare the key inside the assertion
with the key used by the message signer. That's relatively easy if the key
is included by value, of course, it's simple math (or can be). But it's much
harder if references are used instead because that brings in the entire
notion of PKI.

All of this stuff is left out of scope. Which would be fine if the whole
system didn't depend on it. The reams of code you're seeing in OpenSAML et
al. are mostly about this whole problem.

The WSF mechs simplify the task of the WSC, but the WSP still needs to do
all this verification stuff, eventually chaining back to the SAML layer,
which is where my metadata comment came in.

If you're focused on the WSC side, things are much cleaner. Until you want
to verify the TLS key or signature of the WSP anyway...

-- Scott