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

[Ian Young]

On 20 Jan 2014, at 17:42, Tom Scavo <trscavo at gmail.com> wrote:

> Since some software will actually try to check any CRLs or OCSP
> endpoints that might be contained in the certificate, checking for
> self-signed certificates is in exactly the same boat, I think. Is
> there a stage for that?

I'm not sure what you mean, exactly. A stage that would flag up self-signed certificates? Not at present, but again not hard to do.

> - redundant certificates should be avoided (since some software will
> not consume an <md:EntityDescriptor> element containing more than one
> encryption key)

I have considered writing a stage that would remove redundancies where possible. For example, a role containing two otherwise identical KeyDescriptors with use="signing" and use="encryption" can be replaced by just one KeyDescriptor with no use attribute. Removing duplicate encryption keys is an obvious extension of that. You can't do anything about the presence of multiple distinct encryption keys, though, without breaking normal key rollover for everyone else.

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

It complicates things, but it's not a barrier in principle: although most Stage implementations work item-by-item, a Stage has access to everything in the pipeline at the same time if it wants it. In the UKf tooling, for example, I have stages that detect things like duplicate mdui:DisplayName across all identity providers.

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.

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

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.

	-- Ian



-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5943 bytes
Desc: not available
Url : http://shibboleth.net/pipermail/dev/attachments/20140120/47e77234/attachment.bin