Deprecated algorithm RSA1_5 used in spec examples and self-issued

[Michael Jones]

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.

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

[Michael Jones]

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.

[Brian Campbell]

FWIW, I believe the prevailing thinking is that it's really not safe to sign and encrypt with the same RSA key. http://www.internetsociety.org/doc/one-bad-apple-backwards-compatibility-attacks-state-art-cryptography for example, talks about weaknesses in RSA 1.5 encryption ultimately being used to forge signatures when the same key is used for both.

[Michael Jones]

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.

[Michael Jones]

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!

[Nat Sakimura]

Need a concrete proposal.

[Michael Jones]

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.

[Michael Jones]

In the interest of finishing the errata soon to enable PAS submission, I’m prone at this point to apply the Self-Issued action but not change the examples, as it would require re-generating all the encrypted content. I’m going to proceed in that manner unless objections are raised.

I would also add a note saying that RSA1_5 has been deprecated and recommending that a current encryption algorithm be used.

[Michael Jones]

Will be fixed by https://bitbucket.org/openid/connect/pull-requests/567

[Michael Jones]

Fixed by https://bitbucket.org/openid/connect/pull-requests/567