RE: [security-services] Trust management and validation via metadata

["Scott Cantor" <cantor.2@osu.edu>]

> Fundamentally, I don't think that a metadata object signed by an entity
> can be(come) authoritative to specify a trust path that a verifier should
> accept for that entity.

That's not the use case. Entities don't self-sign their own metadata, they
get it signed by what amounts to the real trust root of the entire system,
the metadata signer (i.e. the "federation").

So this all just amounts to turning that key into the real root CA, but then
fooling traditional PKI software into relying on the trust roots vouched for
by that key.

> It can provide useful hints, and could even carry
> certificates that comprise elements of that trust path, but validation
> will still need to be performed relative to a policy and trusted root(s)
> that the verifier obtains through other sources.  The trust file Scott
> describes seems to represent a means to disseminate that sort of policy
> information.  I think it could be useful for entity-supplied metadata to
> be able to conveniently carry, name, or hint at information that a
> validator might use to confirm the entity's trustworthiness, but don't
> think this can replace the need for independent configuration of the
> data and policies that a validator will apply.  

Entities may "supply" their metadata, in some sense, but they don't have to
sign it themselves. In practice, we're not seeing the use case so far for
really pulling the trust metadata from the entities directly, because the
trust model for that would require us to exchange keys out of band of even
this mechanism. It's turtles all the way down, we had to stop somewhere.

Once you have to get your changes signed centrally, you may as well
distribute it that way.

-- Scott