OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[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]