RS256 vs PS256 (again)

[Joseph Heenan]

We've discussed this before ( https://bitbucket.org/openid/fapi/issues/101/jws-signature-algorithms-for-rw ). There still seems to be notable industry pushback so it may be worth further thought.

The Australians are considering using RS256:

https://github.com/ConsumerDataStandardsAustralia/infosec/issues/35

OpenBanking UK still has waivers in place that allow RS256:

https://openbanking.atlassian.net/wiki/spaces/DZ/pages/72287278/Waivers

This seems to be the most contentious and most disregarded part of FAPI. I think we should probably consider at least providing extra explanation of the rational and possible mitigations. It may also be worth explicitly saying to definitely not use RS256 for encryption, but that perhaps for signing the language should be a little weaker?

As I understand the rational, it's that:

1) RS256 has definite issues for encryption (e.g. https://cryptosense.com/blog/why-pkcs1v1-5-encryption-should-be-put-out-of-our-misery/ )

2) PS256 has formal security proofs, RS256 doesn't.

(It's not my area of expertise though.)

I believe the major argument against PS256 is that for many languages it is not supported out of the box by commonly used libraries - e.g. https://jwt.io doesn't even show which libraries do/don't support PS256.

[Brian Campbell]

Also discussed some in this thread http://lists.openid.net/pipermail/openid-specs-fapi/2017-July/000481.html FWIW

[Brian Campbell]

Note that RS256 is a signature algorithm not encryption (though encryption primitives are used in the signature process it's still not really encryption)

[Dave Tonge]

I agree with adding more text, we tried to previously but didn't come up with anything suitable.

Perhaps FAPI can maintain a list of libraries that support PS256? I think most platforms now have libraries that support it.

We are also pushing implementers to use a certified OP and certified RP implementation, I assume that PS256 compatibility is tested in the conformance suite?

[Joseph Heenan]

John suggested that another argument is that disallowing PSS for signing may help discouraging people from using it for encryption.

On Dave's point; thanks to Auth0 https://jwt.io/ now lists which libraries support PS256, although there are currently some libraries where it is listed as unknown, if anyone can assist with filling out the unknowns that'd be great (or adding support to libraries that don't support it).

Dave also shared on today's call that Australia are looking more likely to use PS256, so that helps ease my worries.

John raised an additional point that some guidance about how ecosystems should migrate from RS256 to PS256 could be helpful.

OB UK are going to publish guidance on their migration (scheduled for March) but it is likely to involve coordinated hard switchover dates.

[Dave Tonge]

I've raised this issue on the Connect issue tracker: https://bitbucket.org/openid/connect/issues/1063/guidance-around-algorithm-migration

[Joseph Heenan]

We’re another 6 months on now. I feel like we’re at the point where PS256 is widely enough implemented that we shouldn’t make changes to FAPI. The OBUK waivers that allowed RS256 to be used expired 3 months ago (13th March 2019) and I’ve not heard anyone in the UK complaining about PS256 being an issue. Where information is available on PS256 on https://openbanking.atlassian.net/wiki/spaces/DZ/pages/1010074155/ASPSP+Calendar is appears to indicate the overwhelming majority of banks already fully support PS256 or plan to do so shortly.

Payments New Zealand were apparently considering allowing RS256, but I explained much of the above and I hope they’re now going to go straight to PS256, which means they then wouldn’t run into migration issues.

Does anyone object to closing this issue?

[Dave Tonge]

Sounds good to me

[Stuart Low]

[Edit, remove confusing comment]
It might be a typo but while it’s generally understood that Australia is using PS256 there is no explicit statement in the Standards and the configuration endpoint information (https://consumerdatastandardsaustralia.github.io/standards/#end-points) suggests ES256 can be supported too.

[Nat Sakimura]

Add security considerations.

[Dave Tonge]

I think we should close this issue

[Dave Tonge]

Closing as no activity