[Openid-specs-ab] OpenID Connect Federation draft 09 ready for your review

Roland Hedberg roland at catalogix.se
Fri Nov 1 14:28:42 UTC 2019

Hi !

> 1 nov. 2019 kl. 13:42 skrev Marcos Sanz via Openid-specs-ab <openid-specs-ab at lists.openid.net>:
> Hi again,
> Marcos Sanz/Denic wrote on 29/10/2019 16:43:31:
>> - Section 7.1: It says "Once the Consumer has found a trust anchor it 
> wants to use, it MUST complete the trust chain by fetching 
>> the trust anchor's self-signed entity statement" This sentence is in 
> contradiction with other parts of the spec: Section 2.2 
>> clearly states that the trust chain "ends with an entity statement 
> issued by the trust anchor about the top-most intermediate 
>> [...] or the leaf entity [...]", and it does thus exclude from the chain 
> the (certainly most probably existing) trust anchor's 
>> self-signed entity statement. Verification algorithm of 2.2 ignores the 
> TA self-singed ES, so does Appendix A.1.7.
> [...]
>> - Section 7.2: The chain validation algorithm in 7.2 is broken. It looks 
> like it considers the TA self-signed statement to be part
>> of the chain (cf "for j=0,i verify that iss==sub"), but if that's the 
> case, you'll easily see by setting i=1 (no intermediaries, 
>> just one leaf and a TA) that you only perform 2 signature verifications 
> instead of the 3 that'd be needed (self-signed leaf ES, TA
>> about leaf ES, self-signed TA ES).
> [...]
>> - Section 8.2: "A trust anchor must publish a self-signed entity 
> statement about itself. As described above in Section 2.2, it 
>> should be at the end of the trust chain". Section 2.2 says actually the 
> opposite, see further up.
> I've been thinking about this conglomerate of issues and it'd be actually 
> easier if the TA self-signed statement were *not* part of the chain: the 
> Consumer should be configured with the TA's name (the issuer URI) and TA 
> public key, and it could stop walking up the chain once it finds an ES 
> whose iss and signature match these two configured values.

When how to get self-signed information became different from how to 
get information about an entity from another entity then the TA's self-signed
statement was removed from the trust chain. This may not have been spelled out 
clearly enough.

> This is 
> actually also what X509 certificate path validation (RFC 5280, section 6) 
> does. Potential additional information for processing (like 
> max_path_length or naming constraints) could be included by the TA in the 
> metadata of the TA-issued ES for the topmost intermediate (or for a leaf).
> The second thing, which is less of a recommendation but more a question on 
> how to deal with this in the JWT trust chain, is the good practice of 
> validating 'iss' in JWTs (s. for instance the "MUST" wording in 
> https://tools.ietf.org/html/draft-ietf-oauth-jwt-bcp-07#section-3.8). That 
> soon-to-become-RFC showcases OIDC doing this via the jwks_uri mechanism to 
> dynamically dig issuer public keys for verification. However, we don't 
> resort to that mechanism at all in the Federations spec: the chain 
> validator has to blindly believe the keys in the jwks element of the upper 
> chain link. So it's unclear to me whether this key-to-issuer-binding is 
> being neglected at the moment in our trust chain.

Well, it all starts with the TA. If you don’t trust the TA then you’re smoked.
The Federation spec hinges on the fact that you do trust the TA.

> Finally, and talking about the jwks element: the Federations spec says 
> "keys that can be found here are primarily intended to sign entity 
> statements and should not be used in other protocols". While reading that 
> I was reminded of the aforementioned JWT-BCP's recommendation "Use 
> different keys for different kinds of JWTs. Then the keys used to validate 
> one kind of JWT will fail to validate other kind of JWTs", which is good. 
> And then I realized that Federations is not using explicit JWT typing, 
> though it is RECOMMENDED for new uses of JWTs (and Entity Statements are 
> such). So I think we're still in time to include that.

Good idea!


It is impossible to enjoy idling thoroughly unless one has plenty of work to do. There is no fun in doing nothing when you have nothing to do. Wasting time is merely an occupation then, and a most exhausting one. Idleness, like kisses, to be sweet must be stolen. -Jerome K. Jerome, humorist and playwright (2 May 1859-1927)

More information about the Openid-specs-ab mailing list