Metadata file comment text

[Tom Scavo]

Excellent summary, Peter.

Tom

On Thu, Apr 27, 2017 at 5:15 AM, Peter Schober
<peter.schober at univie.ac.at> wrote:
> * Kannadasan Venkatachalam <venki at ntu.edu.sg> [2017-04-27 10:06]:
>> <!--
>> This is example metadata only. Do *NOT* supply it as is without review,
>> and do *NOT* provide it in real time to your partners.
>> -->
>>
>> Does the red text mean we should not be providing this link for
>> access?
>
> Not for anything other than maybe taking a snapshot of the metadata
> and republishing that in other ways.
>
>> Can someone please advise why this line is included and what are we
>> supposed to check?
>
> You would have to understand the issues involved in order to make that
> safe. So it's easiest to say "Don't do that", though a reference to a
> wiki page detailing the Why wouldn't hurt.
>
> There are least two unrelated issues here:
>
> Trust management[1], i.e. the question how/why someone else should
> trust endpoints and crypographic keys from a text file downloaded
> automatically over the Internet.
>
> Now you may decide that relying on TLS alone is sufficient for this,
> but do you know all the failure modes of the TLS and HTTP libraries in
> use at every relying party consuming your metadata?
> (Think about the many ways graphical web browsers today are trying to
> signal a degradation or reduced/broken trust in TLS connections -- can
> you be absolutely certain automatically downloading metadata will fail
> at the relying parties' systems if something is not OK with TLS?)
>
> The alternative to relying on TLS is signing the metadata itself. But
> why should a metadata consumer trust a signature of your own, claiming
> that your own metadata is legit?
> So for that to make any sense the signature would have to come from
> someone else, usually a trusted third party the metadata comsumer is
> willing to rely on (e.g. what we call a federation operator). But with
> third party-signed metadata often it's also the third party that's
> hosting the signed metadata -- mostly because that's easier to do than
> getting the third party-signed metadata hosted at the end entity
> (i.e. at your SP).
>
>
> The *other*, unrelated, issue is about decoupling the internals of
> your current system configuration (automatically reflected in the SP's
> autogenerated metadata) from what you want metadata consumers to see
> at a given point in time. E.g. you might have several keys configured
> to decyrpt incoming SAML protocol messages but you'd only like to
> publish one of those at some point, usually during key rollover.
> It's not unthinkable to create software configuration that takes all
> this into consideration (e.g. SimpleSAMLphp does this, IIRC) but I'm
> not sure the Shib SP currently offers this.
>
> HTH,
> -peter
>
> [1] https://wiki.shibboleth.net/confluence/display/CONCEPT/TrustManagement
> --
> To unsubscribe from this list send an email to users-unsubscribe at shibboleth.net