Overly broad signature algorithm support

[nightkr]

https://github.com/ena-infrastructure/specifications/blob/39a659490c1d1bbaeb6e32f93fab0ef82b4fee61/ena-oauth2-profile.md#82-cryptographic-algorithms requires both RS256 and ES256 to be supported (with their respective families as RECOMMENDED).

That would make sense during a migration scenario, but given that this is effectively greenfield I think it'd make sense to pick one winner (for now) and go with it. Supporting both wouldn't help much with interop anyway, since you're saddling everyone with that support burden.

HS256 support is also inherited from RFC7518, but can at least be justified by having a different use case (symmetric vs asymmetric crypto). Then again, symmetric signatures aren't really useful in a federation context without separate key negotiation anyway.

[martin-lindstrom]

No, we can't pick one winner. Since we want this to function in a federative context, your suggestion would more or less force implementations to use either RSA or EC keys. We can't do that.

In fact, we are rather a bit liberal on what an entity should support (when it comes to validation). Again, in a federative context there is no client registration in the sense that a client registers at a given OP or AS. So, the corresponding federation profile will probably state additional requirements.

And supporting RS256 and ES256 when it comes to validation can hardly be a problem?

[nightkr]

Since we want this to function in a federative context, your suggestion would more or less force implementations to use either RSA or EC keys.

Someone is getting forced either way, the only question is who. And if we can't even enforce uniformity now then that gets me worried about what that means for complying with the rest of the spec, or any future more urgent algo migrations. (See also: that old story about Van Halen and their brown M&Ms...)

And with the way the spec is written currently, "you have to support ES256" still doesn't imply "you can't support RS256", only "you can't assume that the counterparty supports RS256".

Though I'm not sure "you can bring whatever key you want" is a desirable goal at all; ideally you shouldn't be sharing your Ena-relevant keys with anything else anyway, no? (..apart from TLS certificates, which are kind of bound to WebPKI at large.)

Again, in a federative context there is no client registration in the sense that a client registers at a given OP or AS.

Not for the entity statements themselves, no. (Though "at a given OP or AS" is a bit misleading, since OIDF assumes that there's always some registration happening, whether that's implied from the authz request (§12.1) or using the explicit API (§12.2)).

So, the corresponding federation profile will probably state additional requirements.

Isn't that the whole point of these Ena profiles? Or is there intended to be a policy difference between Ena-the-spec-framework or Ena-the-federation?

And supporting RS256 and ES256 when it comes to validation can hardly be a problem?

Fundamentally, your protocol is only as strong as the weakest algorithm you support, so "we support RS256 or ES256" just means "we're vulnerable if RS256 or ES256 is broken", in exchange for.. pretty much no upside?

[martin-lindstrom]

Based on your reply, I don't understand what you are after.

Regarding the OIDF registration you are referring to (12.1 and 12.2). Those are pretty flawed and won't be profiled by us, and the actual registration of an entity will be done at a superior entity acting as a registration authority. And in these cases there will not be any possibility to algorithm-negotiation.

[nightkr]

It probably doesn't make much sense to discuss this before the OIDF profile draft is public then.