Skip to Content.
Sympa Menu

assurance - Re: [Assurance] Information Security Guide to InCommon IAP Cross Reference

Subject: Assurance

List archive

Re: [Assurance] Information Security Guide to InCommon IAP Cross Reference


Chronological Thread 
  • From: Tom Scavo <>
  • To:
  • Subject: Re: [Assurance] Information Security Guide to InCommon IAP Cross Reference
  • Date: Sun, 22 Jul 2012 20:04:34 -0400 (EDT)

Scott says:
>
> It's not unreasonable on its face, but it is a giant pain. Every
> non-Shibboleth/SSP SP out there is going to break, requiring a large
> effort and usually a flag day. There's no rollover possible with most
> commercial or one-off SPs. Many don't support multiple acceptable
> keys.

Ian says:
>
> Just to balance that out and prove that the universe isn't prepared
> to give anyone a break, we also have a lot of SPs which handle
> multiple trust fabric certificates in metadata badly. So, yes,
> every time anyone replaces a certificate they lose connectivity to
> some SPs during the transition. It's a huge pain for everyone and
> it costs the helpdesk a lot of time sorting out, because the IdP
> people don't tend to be expecting it and often can't figure out what
> has gone wrong.

And so it is. But let me quickly point out (to others following this thread)
that there's a difference between *replacing* and *migrating* a certificate
in IdP metadata. The former is done in response to a known or suspected key
compromise while the latter happens more leisurely, presumably as a
precautionary measure or to improve interoperability. The fact that some SPs
don’t handle migration very well shouldn’t stop an IdP from doing it. The
alternative (replacing a certificate in metadata) is certainly worse.

Some folks are probably wondering if this discussion is off topic...after
all, isn’t this mailing list about Bronze/Silver? That’s true, but for better
or worse Bronze/Silver are targeted at Federation IdPs and the security
assertions they issue to SPs via federated login. Since the trustworthiness
of those assertions can be traced to the IdP’s private signing key, the
security surrounding that private key is paramount.

While some InCommon IdPs will ultimately be certified and labeled as “Bronze”
or “Silver” (or both), there is a very basic level of assurance that all 249
IdPs in the Federation should strive to attain. Those that do will eventually
be labeled as such, in the same way that IdPs are labeled “Bronze” or
“Silver,” so that SPs have a basis on which to trust the assertions received
from IdPs. In that sense, assurance touches all InCommon IdPs.

Tom



Archive powered by MHonArc 2.6.16.

Top of Page