On Sun, Jul 07, 2024 at 05:16:24PM -0500, Orie Steele wrote:
> Hello,
>
> I have done my best to apply all the feedback gathered from the adoption
> call, and I want to draw your attention to the latest draft, and its
> primary remaining obstacles for discussion at ietf 120.
>
> In my haste, I may have destroyed something essential. Apologies to my
> co-authors, feel free to roast me at the mic line.
- Given the JWE recipient header assembly rules, how is one supposed to
tell apart Integrated Encryption and Key Encryption? JWE does allow
having "alg" in protected headers (as long as all recipients use the
same key management algorithm).
- The enc value is redundant for Integrated Encryption.
- Using full aad for Key Encryption is problematic:
* It seems like something that would cause severe implementation
problems in existing JWE implementation.
* It does not even fullfill its seeming purpose, because JWE does
not require protecting "enc".
If one wanted algorithm separation at key encryption level, it would
be sufficient to include just the bulk encryption algorithm in the
KE aad. This would be less problematic for existing implementations,
and would actually fullfill its purpose.
Subtle issue is that the algorithm name must be canonicalized (however,
there is currently no algorithm where any reasonable implementation
would get that wrong). Analogous subtle issue exists with Direct Key
Agreement, where algorithm name is included in context.
The most obvious canonicalization is using minimal number of Unicode
Scalar Values. I.e., only escape or use \u if absolutely required.
The only codepoints requiring escaping that are neither control (pretty
suspect in algorithm names) nor unpaired surrogates (which make many
JSON parsers blow up immediately) are '"' and '\', escaped as '\"'
and '\\'.
> Risk areas, and things which we would like to resolve ASAP.
>
> ### Fully specified HPKE algorithms
>
> It would be nice to have confidence that the algorithm names will not
> change.
>
> For example where we currently see:
>
> ```
> "alg": "HPKE-P256-SHA256-A128GCM",
> "enc": "A128GCM",
> ```
>
> We might see:
>
> ```
> "alg": "HPKE-P256-SHA256",
> "enc": "A128GCM",
> ```
>
> Or whatever the working group decides counts as a "fully specified HPKE
> algorithm".
If encrypting with HPKE, only the first is fully specified.
> ### HPKE AAD vs JWE AAD
>
> I think the current approach is better than computing some custom KDF info
> from apu / apv... But is setting the following as HPKE AAD enough?
>
> hpke-info = empty
> hpke-aad = encode-protected-header . aad (when JWE aad is available)
>
> Where encoded protected header is either the protected header for
> hpke jwe integrated encryption, or the protected header used in content
> encryption, for which the content encryption key is being encrypted?
It is not enough for Key Encryption. hpke-aad is not guaranteed to
capture any of the values ("enc", "apu" or "apv") one might care about!
> ### Lossy conversions
>
> It's possible to express things in JSON Serialization that can't be
> expressed in Compact serialization.
> I tried to make this explicit, but we could decide to simply forbid
> conversions from JSON to Compact that lose information, or that would move
> things around "ek" to "encrypted_key".
I think JWE is already clear enough on the limitations of compact
serialization. I.e., what messages require JSON serialization to
represent.
However, none of the existing JWE Key Managment Modes does stuff that
requires JSON serialization. It is perfectly possible for Compact
Serialization to use, e.g., Key Encryption.
-Ilari
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
