Entity statement signing algorithm

[rohe]

In the spec it is stated about entity statements (in Section 3) :

"Implementations SHOULD support signature verification with the RSA SHA-256 algorithm because OpenID Connect Core requires support for it (alg value of RS256). Federations MAY also specify different mandatory-to-implement algorithms."

This implies that the federation should be able in some way to publish which algorithm that should be used for signing entity statements within the federation.
How this could be done is not discussed in the spec. I think it should be.

I'd also like to propose that the TA should publish which signing algorithm the federation should use together with the its public keys. This would allow the federation to move from one algorithm to another under controlled circumstances.
I make the assumption here that all entities within the federation MUST used the same algorithm.

[Razumain]

I'm afraid that this easily becomes over engineering.

One of the core problems here is that there is no single federation any more. And that's one of the great things about this specification. There is a mesh of services chaining to a superior entity that may chain to many Trust Anchors. Each Trust Anchor defines a unique federation context, but they have no exclusive power over subordinate entities.

Making the TA decide signing algorithms for subordinate entities can become tricky, in particular if two Trust Anchors who have common subordinate entities down their paths define incompatible rules.

In this case I would say that we should expand the list of MUST support algorithms to at least include ECDSA using named curves. That is trivial to support today for all implementers.

If a federation entity decides to use a non commonly supported algorithm, that will create problems. But perhaps we should let it create problems for the involved parties to sort out. If not sorted, that path will not be valid. Fair enough. Parties will probably sort that out by selecting an algorithm that others can handle, or exist in a local context where they don't care.

[rohe]

So maybe we should have entity_statement_sign_algs_supported ?
The TA should definitely be allowed to specify what signing algs it supports.

[zachmann]

I also think that mandating a single algorithm is not a good idea, but having a list where one_of these must be used is certainly the better approach.

[Razumain]

A federation entity metadata parameter could be useful in line with your proposal Roland. I suppose that is what you meant, or did you consider an Entity Statement claim?

[vdzhuvinov]

Should Federation end up sticking around for at least as many years as X.509 has (35+ years), it's reasonable to expect that within its lifetime PQC will come knocking on our door. Suppose it's the year 2034 and we need to start switching our Federations to a new JWS alg, say over a period of one year. How could this work in practice?

[Razumain]

Vladimir, I recall all lengthy debates regarding this in the IETF if various protocols.

In the end what matters is that you can declare what you use, and in case of store and forward protocols, you can see what a peer entity can parse or understand.

We can't foresee the future here and the culture of using different algorithms will change over time.

The case here is that we are neither a store and forward protocol between peer entities, nor an on-line protocol. We have services publishing information to anyone that wants it, often without knowing who the recipient are, or its capabilities.

This is in practice often a self-regulating use-case where parties use trial and error that meets the current culture. You tend to choose an algorithm that you know most implementations can tolerate.

I still think the best solution here is to put most of the responsibility on the entities implementing this to choose what makes sense for the environment they work in. To display your capabilities is fine, but I doubt that any implementation will use that as an active source of information to select their signing algorithm.

[Razumain]

I do think however that we all benefit from shorter data and faster algorithms, In particular if the number of entities becomes very large. This is why I think EC algorithms (with named curves) should be mandatory to support (for verification). I would be super surprised if this is not a requirement that is already met by all implementations. But we agree that this is a snapshot in time that likely will be updated in the future. So we should say something about that as well.

[selfissued]

I agree that we need to address this, especially in light of the potential switch to post-quantum cryptography.

[Razumain]

I just reviewed this, and I have to admit that I'm very confused.

I try to picture how this is used in practice. Who reads this metadata parameter and what do they do with this information. I can make no sense of it.

First of all, the metadata parameter is defined as the algorithm to "sign". And from Rolands original post, I thought this was about the algorithms you support to verify. Signing algorithm is already declared in the JWT header.

Second, a default to RS256 seems wrong, whether it is for sign algorithm or supported verify algorithms. Absence of this metadata parameter should not be treated as a limitation to support only RSA.

Regardless of whether this is for sign or verify capabilities, can someone explain how this will be used to automatically promote future transitions to other algorithms, or use of ES?

P.S. I think mandatory support of ES signatures is the most important task here. Just because OpenID Connect has RS256 as the only mandatory support algo, does not mean that OpenID Federation has to. There is a big difference here. An instance of OpenID Connect exchange is a 2 party exchange negotiated through metadata. OpenID federation Entity Statements is a publication of data that may be consumed by multiple entities with no prior negotiation.

[vdzhuvinov]

+1 that this first PR is not sufficient to address the issue.

For instance, in the case when more that one JWS alg is supported, some kind of a mechanism will be needed to be able to request a particular JWS alg. Something like /.well-known/openid-federation?jws_alg=ES256. If a federation supports multiple signing algs for the Entity Statements, e.g. to migrate from RS256 to some PQC safe alg over some period of time, it's not sufficient to just say "we support these JWS algs".

Thoughts / ideas?

[Razumain]

My thoughts is that this does not fit into my understanding of the use-cases.

Example A
Intermediate A issue an Entity Statement. This is then collected by a resolver and cached.
The requesting entity asks for a resolve statement that includes the Entity Statement from Intermediate A as the specified chain.
The requesting entity sends the chain off to a micro service that validates the chain.

Example B
The RP builds its own chain either directly or through a resolver. It use that chain in a registration request to a OP and forwards the Entity Statements of the chain.

In neither of these cases does the verifier have any possibility to choose algorithm. They can only process what they received and if they can't process the algorithms, they will reject.

Example C
The Entity Configuration is fetched using the ./well-known location. There is no room here for asking for a particular algorithm.

More concerns. Being able to ask for a unique algorithm for each request prevents caching of response data. This can be converted to an attack tool and puts unreasonable burden on the services.

I think we need to keep this simple. This is a problem that will be handled on a level that does not have to include metadata. It will be reflected in agreements between services decided out-of-band. The penalty for using non-agreed algorithms is immediate loss of interoperability. That is a self-fixing problem. Services will adapt in order to interoperate.

Even if we could fix it using metadata, I don't see how it would work in practice.