[wsf-dev] signing questions

[Asa Hardcastle]

Wow. Not confusing in the least!!

> 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.

ok.  Given a WSC "c" and a WSP "p".    For Peer, there must be  
ClientTLS established, meaning mutual TLS.   This requires that both c  
and p have private keys.   Does p tell c to use a specific private key  
that c has and p knows about?


> 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.

check.

> 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.

ugg.. So as a WSC, the SAML Assertion given to me would specify that I  
use a specific private key for the TLS?

> (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.)

I see.  So what I am currently doing, which is signing an outgoing  
message with my very own key, paying no heed to the SAML Assertion,  
would be acceptable, but has no relationship to the TLS:SAMLV2 sech  
mech.  Rather it is signed TLS:Bearer with the Bearer Token being a  
SAML assertion.  I am relying on the party that I am communicating  
with to already trust me (and trust that I've kept my key safe and not  
checked it in to an open source svn repo) and have my public key  
available.

>
>> 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.

I get it now.  So this could potentially save a high traffic end point  
a great deal of pain by hinting at the proper cert.



> 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).


Ok.  So as a WSC the following process might take place.

1. SAML Authority issues a HoK Assertion to the WSC (through some auth  
process).  The WSP has a trust relationship with the SAML Authority

2. WSC signs a request with its private key and sends request to WSP  
over SSL (using the WSPs cert).  WSP already has or is supplied with  
the WSCs public key

3. WSP signs message with its private key and sends response encrypted  
with the key provided in the HoK Assertion.  WSC already has the  
server's public key.

How does the WSC decrypt the response?   Step 3 is a little fuzzy to me.


> 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...

So as a WSC my life is relatively simple, unless I want to do  
verification of a WSPs responses.

asa