Assertion signing confusion

[Eric Tiffany <eric@projectliberty.org>]

[sorry, I sent this a while ago, but my OASIS acct was hosed].

The issue of what XML to sign in the samlp:response message has come up
again.  We discussed this issue at length back in Nov and Dec '06 at our
test events.  The bottom line is that we agreed that signing can occur at
either the Assertion or message level, but the language in the various SAML
specs is still a bit ambiguous.

I think the first place to look is in the saml-core spec, section 5.3
"Signature Inheritance", which notes:

"A SAML assertion may be embedded within another SAML element, such as an
enclosing <Assertion> or a request or response, which may be signed. When a
SAML assertion does not contain a <ds:Signature> element, but is contained
in an enclosing SAML element that contains a <ds:Signature> element, and the
signature applies to the <Assertion> element and all its children, then the
assertion can be considered to inherit the signature from the enclosing
element. The resulting interpretation should be equivalent to the case where
the assertion itself was signed with the same key and signature options."

So this is a general statement about all profiles where assertions and
signing are concerned.  However, the SAML profile document makes other
statements which seem to make more strict requirements (sect 4.1.3.5, lines
497-500). 

" The <Assertion> element(s) in the <Response> MUST be signed, if the HTTP
POST binding is used, and MAY be signed if the HTTP- Artifact binding is
used."

In view of the first passage above, you could interpret the
<Assertion> as being signed by virtue of the whole message being signed.
However, experience shows that some implementers adhere to a strict
interpretation that the <Assertion> element must be signed for POST, and
they think this trumps the "signature inheritance" (or they didn't know
about it). 

But  to further complicate matters, Robert Aarts wrote to me later that

> I noticed the
> other day this section in the SAML Metadata (with errate included) spec:
> 
> WantAssertionsSigned [Optional]
> Optional attribute that indicates a requirement for the <saml:Assertion>
> elements received by this service provider to be signed. If omitted, the
> value is assumed to be false. This requirement is in addition to any
> requirement for signing derived from the use of a particular
> profile/binding combination. ****[PE7]Note that an enclosing signature
> at the SAML binding or protocol layer does not suffice to meet this
> requirement, for example signing a <samlp:Response> containing the
> assertion(s) or a TLS connection.*****

I think that this may add to the impression that the <Assertion> element
itself must be signed.

So I would suggest that clarifying language be added in the Profile document
around 4.1.3.5 line 500 indicating that the "signature inheritance" notion
applies to the <Assertion> element in a POST message --- if that is indeed
the intent.

ET

-- 
____________________________________________________
Eric  Tiffany             |  eric@projectliberty.org
Interop Tech  Lead        |  +1 413-458-3743
Liberty Alliance          |  +1 413-627-1778 mobile