Metadata "trust"

[Cantor, Scott]

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).

That doesn't mean they have to use it in dealing with you, I would note.
Nor does it mean anything if you have metadata explicitly containing it,
since it won't matter what's in the certificate.

>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.

That is, well, completely wrong. It *precludes* key rollover, because the
keys in the metadata are completely driven by what's configured in the SP.
That's exactly what you can't do if you want rollover to work, because you
have to separate the metadata from the keys actually used by the SP, in
order to control when the keys get published vs. configured.

That's one of the reasons why using the metadata handler directly is a bad
idea.

>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.

You should probably ignore anything that document says about trust or
metadata exchange. It was written with a total absence of understanding of
how metadata would actually work in practice. The spec covers the metadata
syntax and content, and a little bit about caching (which has been
corrected recently in errata) but the rest is essentially useless.

I tried to do a better job of explaining these issues in our wiki in the
Metadata and Trust Management topics.

That said, sure, if you trust the SSL/TLS connection, then you're
essentially getting the metadata direct from the source, and as long as
you're willing to trust the peer to tell you anything you want to know
about the peer, that's fine.

However, note that while the IdP might actually allow this safely, the SP
doesn't. If you were the SP, pulling metadata using the XML metadata
provider in the SP from an IdP does NOT validate the transport layer, ever.

>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).

It doesn't cache. It can supply a validUntil or cacheDuration. It can also
sign. But that makes no sense in this context, if they're going to keep
changing the key.

>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.

It's not, see above. You CANNOT use that process if you're going to point
people directly at the metadata handler. It simply won't work.

>I'm wondering if the vendor is perhaps confused over differing roles of
>the web server certificate vs. the SP encryption/signing cert.

There is virtually no doubt of that at all.

>Comments/suggestions/guidance?

Take anything that isn't managed by a federation you trust with an extreme
amount of salt. You are essentially owning the trust relationship and
there is a very high degree of chance that unless you're really breathing
this stuff daily, it won't be right.

Honestly, the safest choice outside of TTP federation is for you to
exchange metadata with those partners out of band, and never rely on
anything involving PKIX, CAs, or remote metadata. When changes have to get
made, you schedule it with each other. It sucks, but that's why we do TTP
federation.

-- Scott