Federation: Trust chain resolution: Require the signing JWK to be present in the superior statement's JWK set about the entity

[Vladimir Dzhuvinov]

To prevent entity impersonation attacks in case the DNS or the TLS gets compromised, but also to ensure that intermediates and trust anchors actually vouch for the entities' jwks under their authority.

At each step in the trust chain resolution it must be verified that the signing JWK is also present in the jwks statement claim issued by the superior. The check can be performed by making sure the signing JWK thumbprint (RFC 7638, see https://tools.ietf.org/html/rfc7638) matches the thumbprint of a JWK in the superior’s statement jwks . Entities must also make sure to sign statements with a JWK which is already registered with its upstream authorities.

Sample Java code:

https://bitbucket.org/connect2id/oauth-2.0-sdk-with-openid-connect-extensions/src/368d830e49f0f0a30cee7ae80c6bedcdb8ebfa49/src/main/java/com/nimbusds/openid/connect/sdk/federation/trust/TrustChain.java#lines-340

‌

In the absence of this check the security of the trust chain resolution will depend entirely on the security of the DNS. Having the client preconfigured with the trust anchor jwks (instead of obtaining it dynamically) can prevent impersonation on DNS compromise in minimal “trust anchor → leaf” chains, but not for chains with intermediates “trust anchor → intermediate → leaf”.

[Roland Hedberg]

I’ve always taken this for granted. I’ll check the wording in the draft and if not explicit enough will add some text on the matter.

[Roland Hedberg]

There is actually text on this in section 7.1 .

[Roland Hedberg]

Added more explicit language.