shibboleth-dev - Re: client certificate chains and 1.3 IdP
Subject: Shibboleth Developers
List archive
- From: Walter Hoehn <>
- To: Ian Young <>
- Cc: Scott Cantor <>,
- Subject: Re: client certificate chains and 1.3 IdP
- Date: Wed, 6 Jul 2005 10:40:23 -0500
On Jul 6, 2005, at 10:05 AM, Ian Young wrote:
Scott Cantor wrote:
In practice, chains are dumb. The PKIX code doesn't care if the anchor is
self-signed. So you can trust the issuer directly, and I don't see why
anybody wouldn't be able to live with that. But fixing it doesn't really
seem possible in any other way.
I've now tested that in our case, adding the intermediates in question to the EntitiesDescriptor /Extensions /KeyAuthority list allows the IdP to validate the "path". I imagine, though, that it is not validating the whole path to the self-signed root but only to the immediate signer of the end certificate; do you agree? Is there a way to confirm this with the current codebase?
I've tried it, but it wouldn't hurt to have a jUnit test.
I think you're right, that we should be able to live with this, particularly if the alternative is holding our breath until someone fixes AJP... I'm assuming that adding intermediates to the KeyAuthority list won't cause trouble for 1.2 entities; do you know of any issues that might come up there?
The IdP doesn't do validation in 1.2. It is handled completely by mod_ssl. The 1.2 SP should work just fine with the intermediates in the metadata as long as the included chain goes all the way up to the root.
Final question: I'm interested to hear that the code doesn't care if the anchor is self-signed, as I thought that OpenSSL (as used by the C++ SP?) had just such a limitation? That implies to me that we need to keep the whole chain of intermediates in the metadata even if it shouldn't strictly be required (the chain I'm looking at is strictly A->B->C->client with no branching, so A and B are superfluous unless a self-signed root is required by someone).
The IdP trust module definitely allows anchoring with non-self-signed certificates. This is correct behavior according to PKIX. I believe that Scott worked around the OpenSSL limitations in 1.3 so that both code-based behave the same, but I'll let him confirm that.
-Walter
- client certificate chains and 1.3 IdP, Ian Young, 07/05/2005
- RE: client certificate chains and 1.3 IdP, Scott Cantor, 07/05/2005
- RE: client certificate chains and 1.3 IdP, Scott Cantor, 07/05/2005
- RE: client certificate chains and 1.3 IdP, Scott Cantor, 07/05/2005
- RE: client certificate chains and 1.3 IdP, Scott Cantor, 07/06/2005
- RE: client certificate chains and 1.3 IdP, Scott Cantor, 07/06/2005
- Re: client certificate chains and 1.3 IdP, Ian Young, 07/06/2005
- Re: client certificate chains and 1.3 IdP, Walter Hoehn, 07/06/2005
- Re: client certificate chains and 1.3 IdP, Ian Young, 07/06/2005
- RE: client certificate chains and 1.3 IdP, Scott Cantor, 07/06/2005
- Re: client certificate chains and 1.3 IdP, Ian Young, 07/06/2005
- RE: client certificate chains and 1.3 IdP, Scott Cantor, 07/06/2005
- RE: client certificate chains and 1.3 IdP, Thomas Lenggenhager, 07/07/2005
- Re: client certificate chains and 1.3 IdP, Ian Young, 07/06/2005
- RE: client certificate chains and 1.3 IdP, Scott Cantor, 07/06/2005
- Re: client certificate chains and 1.3 IdP, Ian Young, 07/06/2005
- RE: client certificate chains and 1.3 IdP, Scott Cantor, 07/06/2005
- Re: client certificate chains and 1.3 IdP, Walter Hoehn, 07/06/2005
Archive powered by MHonArc 2.6.16.