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",
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<http://www.transmute.industries/>
[https://ci3.googleusercontent.com/mail-sig/AIorK4xqtkj5psM1dDeDes_mjSsF3ylbEa5EMEQmnz3602cucAIhjLaHod-eVJq0E28BwrivrNSBMBc]<https://transmute.industries/>
_______________________________________________
jose mailing list -- [email protected]
To unsubscribe send an email to [email protected]
