[Federation] FAPI prohibits RS256

[Takahiko Kawasaki]

The OIDC Federation specification requires that entities support RS256 as a signing algorithm for entity statements. However, Section 8.6. Algorithm considerations of FAPI 1 Advanced prohibits the algorithm for security reasons. It is better to modify descriptions about RS256 in the OIDC Federation specification so that the specification can be used with FAPI without conflicts.

History: Section 3.1 of RFC 7518 (JWA) (published in 2015) recommends RS256 and some descriptions of client metadata in OIDC Dynamic Client Registartion 1.0 (published in 2014) refer to RS256 as the default algorithm or should-support algorithm. However, the algorithm lacks forward secrecy, so the algorithm is not recommended these days. TLS 1.3 has removed algorithms that lack forward secrecy.

[Michael Jones]

There’s a few different things we could do here.

1. We could leave the spec as-is, which is aligned with OpenID Connect Core, which also mandates RS256.
2. We could mandate support for both ES256 and RS256.
3. We could leave mandatory-to-implement algorithms up to individual federations. We do have policy statements with which they could express these algorithm requirements.
4. A refinement of the above is still leaving it up to Federations, but suggesting that they require either ES256 or RS256 or both.
5. We could require support for ES256 and say that RS256 MAY be supported, but is depreciated. Note that this would be incompatible with OpenID Connect Core.

I’m sure there are other possibilities as well. Thanks for bringing this up, Taka!

‌

[Giuseppe De Marco]

On the basis of how a leaf signs its EC, it should be known which signature algs it uses.

In a mixed approach different participants may sign their statements differently and the statements that compose a chain may be signed with different algs, it’s up to the trust verifier dealing with all these (and supporting all these). We know that many federations may support different algs and that a leaf may join to more than a single federation.

To allow the extendibility of the Federation implementations during the time I agree that a TA MAY force the signature alg to be adopted by descendants BUT at the same time multiple TAs, from multiple Federations, may require different signature algs. The leafs don’t know how they should sign their EC because the EC must work for many federations.

So, I’d be for force the support for the legacy algs like RS256 (to establish in the specs the basis of the minimum requirement for interoperability) and also enable the mixed approach.

So we may say that all the participants MUST support RS256 for legacy support and, if the federation permits, they SHOULD support also ES and P. But the problem remains until we say that the following algs MUST be supported by all the participants:

RS256 and superiors (384, 512)
ES256 and superiors (384, 512)
PS256 and superiors (384, 512)

if we have this asset then it would be up to the participants establish their level of security with the signatures issued by themself, but at the same time the participant with the highest level of security will force the other participants to adapt and support it. Once we got its EC we know if we’re able to deal with it or not

[David W Chadwick]

I think Mike’s second option broadens the scope for interoperability.

[Brian Campbell]

Just for posterity, message signatures and forward secrecy are really distinct concepts. A signature by itself cannot provide forward secrecy. It shouldn’t be a consideration in this issue.

‌

[Giuseppe De Marco]

yes, option 2 seems the simplest one

[Michael Jones]

On the 21-Oct-22 Federation Editors' call, we agreed to use language along the lines of “Implementations SHOULD support signature verification with RS256 because OpenID Connect Core requires support for RS256; Federations MAY also specify different mandatory-to-implement algorithms.”

[Giuseppe De Marco]

The PR below aims to close this issue
https://bitbucket.org/openid/connect/pull-requests/349

[Michael Jones]

Addressed by https://bitbucket.org/openid/connect/pull-requests/349