Shibboleth Developers

[Thomas Lenggenhager <>]

Scott Cantor wrote:
> 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.

My concern with keys in metadata is the deployment issue, when an SP or
IdP has to replace a key. Would there be means for smooth key changes
with no service interruption?
Provided the policy requires new keys for certificate renewal, that
might happen once a year for each SP or IdP.

Is it related with dynamic metadata retrieval, based on the providerId?
If I understand correctly, dynamically retrieved metadata would have to
be signed by a trusted third party.

Thomas
-- 
Thomas Lenggenhager           http://www.switch.ch/
SWITCH       The Swiss Education & Research Network
Zurich, Switzerland            Tel: +41 44 268 1541