On Tue, 11 Jun 2024 at 03:00, Orie Steele <[email protected]> wrote:
> 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) > I see that the JOSE specifications expect both parameters to be provided. Despite the redundancy, the second option seems like the preferred choice. > > 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. > Agreed. > > 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 <[email protected]> > wrote: > >> >> >> On Sun, Jun 9, 2024 at 11:06 PM tirumal reddy <[email protected]> wrote: >> >>> On Sat, 8 Jun 2024 at 02:39, Orie Steele <[email protected]> >>> wrote: >>> >>>> >>>> >>>> On Fri, Jun 7, 2024, 3:09 PM Brian Campbell <bcampbell= >>>> [email protected]> 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 < >>>>> [email protected]> 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 -- [email protected] To unsubscribe send an email to [email protected]
