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

[Orie Steele <[e-mail]>]

Thanks again for your comments.

You have highlighted that choosing a different encryption algorithm for the
content encryption could make the examples clearer.

You have also generally captured the intention of the 2 modes.

If we were to register HPKE-P256-SHA256+A256GCM and HPKE-P256-SHA256

It would be essentially the same as ECDH-ES and ECDH-ES+A256KW.

Arguing against fully specified encryption algorithms for a moment... We
might drop the curve and kdf parts, and set the kdf to be always sha-256
for JOSE.

This would reduce number of registrations.

alg: HPKE, enc: A128GCM
alg: HPKE+A256KW, enc: A128GCM

However, we would now not be able to negotiate for post quantum encryption
by algorithm alone.

Key generation would need to be aware of kty and crv... We might not have a
way to easily distinguish between ML-KEM-768 and other KEMs for the same
kty.

A benefit of fully specified HPKE algorithms is that negotiation is
simplified, and key generation can be aligned to what can be negotiated.

If it's important to be able to negotiate for integrated vs key encryption,
it is important that they be implied by the algorithm registrations we
request.

On Mon, Jul 8, 2024, 9:11 PM Les Hazlewood <[e-mail]> wrote:

> 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?
>>
>
> Trying to answer my own question:
>
> "alg": "HPKE-P256-SHA256",
> "enc": "A256GCM"
>
> would mean a JWE content encryption key would be obtained by executing the
> KEM to derive a shared secret which is then made uniform by HKDF-SHA256.
> The output of the HKDF Expand function would be the content encryption key
> used to directly encrypt the payload using AES 256 GCM.
> This would imply that the HKDF's `Expand(prk, info, L)` function's `L`
> input length must be equal to the `enc` required key length (in this
> example, `256`).
>
> Whereas
>
> "alg": "HPKE-P256-SHA256-A256GCM",
> "enc": "A128GCM"
>
> would mean
>   a) an ephemeral AEAD secret key (the CEK) would be generated for the
> `enc` algorithm (e.g. AES 128 GCM)
>   b) this ephemeral AES 128-bit CEK would itself be encrypted using HPKE
> P256-SHA256-A256GCM
>   b) the ephemeral AES 128-bit CEK would be used to encrypt the recipient
> payload, and the CEK ciphertext would be included in the recipient header.
>
> Then the recipient uses HPKE P256-SHA256-A256GCM to decrypt the CEK
> ciphertext, producing the CEK, which is then used to decrypt the payload.
>
> Is that about right?
>
> Les
>
>>