Skip to Content.
Sympa Menu

per-entity - Re: [Per-Entity] implementing a cache on the client

Subject: Per-Entity Metadata Working Group

List archive

Re: [Per-Entity] implementing a cache on the client


Chronological Thread 
  • From: Tom Scavo <>
  • To: David Walker <>
  • Cc: Tom Scavo <>,
  • Subject: Re: [Per-Entity] implementing a cache on the client
  • Date: Thu, 28 Jul 2016 14:10:30 -0400

On Thu, Jul 28, 2016 at 1:53 PM, David Walker
<>
wrote:
> Yeah, having now seen your comment that AD FS requires TLS, I'm fine with
> using it. I just wouldn't advertise it as a way to verify the metadata.

When I say TLS, I mean the TLS protocol, not the TLS trust model based
on commercial CAs. For example, consider the mdq-beta server, which
has its own metadata signing key and corresponding long-lived,
self-signed certificate. We could configure TLS on the mdq-beta server
using the same key and certificate we use for signing. A TLS-based
metadata client would have to explicitly trust the public key
certificate since it's self-signed.

Note that Scott wrote the phrase "TLS validation against explicit
anchors" in the MDQ Client Software document. We don't know if AD FS
supports that model, but if it could, we would surely document it and
that would be an acceptable alternative to XML signature.

In summary, if we want to embrace MDQ clients other than Shibboleth
and SSP in our deployment plan, then we must configure TLS on the MDQ
server. If we're going to do that, we should do it in such a way as to
provide actual security benefit to the consumer.

Tom



Archive powered by MHonArc 2.6.19.

Top of Page