Attack identified against self-issued "sub" values

Issue #920 resolved
Michael Jones created an issue

James Manger identified an attack against self-issued "sub" values in the OpenID Security mailing list thread

The gist of the issue is that parts of the JWK are concatenated together without a separator, as described at, meaning that an attacker might be able to shift content between the key parts, resulting in the same "sub" value with different keys.

I propose that we change the computation of the self-issued "sub" value to use an agreed-upon legal JWK representation of the key as the value to be hashed. So, for instance, for an RSA key the "sub" value would be: BASE64URL(SHA-256('{"kty":"' || sub_jwk.kty || '","n":"' || sub_jwk.n || '","e":"' || sub_jwk.e || '"}')) and the "sub" for an EC key would be: BASE64URL(SHA-256('{"kty":"' || sub_jwk.kty || '","crv":"' || sub_jwk.crv || '","x":"' || sub_jwk.x || '","y":"' || sub_jwk.y || '"}'))

Comments (3)

  1. John Bradley

    For self issued IdP producing RSA keys, I think we should also recommend the value of e be 65537 for interoperability and security.

  2. Michael Jones reporter

    Mike will publish a mini-spec about JWK public key thumbprint values. It will order the member names alphabetically and limit the member names to ASCII characters.

  3. Log in to comment