Brian wrote: > The 'dir" Key Management algorithm for JWE is defined in JWA as Direct Encryption with a Shared Symmetric Key, which is not what's happening with that HPKE Direct Encryption mode.
> This section defines the specifics of directly performing symmetric key encryption without performing a key wrapping step. In this case, the shared symmetric key is used directly as the Content Encryption Key (CEK) value for the "enc" algorithm. https://www.rfc-editor.org/rfc/rfc7518.html#section-4.5 It is true that when 7518 was written, "alg : dir" only had one meaning, for example: https://datatracker.ietf.org/doc/html/rfc7520#section-5.6 In the case of "HPKE Direct Encryption", consider the single shot APIs: https://datatracker.ietf.org/doc/html/rfc9180#name-single-shot-apis Instead of seeing: { "alg": "dir", "kid": "77c7e2b8-6e13-45cf-8672-617b5b45243a", "enc": "A128GCM" } You would see: { "alg": "dir", "kid": "77c7e2b8-6e13-45cf-8672-617b5b45243a", "enc": "HPKE-Base-P256-SHA256-A128GCM" } Instead of "77c7e2b8-6e13-45cf-8672-617b5b45243a" dereferencing to: { "kty": "oct", "kid": "77c7e2b8-6e13-45cf-8672-617b5b45243a", "use": "enc", "alg": "A128GCM", "k": "XctOhJAkA-pD9Lh7ZgW_2A" } It would dereference to: { "kid": "77c7e2b8-6e13-45cf-8672-617b5b45243a", "alg": "HPKE-Base-P256-SHA256-A128GCM", "kty": "EC", "crv": "P-256", "x": "vQxv17rpEWesvyfFe7EronTClCTZTwYrof7iQI_ESME", "y": "G_89kDqIMslM2IvlwxljC13G1Dizg-7PqquWxH6mTC4" } Regardless of how it is expressed, the goal of "HPKE Direct Encryption" is to use a suite ( KEM, KDF, and AEAD from the registry ), to encrypt a message to a public key: https://www.iana.org/assignments/hpke/hpke.xhtml Perhaps the working group might consider the following alternatives more intuitive: { alg: HPKE-Base-P256-SHA256-A128GCM, enc: dir } or { alg: HPKE-Base-P256-SHA256-A128GCM, enc: A128GCM } or { alg: HPKE-Base-P256-SHA256-A128GCM } (enc implied to be A128GCM) Another option would be to split the HPKE suite information up differently for key encryption and direct encryption. { alg: HPKE-Base-P256-SHA256-A128KW, enc: A128GCM } ( this would introduce lots of redundant registry entries ) { alg: HPKE-Base-P256-SHA256, enc: A128GCM } (this could lead to mismatches in strength, and hash function, and poor interop) I prefer JOSE and COSE, not split up HPKE suites, since some combinations of KEM, KDF, and AEAD do not make sense, and enabling them to be selected a-la-carte reduces the chances of successful interoperability, and makes negotiation complicated. Whatever JOSE and COSE decide to do, it should be aligned as much as possible. On Mon, Jun 10, 2024 at 4:03 PM Brian Campbell <bcampb...@pingidentity.com> wrote: > > > On Sun, Jun 9, 2024 at 11:06 PM tirumal reddy <kond...@gmail.com> wrote: > >> On Sat, 8 Jun 2024 at 02:39, Orie Steele <orie@transmute.industries> >> wrote: >> >>> >>> >>> On Fri, Jun 7, 2024, 3:09 PM Brian Campbell <bcampbell= >>> 40pingidentity....@dmarc.ietf.org> wrote: >>> >>>> Couching my comments inline below with my own experience or lack >>>> thereof: I've got a 10+ year old JOSE/JWT implementation that supports JWE >>>> compact serialization and is still in (relatively) widespread use, so I >>>> have some knowledge in that area. However, I'm only a casual observer of >>>> HPKE and the efforts to bring its wisdom down from the mountain to JOSE. >>>> >>>> >>>> On Tue, Jun 4, 2024 at 4:44 AM Ilari Liusvaara < >>>> ilariliusva...@welho.com> wrote: >>>> >>>>> On Sun, Jun 02, 2024 at 10:56:35AM -0500, Orie Steele wrote: >>>>> > I've suggested a change to JOSE HPKE to align it with COSE HPKE: >>>>> > >>>>> > https://github.com/tireddy2/JOSE_HPKE/pull/26 >>>>> > <https://github.com/tireddy2/JOSE_HPKE/pull/26/files> >>>>> > >>>>> > If there is consensus to make this change, I can update my prototype >>>>> and >>>>> > regenerate examples for the draft, and the cookbook: >>>>> >>>>> Sure, it is better. >>>>> >>>> >>>> I agree that it's better to not use the "epk" (ephemeral public key) >>>> <https://www.rfc-editor.org/rfc/rfc7518.html#section-4.6.1.1> header >>>> for something that sure doesn't seem like a public key (ephemeral or >>>> otherwise). Also noting that "epk" was specified in the context of JWE's >>>> ECDH >>>> Key Agreement <https://www.rfc-editor.org/rfc/rfc7518.html#section-4.6> >>>> . >>>> >>> >>> enc or encapsulated key is an ephemeral public key for DHKems, but for >>> PQ KEMs like ML-KEM, it is KEM ciphertext. >>> >>> I suggest reading RFC9180 (from memory this is the HPKE RFC, possible my >>> memory is wrong) to get a feel for the HPKE Kem interface. >>> >>> >>>> >>>> >>>> >>>>> However, there is this text in RFC 7516, section 5.1.: >>>>> >>>>> 4. When Key Wrapping, Key Encryption, or Key Agreement with Key >>>>> Wrapping are employed, encrypt the CEK to the recipient and let >>>>> the result be the JWE Encrypted Key. >>>>> >>>>> Which seems to say that the whole output should go into JWE Encrypted >>>>> Key. >>>> >>>> >>>> As the aforestated casual observer, I have not understood why the JWE >>>> Encrypted Key isn't a good place to put the encapsulated key. >>>> >>> >>> In the case of multiple recipient hpke, you have a kem ciphertext and an >>> encrypted content encryption key per recipient, similar to what you see in >>> a message encrypted with both ECDH-ES+A128KW, and ECDH-ES+A256KW. >>> >>> In the case of direct HPKE encryption, you have a single recipient, and >>> HPKE encrypts the plaintext directly without an intermediate content >>> encryption key being externalized. >>> >>> Most of the discussion we've had so far has been about if it's easier to >>> reuse an existing parameter for HPKE or if we should create new parameters >>> that are specific to HPKE. >>> >>> If I understand Ilari's comment, he suggests that when HPKE is used to >>> encrypt a cek, the JWE Encrypted Key is the concatenation of the kem >>> ciphertext and the aead ciphertext. >>> >>> This would require implementations to split this base64url encoded >>> concatenated string for each HPKE kem, in order to decrypt the content >>> encryption key. >>> >>> I tend to prefer using JSON, or CBOR to handle distinct parameters, >>> instead of splitting binary or text encoded binary in a single envelope >>> parameter. >>> >> >> Yes, I don't see a need to overload the JWE Encrypted Key to carry the >> encrypted CEK and KEM ciphertext. Introducing a new parameter to carry the >> KEM ciphertext does not break the procedure in steps 3 and 4 of Section 5.1 >> of RFC7516. >> >> >>> >>>> >>>> >>>> >>>>> The algorithm can not be Key Agreement with Key Wrapping, because >>>>> then step 3 would come to play, and it wants "the key agreement >>>>> algorithm to compute the value of the agreed upon key" (something that >>>>> requires exporters in HPKE). >>>>> >>>>> There is of course two outputs. Naive concatenation would work, because >>>>> length of enc is determined by KEM (it is even listed in IANA >>>>> registry), >>>>> which is determined by alg. >>>>> >>>>> >>>>> As for the other mode, JWE as of currently defined does not allow it. >>>>> What the draft currently does with it is flat out Undefined Behavior. >>>> >>>> >> If you are referring to HPKE Direct Encryption mode, it is a new mode >> (similar to one defined in COSE HPKE spec). >> > > I'm not sure but maybe he's referring to how that 4.4.1. HPKE Direct > Encryption > <https://www.ietf.org/archive/id/draft-rha-jose-hpke-encrypt-07.html#name-hpke-direct-encryption> > uses the JWE "dir" alg in an inappropriate and non-compliant way? The > 'dir" Key Management algorithm for JWE is defined in JWA as Direct > Encryption with a Shared Symmetric Key > <https://www.rfc-editor.org/rfc/rfc7518.html#section-4.5>, which is not > what's happening with that HPKE Direct Encryption mode. That's something > that probably needs to be addressed regardless of what Ilari was actually > referring to here. > > > > > > > *CONFIDENTIALITY NOTICE: This email may contain confidential and > privileged material for the sole use of the intended recipient(s). Any > review, use, distribution or disclosure by others is strictly prohibited. > If you have received this communication in error, please notify the sender > immediately by e-mail and delete the message and any file attachments from > your computer. Thank you.* -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list -- jose@ietf.org To unsubscribe send an email to jose-le...@ietf.org
