[jose] Re: draft-ietf-jose-hpke-encrypt-01

[Les Hazlewood <[e-mail]>]

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