Shibboleth Developers

[Ian Young <>]

On 24 Oct 2010, at 20:38, Tom Scavo wrote:

> As a result, I will recommend the following deployment requirements
> within the InCommon Federation:

Just wanted to provide some data points against what we see in the UK 
federation, as an example of another large-scale deployment.

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

> 2. Using forms-based submission, a site admin MUST be able to bind
> separate signing and encryption keys, even if those keys are
> identical.

If I understand what you're saying here, that's more a requirement for 
InCommon's registration tools than a deployment requirement.

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

> 4. Where multiple keys are listed within a single role descriptor,
> unexpired certs SHOULD precede expired certs.

We prefer, per the IOP profile, not to have expired certificates at all.  
When we do have them, we don't make any distinction or impose any ordering, 
again per the IOP profile.  We document the semantics of credential 
verification in one of our technical documents now, and we say there that we 
expect all KeyDescriptors to be considered.

> 5. The same certificate SHOULD NOT be used by two different entities.

We definitely don't enforce this.  In fact, there are a number of pretty 
major service providers in the UK federation who use the same public key (and 
the same certificate) for multiple entities, and I don't see that changing.  
If you're saying that ADFS has a restriction here (because, for example, it 
regards it as valid to look up the entity by the key presented, not by the 
entity ID presented) then I'd have to say that there will be interoperability 
issues as a result.  I'd also have to call it a bug.

> 6. A certificate in metadata SHOULD NOT have a CRL Distribution Point
> (CDP) certificate extension.

Don't think I've ever seen one of those, so no comment.

> The following software requirements should be documented as well:
> 
> 1. To support key rollover, an implementation MUST be able to consume
> and utilize up to two <md:KeyDescriptor use="signing"> elements in a
> single role descriptor.
> 2. To support key rollover, if an implementation supports encryption,
> it MUST be configurable with up to two decryption keys.

I agree with the sentiment, but there's an ambiguity in the text.  I suspect 
that what you want is something like:

"Implementations SHOULD support key rollover.  In order to support key 
rollover, implementations MUST <do those two things>"

> 3. If an implementation produces metadata on-the-fly, it SHOULD
> produce metadata with at most one encryption key.

I have to disagree with this recommendation, and agree with Scott's earlier 
comment.  Attempting to constrain all other implementations to permanently 
cater for a current bug in one implementation is not a good long-term 
approach.

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.

        -- Ian

Attachment: smime.p7s
Description: S/MIME cryptographic signature