On Fri, Jul 12, 2024 at 05:54:05PM -0500, Orie Steele wrote: > Brian, > > You are correct. > > This is why I wrote : The working group SHALL draft text explaining what > "enc:dir" means, and how it is related to "alg". > > Perhaps this might look like: > > This document updates RFC7516. > > This document defines a new value "dir" for "enc".
This definition needs to be indepdent of HPKE. The HPKE ciphertsuites are then layered on top of this mechanism. And presumably should include the encryption/decryption procedures like sections 5.1. and 5.2. of JWE. As sanity check, the first operations in decryption process should be the same as defined in section 5.2 of JWE (I think steps 1 through 5). > When "enc:dir" is present tag and iv are empty. There is no technical reason to require this. However, there is, e.g., a technical reason to require "enc:dir" to not use headers. HPKE does not have to use this even if it is there. > "enc:dir" can only be used with "alg" values that use an AEAD to perform > authenticated encryption on plaintext to produce ciphertext, when these > algorithms are used iv and tag are empty. I think the practical way to add a new algorithm operations for performing bulk encryption/decryption (naturally only algorithms that support the new operation have it) and then call into that. Algorithm operations are not exclusive, so the same algorithm could then have "encrypt the CEK to the recipient" and "decrypt the JWE Encrypted Key" operations required to act as Key Encryption. > As you have just pointed out, it would be incorrect to use "enc: A128GCM" > for integrated encryption because no tag and no iv are present. It is not incorrect for that reason, it is incorrect because it means to use JWE bulk encryption mechanism, which is just incorrect for any kind of integrated encryption. It would be just as incorrect if using version of A128GCM that leaves tag and iv empty by just concatenating key/nonce and ciphertext/tag. JWE explicitly allows enc to leave tag and iv empty. > I suggest we defer discussion of the exact text the working group would > need for integrated encryption, since that is not necessary to agree to the > general approach. Yes, I think that whatever reasonable approach to integrated encryption using HPKE will fit into whatever reasonable definition of Integrated Encryption. > ### For HPKE JWE Key Encryption Mode: > > The algorithm name SHALL be of the form "HPKE-P256-SHA256-A128GCM". > The "enc" value SHALL be any registered AEAD here - > https://www.iana.org/assignments/jose/jose.xhtml, per section of RFC7518. > The hpke-aad SHALL be ECDH-ES FixedInfo *(citation needed @ilari can you > provide a reference here please?) * > The hpke-info SHOULD be empty. On text about aad, something like (needs wordsmithing): hpke-aad SHALL be the FixedInfo part of ECDH-ES Concat KDF input. That is, concatenation of AlgorithmID, PartyUInfo, PartyVInfo, SuppPubInfo and SuppPrivInfo inputs, in that order, as defined in section 4.6.2 of JWA. -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
