> > I consider any strong coupling between enc and alg to be a huge mistake. >
They are already strongly coupled. The properties of the enc algorithm (minimum/mandatory key size) must be known for the key management (alg) behavior. If they were actually independent, alg wouldn't need any enc-based input parameters. > > 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. > Not today at the moment, but as these things would imply new (additive) header parameters, this could be true. It wouldn't be regressive since it does not change the purpose and semantics of existing header parameters. But I do understand and respect what you're saying about delegation and the associated difficulties of a new paradigm. > 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. > This fundamentally changes the semantics of the existing headers. In JOSE, for 10+ years: "alg" has always meant "algorithms used for producing the content encryption key" "enc" means "AEAD algorithm used to encrypt the content with the content encryption key" Changing these semantics has *significant* implications to existing libraries, especially typesafe ones that codify these concepts in type-safe APIs used by application developers (Key types, Interface definitions, etc). > 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. > Yes, but this is the JOSE working group, designed for JOSE messages, and supported by JOSE implementations. I'm having a hard time understanding why a JOSE HPKE RFC would change a decade of semantics and convention when the existing parameters can still be used as intended, and/or new parameters can be introduced. > > 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 don't understand why that must be a requirement of a JOSE RFC - it's trivial logic and can be codified in the RFC. > 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). > "dir" is not an AEAD algorithm. Per https://datatracker.ietf.org/doc/html/rfc7516#section-4.1.2: "This algorithm MUST be an AEAD algorithm with a specified key length." I'm personally worried about changing 10 years of semantics due to the downstream impact that will have on implementations. Even though this is a challenging problem, I'm still very hopeful that a good solution is achievable. I very much appreciate your feedback and explanations, thank you Ilari! Best, Les
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
