Attack identified against self-issued "sub" values

[Michael Jones]

James Manger identified an attack against self-issued "sub" values in the OpenID Security mailing list thread http://lists.openid.net/pipermail/openid-security/2014-February/001251.html.

The gist of the issue is that parts of the JWK are concatenated together without a separator, as described at http://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedResponse, 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 || '"}'))

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

[Michael Jones]

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.

[Michael Jones]

Fixed #920 - Attack identified against self-issued "sub" values

→ <<cset 5f18078dc742>>