On Tue, Jul 09, 2024 at 11:11:19AM -0700, Les Hazlewood wrote: > > > > This is also prohibited by draft-ietf-jose-fully-specified-algorithms > > (It requires what alg to be independent of enc). > > > > Hi Illari, > > > Thanks for the explanation, I appreciate it. > > > However, I think this is a huge mistake. I consider any strong coupling between enc and alg to be a huge mistake.
> The entire purpose of JOSE is to have a JSON-compatible metadata format for > message sending and receiving; with all the flexibility, convenience, > expressiveness and human-readability that implies, which is a really good > thing, and solidifies the ability to be flexible over time, which is ideal > for an RFC. Unfortunately, here one runs into limitations of JOSE: One would want to delegate bulk encryption, which is not something JOSE (or any trivial extension thereof) supports. > Respectfully, this is incredibly regressive. Data models *should* reflect > the best-case modeling scenario, with rich expression, modularity, etc. If > a new “single string alg” concept needs to exist for downstream > specifications and/or convenience, *those* specification working groups > should define such and not impose this on the JOSE/COSE specifications at > large. It’s crippling and will forever impact how any algorithms and their > potential parameters are defined in the future, and just doesn't make sense > to be forced on a general-purpose messaging format. Unfortunately here delegating bulk encryption does impose chagnes on JOSE specifications at large. (COSE is much more flexible, so no changes to COSE are needed.) > Additionally, such an initiative breaks the concepts of `alg` and `enc` as > they are defined today. They are and always have been separate > concepts. `alg` > is a *key* management algorithm, it is not an encryption algorithm. That > HPKE is composed of both operations isn’t a reason to force it into the > existing `alg` construct - that's trying to do too much and force things > that don’t make sense in a single header parameter that has been > well-defined for a decade. This is all manmifestation of the way JOSE is designed. > Any new specification that defines a single string cipher suite definition > should be *additive*, not regressive. A new header could be defined (e.g. > `csuite`) and that can have that string for the times when it may be needed. Or have "enc":"dir" and have that call into new algorithm operations. > Although anecdotal, I will say that not once in 10 years of maintaining > probably the most-used JOSE/JWT library for the JVM and Android has anyone > ever had a problem with separate `alg` and `enc` headers, and that includes > all the OpenID Connect scenarios I’ve supported both professionally and as > an open-source maintainer. JOSE is designed to work that way, so not really surprising nobody had problems. > > Or if a new header isn’t desired, there’s no reason an additive > specification can’t say “If you want a single string, combine the `alg` and > `enc` header with a hyphen, and that’s your cipher suite”. To say that an > implementation - which *must* parse the JSON header and lookup at least one > parameter (`alg`) anyway - cannot lookup another header and concatenate the > two before processing that value doesn’t seem to hold water in any scenario > I can think of. That’s all that’s needed for cipher suite negotiation for > protocols that need a single string. That is not injective. > I’m not saying that cipher suite negotiation isn’t valuable. I’m saying > it’s 1) only valuable to a relatively small set of use cases and 2) is > easily obtainable by looking at existing headers and 3) it’s fundamentally > regressive to a) shoehorn a new composite algorithm into a header that was > never designed as such and b) force *all* JOSE implementations to operate > with this concept when it’s not needed most of the time. The only constraint on negotiation from "enc":"dir" would be that Integrated Encryption must be supported for all or none of the supported algorithms (that allow IE). -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
