Shibboleth Developers

["Scott Cantor" <>]

That idea I was all high on during the call isn't such a hot idea after all.
I started thinking about the most rudimentary CA trust plugin I could think
of, and it immediately starts to run into the same problems that led me to
generalize it into the current mess to begin with.

The only way it even begins to make sense is if the plugin is all or
nothing. As soon as you start constraining it down by saying it only applies
to X or Y, you're right back into the same thing we do now.

Secondly, the hard part is that as soon as you generalize to CAs, you have
to implement KeyName checks that you don't need if you just use keys
directly, which means metadata profiling anyway.

The plugin's likely implementation (in C anyway) is going to end up having
to do the same kind of nasty stuff that I have to do now. The hard part
isn't picking what CAs to attach to the transaction or attaching them, it's
fixing (by copying and reimplementing) OpenSSL's broken path validator. I
don't think that's quite so bad in Java, since it gets easier if you use a
single trust store. But that still leaves open the question of private key
management (i.e. do I still have to be able to pick a key/cert at runtime).

So, I think this is dumb. I don't love having to keep supporting this ugly
technology, but given the choice, I'd rather support it in a way that makes
some logical sense (CA foo applies to bar) than none at all.

The only thing I'd change is to make sure that the trust plugin can combine
information across metadata from multiple sources. It should just combine
trust rules from any source that knows about the relying party and see if
the transaction checks out. That way you could partition metadata if you
wanted to have endpoints in one place but trust rules separate, which starts
to get at the more useful possibilities, like pulling endpoint metadata
dynamically from the partner but getting keys centrally, for example.

-- Scott