On Mon, 8 Jul 2024 at 07:51, Michael Jones <[email protected]>
wrote:
> Thanks a bunch for taking this on, Orie. To your point about “alg” names,
> I would certainly rather see
>
>
>
> "alg": "HPKE-P256-SHA256",
> "enc": "A128GCM",
>
alg: 'HPKE-Base-P256-SHA256-A128GCM' looks like key agreement and deviates
from the behaviour discussed in draft-ietf-jose-fully-specified-algorithms.
I prefer "alg": {"HPKE-P256-SHA256-A128GCM", "enc": "A128GCM"}
Cheers,
-Tiru
>
> than
>
>
>
> "alg": "HPKE-P256-SHA256-A128GCM",
> "enc": "A128GCM",
>
> The extra “-A128GCM” in the latter “alg” value is redundant and would
> contribute to an unnecessary combinatorial explosion of algorithm
> identifiers. Let’s make it a point to eliminate such redundancy during
> IETF 120.
>
>
>
> -- Mike
>
>
>
> *From:* Orie Steele <[email protected]>
> *Sent:* Sunday, July 7, 2024 3:16 PM
> *To:* JOSE WG <[email protected]>
> *Subject:* [jose] draft-ietf-jose-hpke-encrypt-01
>
>
>
> 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.
>
> Be advised the github repo for the working group adopted draft is
> currently here, PRs are welcome:
>
> https://github.com/OR13/draft-ietf-jose-hpke-encrypt
>
> As you can see from the document history -01 addresses several points of
> feedback, and uses the terminology and guidance regarding algorithm names
> provided by Ilari and others.
>
> Major changes in this version:
>
> - JWK is no longer used for encapsulated keys, but "encrypted_key" JWE
> member and "ek" header parameter are.
> - HPKE mode (base / auth / psk / psk_auth) is no longer included in
> algorithm registrations.
> - HPKE Setup info and aad are addressed in a single location for both
> integrated and key encryption with hpke.
> - "dir" approach has been replaced with "enc": <some registered aead>.
> - "jwe aad" examples have been added.
> - "psk_id" and "auth_kid" examples have been added.
>
> I've implemented version -01, and the examples are produced from my
> prototype.
>
> 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".
>
> ```
>
> "alg": "HPKE-P256-SHA256+A128KW", ?
> ```
>
>
> ### 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?
>
> ### 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".
>
>
> Thanks for all the feedback during the adoption call.
>
> Regards,
>
> OS
>
>
>
> --
>
>
>
>
> *ORIE STEELE *Chief Technology Officer
> www.transmute.industries
>
> <https://transmute.industries/>
> _______________________________________________
> jose mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
>
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
