IdP metadata based on multiple signing certificates

[Dennis Wagelaar]

-----Original Message-----
From: users-bounces at shibboleth.net [mailto:users-bounces at shibboleth.net] On Behalf Of Cantor, Scott
Sent: maandag 13 augustus 2012 19:08
To: Shib Users
Subject: RE: IdP metadata based on multiple signing certificates

> At the URL below, I've read about using multiple signing certificates 
> as part of the IdP metadata:

I don't know what that has to do with the multiple certificate question. It should document what that means, but it means more or less the same thing it means for the other trust engine we have.

> Is this usable in a situation where a "personal" IdP is used on a 
> local machine, which uses an X.509 certificate signed by a single root 
> certificate? This means many "dynamic" IdP certificates from the point 
> of view of the SP, as there will be many such "personal" IdPs, all of which must be trusted by the SP.

I think you're saying that the IdP(s) will be using a boatload of different certificates that all come and go randomly but have a common trust anchor. It is certainly the case that doing that with the PKIX engine is more likely to work, but only if you have a lot of complex certificate naming issues worked out. Something's got to be in the metadata to identify the credential, be it a name in the PKIX case, or the key on the more recommended case. So in the end it usually ends up that you're better off avoiding PKIX. It never solves the problem you think it does except by creating security behaviors that are hard to understand.

-- Scott

Thanks for the answer! It is clear that there's (much) more to it than just having the certificates signed by a single root cert. There's also the issue of compromised private keys on the "personal" IdP; anyone who can gain access to the PC with the IdP on it, can get to the key. Having multiple IdP certificates is a start, but certainly does not solve the problem by itself...

Dennis