[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Trust management and validation via metadata
> 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]