Shibboleth Developers

["RL 'Bob' Morgan" <>]

On Wed, 21 Jun 2006, Scott Cantor wrote:

> Another topic that's going to need some discussion at some point (I've 
> brought it up with Chad) is encryption keys. The problem with encryption 
> is that you need the peer's key.

I think you know as well as anyone that the answer to the question:  "how 
are people obtaining keys/certs in a distributed fashion these days?" is 
"they aren't".  By far the most pervasive use of on-demand key acquisition 
is SSL/TLS (as used with HTTP), where server certs flow as part of the 
protocol.  By far the most pervasive use of encryption is also 
SSL/TLS+HTTP, where this is done not with encryption keys per se but with 
symmetric keys negotiated as part of the protocol, based on public signing 
keys (and of course this is stream encryption, not store and forward).

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?

Or, there's RFC 4387, which specifies a HTTP/REST method for keyservers, 
and supports X.509 and PGP.  Anyone looked at that?

Or there's XKMS, which I believe provides key-fetching.

Or there's good old RFC 2585, which is the traditional spec for fetching 
keys via LDAP and HTTP.

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.

> If we start storing keys for encryption in the metadata, you quickly 
> have to ask why anybody would bother not doing that with the signing 
> keys and the path validation option becomes rather pointless. You lose 
> the benefits of key roll-over.

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

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

> If we don't store the keys there, that means building something else. 
> But we can't solve the problems of PKI in this project, so is it really 
> in scope to build a key indirection solution for our use of encryption?

I'm agreeing with Keith that those who want it can do it.

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

> This would be mostly unimportant if encryption wasn't useful, but I 
> think it's very useful and quite simple to implement in and of itself as 
> it turns out.

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.

 - RL "Bob"