I agree, `alg` and `enc` (when present) have always been related: other than "alg": "dir", `alg` must always produce a key compatible with `enc`, and therefore it must 'know about' things relevant to `enc. It doesn't make any sense to me to claim `alg` must be independent of `enc`.
This feels a whole lot like trying to force-fit existing 10-year well-defined headers to support entirely new concepts that were never intended to be used in such headers (`alg` has never required anything about *content* encryption, only key encryption); see my preceding response in this thread. Anyway, conceptually at the highest level HPKE is a 3 phase process: (key encapsulation) --> (key derivation) --> (content encryption), so the `alg` value should contain all the (key encapsulation) -> (key derivation) parts first because that's the 'key management' stuff. But for JOSE, the first two phases aren't just KEM-->KDF. It's KEM-->KDF optionally followed by a key encryption/wrap algorithm. In other words, the JOSE CEK is still derived - it's just derived using both the RFC 9180 KEM->KDF phase, potentially followed by a key encryption/wrap phase. It's all still "key derivation", but just a potential extra step beyond what RFC 9180 defines. This implies the only way to really represent a polymorphic KDF identifier for JOSE would be either: - a standard HKDF identifier for integrated encryption e.g. "$hkdf_id" - a standard HKDF identifier concatenated with the `+` character followed by the key encryption algorithm identifier, e.g. "$hkdf_id+$kealg_id" This is all still part of the JOSE 'key derivation' phase and identifier strings should be tightly associated as such (combined) before any content encryption identifier. This reiterates what Orie has already shown in previous examples, but I wanted to express *why* I believe the format should be this way to be semantically 'correct' with the way the `alg` header parameter has always worked (i.e. key management) and why I believe the KDF id should be tightly coupled (`+`) with the key encryption alg id. There doesn't seem to be a good way to avoid the explosion of registrations Orie is hoping to avoid. Based on https://www.iana.org/assignments/hpke/hpke.xhtml and the existing JWA RFC, there are (currently): - 10 KEM algs - 3 KDF algs - 6 key encryption algs (A128KW...A256GCMKW) - 6 JOSE content AEAD algorithms implying a whopping 1080 permutations! Removing the content AEAD algorithm from the alg identifier (and keeping it only in `enc`) drops the permutations to 180. Still quite large. It seems that the only sensible solution is to greatly limit the permutations to only a select few, but then you'd be excluding potentially desirable permutations and/or greatly limiting any future 'pluggability' that would be desirable, forcing a new RFC to address them. I'd assume it'd be better for RFC longevity and flexibility to indicate that, while those few would exist as registrations, others MAY exist. Or better yet IMO, eliminate the requirement for fully-specified strings and instead provide requirements around what permutations MUST or MUST NOT exist. Best, Les
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
