On Mon, Jul 08, 2024 at 08:11:51PM -0700, Les Hazlewood wrote: > Thank you Orie, your last two replies are really helpful! > > If flexibility and some degree of future proofing are desired, without an > explosion of registration permutations, would it make sense to support the > KEM and HKDF identifiers as separate header parameters? For example: > > "alg": "HPKE" > "kem": "P256" > "kdf": "HKDFS256" > "enc": "A256GCM" > > Then these would be pluggable as desired, so long as strength requirements > are maintained between inputs/outputs. > And the number of registrations for each respective header would be easily > constrained to have a 1:1 correlation with the 3 functions in RFC 9180 > (KEM, KDF, AEAD triplet), as well as those in > https://www.iana.org/assignments/hpke/hpke.xhtml > > I'm not sure if this opens a can of worms or not, but it seems relatively > elegant on the surface. Thoughts?
There was an explicit decision to use ciphersuites instead of doing that kind of thing (old versions of HPKE in COSE essentially did work like that). As far as I can see, that decision was driven by interop and "strength matching" concerns. My view of "strength matching" is strictly about efficiency: Using resources to fortify something that is not the bottleneck wastes those resources. However: - It is not acceptable to artificially weaken things to "match" security of others. - "X bits of security" arguments can be extremely misleading, especially if comparing confidentiality and authentication. -Ilari _______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
