Here is the current language on distinguishing "integrated encryption" from "key encryption".
https://datatracker.ietf.org/doc/html/draft-ietf-jose-hpke-encrypt-01#name-overview > When "alg" and "enc" are both present in a protected header and when "iv" and "tag" are empty, the mode is HPKE JWE Integrated Encryption. > When "enc" is present in a protected header and "alg" is absent, the mode is HPKE JWE Key Encryption when a valid HPKE "alg" value is present in the unprotected headers. I think recipient structures should probably not have "enc": "A128GCM", like they do here: "recipients": [ { "encrypted_key": "S_y3YPaLfjiwGz5o65BHciu14AZv-0J4Kzgtp2s7p7Q", "header": { "alg": "HPKE-P256-SHA256-A128GCM", "enc": "A128GCM", // <- lets remove this ? "kid": "...8fUl1xxvZ-Krvc", "psk_id": "our-pre-shared-key-id", "auth_kid": "...xOA7V-uy8fUl1xxvZ-Krvc", "ek": "...XxWhJyb4LCzMGOLc" } } ] We could say when "alg": "HPKE-P256-SHA256-A128GCM" and no "enc" in the recipient header, the mode is "HPKE JWE Key Encryption" When "alg": "HPKE-P256-SHA256-A128GCM" and "enc": "A128GCM" in the header the mode is HPKE JWE Integrated Encryption. The goal should be that any software that just looks at a headers knows the mode, and that the mode is bound into HPKE using AAD. That is the case today, in integrated encryption the mode is committed to as aad, the header is { "alg": "HPKE-P256-SHA256-A128GCM", "enc": "A128GCM" } In key encryption, the mode is committed to as aad, but the mechanism is via the header that is { "enc": "A128GCM" } ... recipient header would be { "alg": "HPKE-P256-SHA256-A128GCM" } Is this good enough? Regards, OS On Mon, Jul 8, 2024 at 8:07 AM Ilari Liusvaara <[email protected]> wrote: > On Mon, Jul 08, 2024 at 02:20:54AM +0000, Michael Jones wrote: > > Thanks a bunch for taking this on, Orie. To your point about "alg" > > names, I would certainly rather see > > > > "alg": "HPKE-P256-SHA256", > > "enc": "A128GCM", > > > > than > > > > "alg": "HPKE-P256-SHA256-A128GCM", > > "enc": "A128GCM", > > > > The extra "-A128GCM" in the latter "alg" value is redundant and would > > contribute to an unnecessary combinatorial explosion of algorithm > > identifiers. Let's make it a point to eliminate such redundancy > > during IETF 120. > > The "-A128GCM" is not redundant in JWE (RFC7516), those two really mean > different things: > > - 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. > > - The second means to use algorithm "HPKE-P256-SHA256-A128GCM" > (presumably Key Encryption) to derive key for the same bulk > encryption. > > > Currently, the ways bulk encryption algorithm and key mangment algorithm > interact are very minimal, limited to algorithm value in DKA context and > length of key requested from DKA. The section 5 of fully specified > algorithms draft prohibits alg and enc depending on each other (which I > very much agree with). > > > The idea behind using "enc":"dir" is that "dir" is not a valid bulk > encryption algorithm in JWE (and it is already magic as key management > algorithm), so it would signal that something special is going on (with > key managment algorithm taking over bulk encryption). > > > > > -Ilari > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
