Re: [security-services] Signatures in protocols (section 3 of core)

[John Kemp <john.kemp@nokia.com>]

ext Scott Cantor wrote:

>Per the note I just sent, I'm trying to wordsmith some new text for the
>generic text in section 3 around <ds:Signature> in the request/response
>types.
>
>I really don't see the logic in the current text, which says that if I get
>an invalid signature, I'm allowed to consider it valid. (Note that this has
>nothing to do with trust, I'm just talking about the crypto.) What possible
>use case would we see for that and why would it be a good thing?
>
>Instead, I think we should clarify the difference between signature validity
>and trusting the signer, and be more clear about message integrity here.
>
>  
>
I agree wholeheartedly with this intention.

>I propose the following text to replace lines 1318-1320:
>
>"Depending on the requirements of particular protocols or profiles, a SAML
>requester may often need to authenticate itself
>
Insert: ", "

> and message integrity may
>often be required. Authentication and integrity MAY be provided by 
>
Insert: "mechanisms provided by"

>the
>protocol binding (see [SAMLBind]). The SAML request MAY be signed, which
>provides both authentication of the requester and message integrity.
>  
>
I am fine with the MAY if this is not a duplicated requirement from some 
other part of [SAMLCore], otherwise, I think this text should just be 
informative.

>If a signature is used, then the <ds:Signature> element MUST be present, and
>the responder MUST verify that the signature is valid (that is, that the
>message has not been tampered with) in accordance with [XMLSig]. If it is
>invalid, then the responder MUST NOT rely on the contents of the request and
>SHOULD respond with an error. If it is valid, then the responder SHOULD
>evaluate the signature to determine the identity of the signer and MAY
>process the request or respond with an error."
>
>  
>
Yup - looks good.

- JohnK