Shibboleth Developers

["Scott Cantor" <>]

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.

With signing, you can do fancy things like use metadata to authorize keys by
name and then use path validation, but encryption isn't like that. If we
don't store an actual key or certificate inside the metadata, we have no
mechanism today to obtain the peer's public key to do the encryption with.

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.

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 guess I would advocate we build an API for this, presumably just a
KeyResolver API which I already have, but implement it with metadata for the
time being. The problem with that is simply the point I raised above...once
we do that, the path validation stuff quickly becomes stupid to use.

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.

-- Scott