Shibboleth Developers

["Scott Cantor" <>]

> I could imagine putting a PGP keyserver protocol 
> implementation behind a KeyResolver API; maybe some people have keys in
> PGP keyservers that they could leverage?

For servers? This is is just S-S encryption we're focused on.

> Or, we might look at the current Shib practice of monolithic SAML metadata

> files distributed from well-known central places via cron+http and say, 
> hmm, that sure looks like it needs a distributed mechanism, and if that 
> metadata has encryption keys in it too, then Bob's your uncle, no special 
> encryption-key-fetching protocol needed.

That was part of my thinking, sure.

> People who are invested in complex cross-certification and path-validation

> scenarios may also be invested in, say, LDAP/X.500-based methods of key 
> distribution (some parts of the US government claim to be so).

This would be news to me if true, another reason I asked for input.

> If you're contending that supporting encryption with keys in metadata 
> means that the current support for CAs in metadata can be dropped, I just 
> don't think so.

No, you misunderstand my point there...I'm saying it will kill it naturally
when people say "hey, we're getting nothing from this, we still have to rely
on the metadata getting corrected if keys are compromised, etc."

> Of course, support for any feature can always be handled 
> by "let the community that wants it code it", but I observe that InCommon,

> for example, is CA-based now.  Would it be easier to change it to 
> all-keys-in-metadata or to continue supporting CA use in Shib 
> as it is now?

The change would be minimal, I think. Trust=metadata now. It's immaterial
whether it's a one step or two step algorithm at runtime, it's still "load
signed metadata" to me as a deployer.

We don't use CRLs, etc. so all the other ancillary pieces of PKI that are
implied by using a CA are arguably being omitted at our peril. At least an
inline approach has a certain clarity to it.

But regardless, none of this is what I'm really trying to say. We don't have
to drop the support for CAs because we'd be implementing a feature that
makes it obsolete naturally and people will stop using it over time.

> I think the problem for this project (or its friends) will be a 
> SAML-metadata-indirection solution.

Understood.

> It's always all about key management, which is why encryption will be a 
> hard sell no matter how useful and elegant the implementation is in Shib.

Just as with signing, if the goal is end user to end user, yeah, it's
impossible, but I think server to server will be doable here.

-- Scott