On Mon, Jun 16, 2025 at 09:27:51PM -0400, Richard Barnes wrote: > I have reviewed this draft, and I broadly agree with Neil's comments [1]. > The document has one fatal flaw, and one that may be straightforward > to fix: "int" should be "alg", not "enc".
I disagree. If the Integrated Encryption algorithm goes into "enc" slot, then there is no sane interpretation of "alg". Or how would "alg:int" and "alg:not-int" differ? And unless one takes the interpretation that Integrated Encryption algorithms are not AEAD algorithms, I do not see any JWE requirement being violated, which is a fatal flaw. Whereas "enc:int" can be interpretted as bulk encryption with "alg", which can co-exist with a way to derive CEK. And "int" is definitely not an AEAD, so it explicitly violates JWE requirements. One should not have any fixed fields in unpadded format unless needed for backward compatibility reasons, and here backward compatibility is explicitly undesirable. So if Integrated Encryption algorithm goes into "enc", then "alg" should be completely absent. This also explicitly violates JWE requirements. While "enc:int", "alg:foo" and "enc:foo", alg missing are both technically feasible, I think that the first (current) one is easier to implement. > The fact that "enc": "int" is bad has been argued in several places. I > won't reprise them here. The arguments I recall involve "int" not being AEAD. Now, non-AEAD algorithm that looked even remotely like AEAD algorithms would be a major security issue. However, "enc:int" is so different it has to be handled as its own special case. And putting the algorithm in "enc" would not improve things, as those algorithms can not be treated as AEAD either. It is easier to branch on "enc:int" in protected bucket than on the various Integrated Encryption algorithms. > On the other hand, "alg": "int" makes sense, with "enc" set to an HPKE > algorithm. It's a direct parallel to "dir", just with an asymmetric key > pair instead of a symmetric key. If you don't like "enc" > encompassing authenticated public-key encryption, use something else, say > "ies"; "enc" is not required. There is a major difference between using asymmetric key pairs and symmetric keys. In JWE, it is possible to encrypt CEK using either asymmetric key pair or symmetric key. Those two are considered two whole different modes: Key Encryption versus Key Wrapping (even if the two seem very closely related). > It's worth noting, though, that this is a non-trivial semantic change to > JWE. It introduces a new "Key Management Mode" to JWE, in addition to the > ones defined in RFC 7516 (Key Encryption, Key Wrapping, Direct Key > Agreement, Key Agreement with Key Wrapping, and Direct Encryption). Call > it "Direct Public Key Encryption", say. This document needs to define that > whole mode, with HPKE as the first instance. There is no way around adding a new mode in order to use HPKE as bulk encryption. And since it is a new mode, it has to violate JWE requirements. And agreed that the document should define the mode and then have HPKE be a special case of it. This can be done in a way that does not change how JOSE-HPKE works. > That's the "make JWE look like HPKE" approach. You could also take the > "make HPKE look like JWE" approach. Recall that the definition of "alg" is > "the cryptographic algorithm used to encrypt or determine the value of the > CEK". You could use HPKE to determine a CEK by just doing the Setup > operation and exporting a key suitable for the "enc" AEAD algorithm. This > just makes HPKE work like ECDH does today. Even if you use it with DHKEM, > you still get some improved binding properties over raw JWE ECDH. This would require second set of algorithms, which in turn would cause issues with keys. > Personally, I prefer the "make JWE look like HPKE" approach, because it > reuses more of HPKE. But I could understand if you didn't like the extra > text to define a new Key Management Mode. > > In any case: Although HPKE and JWE have slightly different shapes, it's > possible to align them in a couple of sensible ways. Unfortunately, the > current draft does neither, so it needs to be revised to do one or the > other. I think that what the document currently does is one of the sensible ways. Yes, it is not elegant, but there are no elegant ways. -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
