[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [security-services] Trust management and validationviametadata
>The point is to communicate a trust list in metadata. A KeyDescriptor inside
>a role doesn't naturally have the ability to do this.
Ok, I understand now. This almost seems like a problem with the XMLSignature spec and not something we would define.
>>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
>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.
I agree that SSL is the usual use case for using x509 certificate chains - this being one type of indirect trust. x509 cert chains are not limited to just this. The "Trust Models Guidelines" specifies two types of trust, "Business Agreements" and "Authentication". I took the authentication trust to mean SSL/PKI as you described it. If I wanted indirect trust for the "business agreements" trust I could also use PKI/x509 certificate chains to establish this trust.
In fact, if I were to implement indirect trust, I would use PKI/x509 simply because I have those tools built here in house (or via OpenSSL). I have avoided the indirect trust because of the administration issue I mentioned before: Even if the authentication trust and business trust were established indirectly, the administrator still has to manually create configuration for each entity - why not just establish direct trust?
(I could only come up with one use case against this thinking: A CA that revokes and reissues certificates on a regular basis)