Shibboleth Developers

["Howard Gilbert" <>]

> I have a question though, are you saying that we wouldn't special-case the
> embedded key option? The advantage there is bypassing certificate baggage
> entirely, as well as not even having to include the certificates in signed
> messages in some cases.

You don't validate a Certificate that doesn't exist. If there is a Raw Key,
I guess you just try it and see if it works. I don't think there is a
question if there is a ds:KeyInfo at the Role level that contains a Key.
This raises three questions:

It has been proposed that Security administration only really works at the
Entity level even if the Metadata defines KeyDescriptor as an element of
Role. So do we aggregate all the Keys at the Entity level and, therefore,
accept a Key that is configured for a different Role than the one that
actually presents it.

Having a bunch of alternatives isn't a problem if the Signature includes a
KeyInfo that selects one of them. It doesn't have to, and even if it does
include one do we really want to only try that one option. I think it is
simpler if we try to validate the signature with every Private Key we have
for the Entity, whether configured as a Raw Key or extracted from a
Certificate. Then if none of the keys validate, and if the Signature
contains a KeyInfo with a Certificate that is not in the Metadata, try to
validate that Certificate against the Entity-based validation CA set and if
it validates, use its Private Key.

Can the EntityDescriptor and EntitiesDescriptor Metadata Extensions (yet to
be defined) have KeyInfo elements with Raw Keys, or is this only meaningful
for CA Certificates?

> Intuitively, I guess I would expect to leave out Certificates found inside
> actual KeyDescriptors from this process, and use those first by extracting
> just the public key. The validation option would be secondary if that
> fails
> or no keys are present.

Certainly Certificates present in the Metadata don't have to be validated
against anything. In the algorithm listed above, they aren't regarded as
Certificates, just as Public Key envelopes.


> PS. This still sidesteps the real question...is it worth it? Bob clearly
> thinks so. Walter thinks not, Jim knows he doesn't need it (as do I). Who
> does? Shouldn't somebody actually want this?

I think this is a definitional problem. 

Some people (but maybe none of us) believe that PKI is still possible.

I believe that PKI doesn't work, but that X509Certificate data objects are
useful if you look at them free from the usual PKI assumptions

Some believe that Certificates are hopelessly encumbered with traditional
PKI assumptions and you need a clean break back to Raw Keys. Except maybe
SSL where you can't break entirely clean. And then there is the fact that
ds:KeyInfo supports them, so if you get one in a Signature you have to deal.

If we could break clean I might be tempted to do it. Since we can't, I feel
we have to give Certs the best support we can. You get lemons, you make
lemonade. Personally, I would rather have a Sam Adams, but they didn't ask
me.