Per-Entity Metadata Working Group

[Nick Roy <>]

Securing the MDQ server with the key you're using to sign metadata seems like 
the worst possible approach because you're putting that signing key at risk 
by having it on a live, Internet-facing server.

Nick

On 7/28/16, 12:10 PM, 
"
 on behalf of Tom Scavo" 
<
 on behalf of 
>
 wrote:

    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