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