Metadata "trust"

[Chad La Joie]

There isn't "one true way" for establishing trust.

I think most rational and informed people, by now, harbor concerns
about the entire public CA infrastructure and what, exactly, it's
providing them.  That doesn't mean it's wrong but people certainly
need to take claims about CAs infallibility with a grain (or 5 pound
block) of salt. If you know their processes, and you're good with
them, then go for it.

Added to the general issues of public CAs, trusting metadata because
it's delivered over a trust SSL/TLS connection means that you are
willing to trust any information anyone with access to that server
publishes.   If you know their processes, and you're good with them,
then go for it.

In both cases there are dozens of switches and knobs that can be
adjusted.  In most cases you probably can get to a point where you're
comfortable.  How much work that will be will depend on where you set
the bar.

I think most technical people who have to deploy this stuff at scale
unanimously agree that PKI is very brittle and a source of a great
deal of pain and that blindly trusting everything published to a
server isn't good.  So we recommend self-signed certs and signed
metadata, ideally signed with an offline of HSM-protected key.

Specifically related to the metadata endpoints for the IdP and SP.
Scott and I have said repeatedly, those endpoints provide deployers a
starting point they can use to prepare their real metadata.  *Staring
point*, not ending state.

On Wed, Mar 14, 2012 at 19:37, 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/NativeSPMultipleCredentials,
> 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



-- 
Chad La Joie
www.itumi.biz
trusted identities, delivered