OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Signatures in protocols (section 3 of core)

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

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 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 and message integrity may
often be required. Authentication and integrity MAY be provided by the
protocol binding (see [SAMLBind]). The SAML request MAY be signed, which
provides both authentication of the requester and message integrity.

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

Similar text would go in lines 1433-1434. Or I guess a separate subsection
could be used.

The difference is just to make sure that the use of the signature is clearer
and that nobody would ever think they should process a message that's
obviously been tampered with, which is just dumb.

-- Scott

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]