On Tue, Jan 23, 2024 at 09:00:47AM -0600, Orie Steele wrote: > Here is the proposal I made for adding a protected header to the json > serialization. > > https://github.com/OR13/draft-jose-hpke-test-vectors/pull/1/files > > This PR: > > - adds a protected header to the json serialization for HPKE JWE. > - uses the protected header as aad for both seal and open HPKE operations > - uses the protected header as aad for both encrypt and decrypt content > encryption operations
Using protected headers in Key Encryption is sure to cause severe problems with several implementations. The problem is that since JWE does not predict that sort of behavior, the implementations lack the required datapaths. And adding those might be extremely difficult. > The `enc` parameter is redundant to the `alg` for HPKE suites, but I > included to for aesthetic consistency with: > > https://datatracker.ietf.org/doc/html/rfc7516#section-3.3 No, it is not redundant. Due to HPKE limitations, in JSON serialization it must be operated as Key Encryption. It can not perform main bulk encryption. That must be performed by JWE, and JWE requires "enc" to specify algorithm to use. JWE does not allow inferring that. The compact serialization situation is different. Then it is possible to use HPKE for main bulk encryption, taking over the required parts of JWE. I have been thinking about rather different way of doing things, also with two modes; 1) - Headers SHALL NOT contain "enc". - General JWE JSON serialization MUST NOT be used. - HPKE plaintext is (possibly compressed) message. - HPKE aad is computed according to JWE Section 5.1 step 14. - HPKE info is empty. - JWE Encrypted key is HPKE enc. - JWE Initialization Vector is empty - JWE Ciphertext is HPKE ciphertext. - JWE Authentication Tag is empty. 2) - Main headers SHALL contain "enc". - General JWE JSON serialization SHOULD be used. - HPKE plaintext is the CEK. - HPKE aad is empty. - HPKE info is empty. - JWE encrypted key is concatenation of HPKE enc and ct. (no need for length markers). Notes: - The first mode lacking enc is vital, as that is how receiver tells which mode is used, as the two are incompatible. - Anything that requires general JWE JSON serialization can not possibly work in the first mode. - The enc length is always fixed by ciphersuite. E.g., all kem16 ciphersuites have 65 byte enc. -Ilari _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
