Metadata file comment text

[IAM David Bantz]

Peter's summary should be somewhere in the documentation where folks will
encounter it.

David Bantz
U Alaska

On Thu, Apr 27, 2017 at 10:32 AM, Tom Scavo <trscavo at gmail.com> wrote:

> 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
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20170427/f17ceee4/attachment.html>