Metadata "trust"

[Paul Hethmon]

I think both Chad and Scott have contributed quite a bit of good
information on this topic, but also felt the need to throw in my opinion.

The problem you are trying to solve here is one of trust, not security. In
the wild Internet, certs signed by a well-known CA are a useful means to
establish trust so you know you are really talking to "Joe's Widgets"
instead of some site scamming to get your credit card number.

In the SAML SSO world, the trust is established by configuration. If I
tell my IdP or SP to load metadata with a public certificate in it, I've
told it to trust it. End of story. What I need to do as an administrator
is determine how I trust that metadata. Do I download it from a publicly
accessible site, perhaps protected by SSL (and again that signed
certificate), do I get the metadata out of band via personal contact with
the partner? Regardless of how I establish trust, once I have that cert
(metadata), it doesn't really matter, I have made a decision to trust it.

Once I trust it, then security will flow from that trust. The SAML
messages will use that certificate to show that I'm talking to the party I
trust.

Paul


On 3/14/12 7:37 PM, "Tom Poage" <tfpoage at ucdavis.edu> wrote:

>I have a vendor telling me their decision to use an X.509 certificate
>signed by a well-known CA as SP encryption/signing key is to satisfy
>some clients requiring identity verification by a third-party CA (cf.
>high-assurance, EV, ... certs).
>
>The same also tells me to to use their
>https://.../Shibboleth.sso/Metadata URL with a
>FileBackedHTTPMetadataProvider in our IdP to accommodate key/certificate
>rollover when this encryption/signing certificate expires in three years.
>
>I haven't convinced myself to buy into this quite yet, except ...
>
>Section 4.3.3 (third bullet) of the saml-metadata-2.0 doc suggests (to
>me) fetching metadata over an SSL/TLS connection is sufficient as long
>as I trust the server. OK, so XML digital signature is perhaps not
>absolutely required to "trust" the metadata.
>
>Down side, the SP /Metadata URL does not provide a validUntil nor a
>digital signature, and I don't know if /Metadata end point knows how to
>respond to HTTP If-Modified-Since (doesn't appear to), so it looks like
>I'd need to poll every so many hours/days (maxRefreshDelay).
>
>As long as the vendor adheres to good key rollover practice, cf.
>https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPMultipleCrede
>ntials,
>then this might be workable.
>
>I'm wondering if the vendor is perhaps confused over differing roles of
>the web server certificate vs. the SP encryption/signing cert.
>
>Comments/suggestions/guidance?
>
>Thanks.
>Tom.
>
>--
>To unsubscribe from this list send an email to
>users-unsubscribe at shibboleth.net