Shibboleth Developers

["Scott Cantor" <>]

> > 1. Every <md:KeyDescriptor> element in IdP metadata MUST have an
> > explicit use="signing" XML attribute.
> 
> By coincidence, we already enforce this one due to a bug in very very old
> Shibboleth SP software, now long removed.

I was trying to recall if there were any bugs in the IdP (the old one)
around this, but I don't think so. The IdP hasn't generally supported
encryption to itself, so the problems of mixing keys and usages has mainly
been in SP metadata, and IdPs have just used use="signing".

> > 3. Every role descriptor SHOULD have at most one encryption key.
> 
> We don't make such a restriction, and in fact (SP) entities often have
more
> than one encryption key during key rollover.

Tom's point is that in theory that isn't needed, since both keys are
available to the sofwtare, so you can switch the key rather than add them,
*if* you control the use attribute and can distinguish signing vs.
encryption.

This is true, but IMHO just makes the situation harder to understand, not
simpler.

> In theory, of course, things
> should continue to work if you removed the "old" encryption certificate
> during key rollover (although you need to keep both *signing* keys/certs
> around until the transition has been completed) but that's sounding to me
> like it might be a little tricky to explain.  If people misunderstand and
> remove both the old encryption and signing certificates at the start of
> rollover, they will break interoperability for a time.

That's why I think the more conservative approach I documented is the
simplest way to explain it to people, since it generally always works
(provided the consumers are non-buggy of course).

> If you feel that it's important for InCommon to publish metadata that
> conforms to a more restrictive profile, one route is to simply transform
the
> metadata before publication.  For example, in this case a couple of lines
of
> XSLT or equivalent can arrange to drop all but the first encryption key in
> each role, if that's what you think you need to be publishing.

I think that's the main issue here. It's fine for a federation to debate
what it thinks its metadata should do to maximize interoperability, and that
may involve restrictions that go beyond the standard set of assumptions.

-- Scott