Shibboleth Developers

["Scott Cantor" <>]

> The new-key-from-the-same-CA example might be the only case where
> the non-CA approach causes extra trouble.  A change of CA might not
> work in any cass.  Nor would a change of CN.

Actually, a CN change wouldn't matter unless it affected the metadata
locations too.

As you say, the extra work is in the renewals, most of which argues for the
IdP "blessing" the SP's credentials in most cases (unless a federation does
it for you). Then you schedule the renewals anyway, based on whatever policy
you want, so it doesn't much matter whether it's you issuing a cert, or just
entering metadata

I think the real benefit of a CA accrues to the SP dealing with a bunch of
IdPs. And I don't see much there, because dealing with InCommon would be the
same even if we weren't issuing certificates. You'd still be "registering"
your key on some periodic basis with the federation and the metadata is just
a big XML certificate. Where the SP wins is in handling multiple
point-to-point relationships because there's nobody to manage the key
renewal for them. Again, though, it's a tools issue. People want to sell
software for this kind of thing.

A PKI is one way to smooth over not having those tools yet, but of course
its tools and user experience are lousy too. So I'll go a short way out on a
limb and claim that the future here is tools that manage federated trust
without using CAs in the usual sense, decomposing them into different parts
of the traditional CA process, signing metadata, registering keys.

-- Scott