Per-Entity Metadata Working Group

[IJ Kim <>]

Just for the background information, another concern was the server
security which is assumed in TLS.  I'm not suggesting md.incommon.org is
not secure but it was difficult to quantify and it was certainly less
secure than the signing operation.  Ops also wanted to reserve the
flexibility of hosting its stand-by servers in co-locations without
special requirements on its physical security.

--IJ

On Tue, Sep 06, 2016 at 02:31:29PM -0400, Tom Scavo wrote:
> On Tue, Sep 6, 2016 at 9:40 AM, Scott Koranda 
> <>
>  wrote:
> >
> > My understanding is that the InCommon TAC in particular has
> > had objections in the past to serving any InCommon metadata
> > that *relies* on the TLS trust model.
> 
> That statement has some truth in it but that is not the whole story.
> All you have to do is raise this topic on the REFEDS list to start a
> religious war :-)
> 
> > Can someone familiar with that objection (Scott C or Tom S or
> > Nick R or ?) provide more details, or correct my understanding
> > if I am wrong?
> 
> I can give a historical perspective. AFAIK, InCommon has always
> published a metadata location that begins with "http://";. Originally,
> that location was:
> 
> http://wayf.incommonfederation.org/InCommon/InCommon-metadata.xml
> 
> Now it is:
> 
> http://md.incommon.org/InCommon/InCommon-metadata.xml
> 
> Server md.incommon.org does not support TLS, which is intentional. A
> surprising fact is that TAC recommended that md.incommon.org should
> support TLS. Ops disagreed with TAC (which is rare, and perhaps
> unprecedented) so md.incommon.org does not support TLS.
> 
> > What other objections are there to serving InCommon metadata
> > using the TLS trust model?
> 
> I'll sidestep that question (ScottC gave an answer) and suggest a
> thought experiment. Suppose md.incommon.org supported TLS. What
> metadata location would we publish and document? The only answer that
> makes sense (to me) is that we would publish a metadata location that
> begins with "https://";. But what about the documentation? Honestly, I
> wouldn't be able to write documentation that makes sense (to the
> average deployer). That little "s" in the URL really complicates the
> message, so in the end we decided not to support TLS on
> md.incommon.org.
> 
> An MDQ server gives us an opportunity to revisit this issue. I'll stop 
> there :-)
> 
> Tom

-- 
IJ Kim, Technical Services Group
100 Phoenix Drive, Suite 111
Ann Arbor, MI 48108

Visit our website: www.internet2.edu
Follow us on Twitter: www.twitter.com/internet2
Become a Fan on Facebook: www.internet2.edu/facebook