per-entity - Re: [Per-Entity] HTTPS transport and TLS trust
Subject: Per-Entity Metadata Working Group
List archive
- From: Scott Koranda <>
- To: "Cantor, Scott" <>
- Cc: "" <>
- Subject: Re: [Per-Entity] HTTPS transport and TLS trust
- Date: Tue, 6 Sep 2016 10:13:06 -0500
- Ironport-phdr: 9a23:lAwYlRXX9jecMNOl4+atYv5yH53V8LGtZVwlr6E/grcLSJyIuqrYZR2At8tkgFKBZ4jH8fUM07OQ6P+wHzFbqs/c+Fk5M7VyFDY9wf0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3HUNPK+/0Ao/fidisn6D3osWLIlYAuD3oK5h7Kgmxt0GZjcIRnZcoYvI6wx3VpWEOIcxR3n4uKF6OyUXS/MC1qaVo9DhM89Em7cdGXayyK787SqZRCjgvG28w7czv8xLESF3ctTMnTmwKn08QUED+5xbgU8K063Oiuw==
> > What other objections are there to serving InCommon
> > metadata using the TLS trust model?
>
> Mainly the lack of trust constraints. If we assume that ADFS
> is validating the certificate correctly and performing
> revocation checking, it still validates any certificate it
> gets against any valid trust root, which means there's no
> control over which trust anchor is trusted for specific
> sources of metadata.
I see.
So as a contrast, the Shibboleth IdP allows me to effectively
say "for metadata downloaded from this URL use this X.509 CA
trust chain to validate the TLS trust, but for metadata
downloaded from this other URL use this other X.509 CA trust
chain".
You are arguing that ADFS does not (to the best of our
knowledge so far) allow a deployer to do that and will simply
search any and all of its trust anchors for a way to validate
the server X.509 being used for TLS trust, correct?
> Even if you do the self-signed thing, you still have to
> trust that self-signed cert for basically anything in order
> to trust it for that specific case.
In other words, a ADFS operator has to pull that self-signed
cert into one of its trust stores and there is no way to
specifically "bind" it to the operation of trusting SAML
metadata from one particular URL.
Correct?
> The basic objection is over whether people would leverage
> the TLS layer correctly or effectively and whether that's a
> thing to even encourage given the complexity of getting it
> right.
Thanks,
Scott K
- [Per-Entity] HTTPS transport and TLS trust, Scott Koranda, 09/06/2016
- RE: [Per-Entity] HTTPS transport and TLS trust, Cantor, Scott, 09/06/2016
- Re: [Per-Entity] HTTPS transport and TLS trust, Scott Koranda, 09/06/2016
- RE: [Per-Entity] HTTPS transport and TLS trust, Cantor, Scott, 09/06/2016
- Re: [Per-Entity] HTTPS transport and TLS trust, Scott Koranda, 09/06/2016
- RE: [Per-Entity] HTTPS transport and TLS trust, Cantor, Scott, 09/06/2016
- Re: [Per-Entity] HTTPS transport and TLS trust, Scott Koranda, 09/06/2016
- Re: [Per-Entity] HTTPS transport and TLS trust, Tom Scavo, 09/06/2016
- Re: [Per-Entity] HTTPS transport and TLS trust, IJ Kim, 09/06/2016
- RE: [Per-Entity] HTTPS transport and TLS trust, Cantor, Scott, 09/06/2016
- Re: [Per-Entity] HTTPS transport and TLS trust, David Walker, 09/06/2016
- RE: [Per-Entity] HTTPS transport and TLS trust, Paul Caskey, 09/06/2016
- Re: [Per-Entity] HTTPS transport and TLS trust, David Walker, 09/06/2016
- RE: [Per-Entity] HTTPS transport and TLS trust, Paul Caskey, 09/06/2016
- RE: [Per-Entity] HTTPS transport and TLS trust, , 09/06/2016
- RE: [Per-Entity] HTTPS transport and TLS trust, Paul Caskey, 09/06/2016
- Re: [Per-Entity] HTTPS transport and TLS trust, David Walker, 09/06/2016
- RE: [Per-Entity] HTTPS transport and TLS trust, Paul Caskey, 09/06/2016
- Re: [Per-Entity] HTTPS transport and TLS trust, David Walker, 09/06/2016
- RE: [Per-Entity] HTTPS transport and TLS trust, Cantor, Scott, 09/06/2016
- Re: [Per-Entity] HTTPS transport and TLS trust, IJ Kim, 09/06/2016
- RE: [Per-Entity] HTTPS transport and TLS trust, Cantor, Scott, 09/06/2016
Archive powered by MHonArc 2.6.19.