Shibboleth Developers

["Scott Cantor" <>]

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

No, definitely not, anymore than I currently allow an AA to use a key named
"foo" because there'a a HandleService element with that Name.

The actual trust processing is role-based, and that's why my APIs into
various code blocks pass in Role interfaces, and not an (I)EntityDescriptor.
Sometimes a specific role, but usually just anything, since I can get the
KeyDescriptor information from the base interface.

Of course, it walks up the tree back to the entity from there when it needs
to, and I don't have any objection to defining the Extension element at only
higher levels, but this is why I said it doesn't really matter, it would be
trivial for me to let roles include the extension anyway.

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

Ok, that's what I originally assumed, given that you mean public key there,
not private. (I generally verify the message first, since it's cheaper than
the path walk, which is potentially multiple signature operations.)

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

Historically, I only allowed certificates. Mostly because the implementation
wouldn't have worked, being based on path validation (touche). Having
overridden it, it's not inconceivable to implement a case in which raw keys
would work, but I don't think there's much of a use case for it.

It's part of a broader question of what ds:KeyInfo elements to support and
where.

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

Right. Your note previous to this just had a small bit that made me ask.

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

Well, this is self-imposed. When we mentioned this topic on the SAML call
today, I had to explain what I was even talking about, and there's likely to
be little interest in it. That said, I don't know how their products do SSL.
It's not easy to define what is meant by a well-known key in that case. We
can do it, but it's a made-up concept. So I kind of think they handle it
separately from all this and probably just do the simple thing, stick in
some roots, and let the SSL library have its fun. That would be nice, except
that it's completely insane to do signing one way and TLS another. I'm
asking one vendor I'm on good terms with, maybe I can get some insight.

So we're the oddballs and none of us seem too keen on this, so again, this
is a lot of work for no apparent audience.

-- Scott