Metadata requireSignedMetadata=false Behavior

[Brent Putman]

On 6/8/15 10:18 AM, Nate Klingenstein wrote:
>
>
>> A trust engine can do anything is the point, and you could chain
>> trust engines together with multiple keys if you really didn't care
>> who signed what (which itself is a problem, so that's the main reason
>> edugain really doesn't work like that).
>

Right, the new (in v3) ability to specify a single key/cert on the
filter is really just a convenience, since it's the 99% case probably. 
If you want to do advanced things, you do a full trust engine like in v2.

You could have either multiple engines in a chain, or more likely a
single engine with multiple trusted credentials.


> I was more interested in the ability to associate providers with
> authorities, maybe through an entity tag, the registrar tag, or even a
> dumb regex match on the entityID than the ability for anyone to sign
> anything -- see browser CA's.
>

Just thinking out loud:  We could in theory support something like a
Function<XMLObject, Set<String>> on the filter, allowing one to map
which trusted credentials' managed by an explicit key trust engine were
resolved by the underlying credential resolver, and therefore acceptable
for validating a particular signature. I could imagine it being
configured via one or more a Map<String,String>.  E.g. Key A is valid
for entityIDs  X, Y, Z; key B is valid for EntitiesDescriptors with
@name of D, E, F, etc.  If we really want to go there...  Also heinous
for deployers, I'm sure.  A model where an aggregator/publisher resigns
what it publishes with a single key is probably much more tenable. 

We already did something similar for dynamically constructing the set of
PKIX trusted names used in validating the signing cert with the PKIX
engines.  Btw, that is the other way to go here for this kind of thing: 
PKIX trust anchors (perhaps just 1) that issue signing certs to the
parties who then self-sign their own metadata; similar to the above, the
trust is based on mapping expected names from the signed thingies to the
name(s) in the cert.  E.g. you trust the signing cert for
EntityDescriptor with entityID X because it's chained to a trusted root
and the cert contains the entityID X as a CN or alt name.  That's
supported today.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://shibboleth.net/pipermail/users/attachments/20150608/05b5216e/attachment-0001.html>