Verification failed for URI
Cantor, Scott
cantor.2 at osu.edu
Thu Aug 2 19:26:22 EDT 2018
On 8/2/18, 7:16 PM, "users on behalf of Brent Putman" <users-bounces at shibboleth.net on behalf of putmanb at georgetown.edu> wrote:
> That's true, but if the metadata is signed and you have the SignatureValidation filter enabled with
> requireSignedRoot="true", as he does, then that warning re MITM is not really relevant.
Only if signatures are combined with short validity windows and a filter to enforce the upper bound on that window, otherwise you're vulnerable to injection of old metadata that invalidates revocation.
In practice, this just isn't something you can rely on any single SP to do, it's a trust model that only works at federation scale. SAML has no trust model outside of our federation model, it's simply "punt, do nothing, pretend it's fine". How we got here is sad and confusing, but when I tossed PKIX, I never anticipated people would simply accept "nothing" as an alternative for revocation.
> I'd say personally that's a little strong. If used correctly, as it appears to be here, then it's technically speaking fine,
> albeit a little atypical.
It's a case of overstating the facts to convince people to avoid doing something that's a bad idea 95% of the time. Not to mention you're trusting that SP to actually use their metadata properly when it comes to changing keys, etc. You just can't in practice, so it breaks anyway.
"Never do it" is a better piece of advice for the vast majority of deployers than trying to explain all the caveats one would have to understand and implement to do it properly.
That's always been my underlying thinking anyway.
-- Scott
More information about the users
mailing list