Shib MDA 0.8.0 can check the certificate's metadata expiration?

Tom Scavo trscavo at gmail.com
Mon Jan 20 13:23:02 EST 2014


On Mon, Jan 20, 2014 at 1:08 PM, Ian Young <ian at iay.org.uk> wrote:
>
> On 20 Jan 2014, at 17:42, Tom Scavo <trscavo at gmail.com> wrote:
>
> A stage that would flag up self-signed certificates?

Yes, exactly.

>> - redundant certificates should be avoided (since some software will
>> not consume an <md:EntityDescriptor> element containing more than one
>> encryption key)
>
> You can't do anything about the presence of multiple distinct encryption keys, though, without breaking normal key rollover for everyone else.

You can flag such entity descriptors as possible interoperability
issues, just like self-signed.

>> - certificates should not be shared (since some software will not
>> consume two <md:EntityDescriptor> elements that contain the same
>> certificate)
>>
>> The latter is particularly onerous since it can't be determined by
>> examining a single EntityDescriptor.
>
> If this was something worth checking, then it would probably be best built as two stages: one which extracted all certificates used by an entity into the item metadata (which is what this kind of meta-metadata is called in the MDA framework) and a second one that looks for particular conditions across those collections. It's not trivial, but it's not particularly hard in principle; all the structures are there.

Whether it's worth checking depends on your frame of reference, I
guess. Knowing where potential interoperability issues lie is the
first step. If avoiding them altogether (by simply not importing them)
keeps deployments from breaking, that would be useful, I think.

>> In all cases, when I say "some software," I'm referring to a specific,
>> well-known implementation that exhibits all of these issues (including
>> the expired certificate issue in MDA-75).
>
> If what you were interested in was essentially a list of entities which participate in practices that The Nameless Implementation had problems with, that's definitely possible within the framework. Similarly, deriving a new aggregate which only included non-problematic entities is then very simple.

That's something to think about, yes.

> Obviously, given that many of those practices are otherwise legal and indeed (in the case of key rollover) good practice, you probably wouldn't want to detect and outlaw them entirely.

Agreed, but let me point out in passing that multiple encryption keys
is NOT a recommended practice since they are not strictly required for
key rollover. (https://spaces.internet2.edu/x/dpiKAQ)

Tom


More information about the dev mailing list