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

[Les Hazlewood <[e-mail]>]

Thinking though this a whole lot more I think I was confused on which
alg/enc parameters were used in which header elements.  To avoid that
confusion for myself, I'll refer to them using their RFC 7516 names:

Currently with JWE, `enc` algorithms/IDs are all AEAD algorithms, and I
think this must remain the same. Consistency, no surprises, everything
stays the same, lowest possible impact to all existing JOSE
implementations. And actually, having this value be anything other than an
AEAD algorithm would violate RFC 7516, Section 4.1.2
<https://datatracker.ietf.org/doc/html/rfc7516#section-4.1.2> as written:
 "This algorithm MUST be an AEAD algorithm with a specified key length."
 Many implementations (mine included) make plenty of assertions that this
must be an AEAD algorithm that requires secret keys, etc.  Changing this to
be a different type of algorithm would cause a lot of problems on
implementations, especially those written in typesafe languages.

In the multi-recipient case, I agree, there doesn't need to be an `enc`
value in the JWE Per-Recipient Unprotected Header because it's always
implied by the JWE Protected Header.  This must be the same for all
recipients anyway.  Nor is an JWE Protected Header `alg` value required
since that will likely be different per recipient.  The union (JWE JOSE
Header) for a single recipient and/or JWT must have both header parameters
however.

For HPKE then, it seems that the `alg` value only needs to include the
first 2 HPKE cipher suite IDs/tokens and exclude the trailing AEAD id as
Michael Jones said.  But then Ilari said:

"- The first means to use algorithm "HPKE-P256-SHA256" (presumably Direct
  Key Agreement) to derive key for "A128GCM" (which is defined by
  RFC7518) bulk encryption."

I'm probably missing something, but I don't believe this is an issue.
HPKE does not use nor accept direct shared symmetric key IKM (input key
material).  That is, HPKE is only to be used for public key derivation of a
shared secret (KEM) which is then tied to context and made
cryptographically uniform (HKDF), and that output key is used as the AEAD
symmetric key.

That means if you have an `enc` value, you only need the HPKE ID trailing
tokens to be a tuple because you already have the 3rd in the `enc` header
parameter. That is:

header['alg'] + header['enc'] would always
equal "HPKE-<KEMID>-<HKDFID>-<AEADID>"

That is unless you're trying to use HPKE as a key encryption/wrapping
algorithm, which brings me to my next question:

Why is JWE HPKE Key Encryption necessary at all?  Since HPKE requires
asymmetric keys to be used, what is the use case for encrypting a
direct/shared symmetric key when the recipient must decrypt with their
private key anyway?

Thanks,

Les