Deprecated algorithm RSA1_5 used in spec examples and self-issued

Issue #974 open
Michael Jones created an issue

The RSAES-PKCS1-v1_5 algorithm ("RSA1_5") was removed from the W3C WebCrypto API because of known security vulnerabilities with it. We use it in our examples in Discovery and Registration. I'd propose that we change those examples to RSAES OAEP ("RSA-OAEP"), which is also reasonably widely supported, including by WebCrypto, and doesn't have those security problems.

A bigger concern is that we say in the self-issued description "Encrypting content to Self-Issued OPs is currently only supported when the OP's JWK key type is "RSA" and the encryption algorithm used is "RSA1_5". We should discuss what, if anything, to do about this and whether what we do is an errata action or whether it would be part of a 1.1 spec.

Comments (8)

  1. Nat Sakimura

    For the Self-issued, it may be better to move to EC instead of RSA-OAEP now, though it sounds like more change than errata as you need different keys for sign and encrypt.

    Section 7.3 Request needs to be clarified as to from where it should get the key.

    Last sentence of 7.3:request is problematic as well. It should have a reference to 7.4.

  2. Michael Jones reporter

    For the non-normative examples, did the working group discuss whether to change to RSA-OAEP on the call? This seems like an obvious thing to do and is also fine to do, since it's not a normative change.

    Changing self-issued encryption is more complicated. Just as we justified changing the key thumbprint algorithm in errata1 as a security-related change, we could justify changing to OAEP for the same reason.

    However, adding EC encryption is a much bigger deal - in part, because we would have to introduce a second key. We took advantage of the fact that it's safe to both sign and encrypt with the same RSA key but that trick doesn't work for EC. So if we add this, it would have to be part of a 1.1 spec.

  3. Michael Jones reporter

    Thanks for the reference. Great paper!

    Section 4.3 - The Power of Bleichenbacher’s Attack makes it clear to me that we have to do something about using the same key with RSA1_5 and RS256, because it enables an attack on both. The minimum change we could make would be to replace the use of RSA1_5 with RSA-OAEP - eliminating the preconditions for this attack.

  4. Michael Jones reporter

    Mike suggests that we're probably better off deprecating singing and encrypting with the same key. John says that encrypting to the client is an edge case. You can only do this upon the second interaction with the provider!

  5. Michael Jones reporter

    I propose that we change all uses of RSA1_5 in examples to RSA-OAEP. I also propose that we replace the language about using RSA1_5 to encrypt to self-issued OPs with the statement "Encrypting content to Self-Issued OPs is not currently supported". (This would replace then language "If the ID Token is encrypted to the Self-Issued OP, the sub (subject) of the signed ID Token MUST be sent as the kid (Key ID) of the JWE. Encrypting content to Self-Issued OPs is currently only supported when the OP's JWK key type is RSA and the encryption algorithm used is RSA1_5. ".) This change would apply to both the descriptions of "id_token_hint" and "request" in http://openid.net/specs/openid-connect-core-1_0.html#SelfIssuedRequest.

  6. Log in to comment