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

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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


Subject: RE: [saml-dev] Signing protocols and assertions


> > Well, when you sign, you have to ensure that any
> > non-visibly-used namespaces are included or the message is
> > vulnerable to namespace substitution attacks.
> 
> Scott, do you mean non-visible used or non-visibly defined (e.g.
> the case when I use a namespace prefix, but the namespace is
> defined outside of the assertion)?  I would assum non-visibly
> used doesn't matter as it doesn't show up in the assertion
> at all.

It's a technical term from the excl c14n spec. "Non-visibly-used" means that
there is no element or attribute in the node set that is declared with a
given namespace. This doesn't include QName content in attributes or
elements, like xsi:type values.

If you *use* a prefix visibly, then it's pulled in by excl c14n even if it's
declared above. With c14n, of course, it's pulled in just by having declared
it, whether it's used or not, which is why you get context-dependent
signatures.

The InclusivePrefix element is the only way to force a namespace prefix into
the signed node set if it's used only in xsi:type or similar ways. If you
don't use the InclusivePrefix option when signing content like that, then an
attacker can declare a *different* namespace for those prefixes without
affecting the signature. One example attack is a DOS against message
validation, by declaring the xsi:type to be a non-existent namespace.
 
-- Scott




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