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? Kind regards, Les >
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
