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