> > 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. 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. But then to have a new specification that constrains the most important security aspect of this down to a single string? For a few downstream specifications that don’t represent the bulk of JOSE/JWT use cases? It’s saying “all the reasons we’ve chosen JOSE headers parameters, and all that implies - we’re going to ignore that and force-stuff it all into a single value for the convenience of *some* downstream specifications, all the while imposing this new inconvenient reality on ALL JOSE/JWT scenarios.” 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. 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. 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. 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. 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. 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. Implementations do not need to be forced this concept on a general-purpose messaging format which has many more implications than OpenID Connect and a few other downstream specifications. Most respectfully, and gratefully, Les
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
