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

[Marcos Sanz]

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. 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.

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.

Best,
Marcos