[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Trust management and validation viametadata
> I suppose I don't understand what is broken / what we need to > fix. Why does the KeyInfo need to reference the root CA? I I'm not saying it does. I don't seem to be explaining this, but then I'm not a huge fan of this use case myself because I think it's confusing for deployers, but let me try further. What you proposed in the other note is interesting, but somewhat distinct/orthogonal to this. The point is to communicate a trust list in metadata. A KeyDescriptor inside a role doesn't naturally have the ability to do this. > just assumed that if someone wanted indirect trust they would > always use a X509 certificate-chain (containing the root CA > and any subordinate CA info). So is the problem when X509 is > not used? No, that's not indirect trust. Say I send you such a chain in metadata. That's nice, but why bother? The metadata signer is basically saying the EE cert in the chain is your key, so what does the chain add? Nothing. The point is to sign/vouch for *only* the CA. Then the metadata contains that (somehow) and a KeyName in the role. The relying party is then validating the EE cert it gets later against the name and against the trust list that it receives in the metadata. That's your standard SSL type use case in the PKI world, you know the "name" of the EE credential, and your trust list establishes the trust. The issue here is communicating/signing such a trust list, and not leaving it to OOB configuration. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]