[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Trust management and validation via metadata
As I mentioned on the last call, our project is looking hard at consolidating some of our older work in trust management around the new metadata schema (initially for SAML 1.x, but eventually 2.0 as well) and the basic problem we have is the lack of any place to communicate not just keys but key authorities. CAs if you will. There's a quite a bit of text on this subject here: https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/TrustManagement But in a nutshell, we plan to continue supporting a model where instead of distributing actual public keys in the metadata, we use a more traditional PKI in which we distribute the names of certificates that can be used along with the allowed certificate authorities. We do this today at the federation level, by using our own CA to issue InCommon certificates to participating providers and distributing our own trust file format that, loosely translated, says "Providers in the InCommon federation must use certificates issued by the InCommon CA", where the actual CA is in the file. The metadata than contains only the key names that particular providers can use, and then the certificate is validated at runtime in the usual PKIX (or something close) manner. Now, there is no ds:KeyInfo child element that means "CA". The closest is the IssuerName/SerialNumber combo, and that's not the same thing since it still bumps the actual CA cert to some OOB exchange. So what I was asking on the call is, is anybody else doing this, and is there any interest in developing an extension element that would contain ds:KeyInfo data that was specifically defined to be authorities for keys issued to providers within the containing element. It would be something usable at the role, entity, or entities level. Example: https://authdev.it.ohio-state.edu/twiki/bin/view/Shibboleth/MetadataExtensio ns Alternatively, what am I missing? Nobody uses any traditional PKI for this sort of stuff? I can believe that. -- Scott
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]