> On Nov 25, 2022, at 7:45 PM, AJITOMI Daisuke <[email protected]> wrote: > > So umm, this might be a bit disruptive, but I’d like it to be considered. > > One more proposal has come up and I'm having fun. > > I think your idea should be considered as one candidate solution because it > has a clear advantage for object code size. > > HPKE-KDF => uint, > HPKE-AEAD => uint, > HPKE-KEM => uint, > HPKE_Enc => bstr > > Perhaps the following headers may need to be added as well. > > HPKE-Version => uint,
That sounds a bit scary to me. We do not want to encourage versions. > HPKE-Mode => uint, This could be built into the COSE algorithm ID. The algorithm IDs could be HPKE_BASE and HPKE_AUTH, perhaps the PSK stuff could be added later. The version could be built in into COSE algorithm ID too. If there ever was an HPKE-v2 then it would be HPKE2_BASE and HPKE2_AUTH. I really really hope there is no HPKE-v2. Both the mode and the version are sort of major characteristics that 1) are useful to know up front and 2) should not fan out much more than one or two points past what they are now. > HPKE-PSK-ID => bstr, Don’t understand this yet, but maybe it could be mapped to COSE kid. Note that Illari's sub-array proposal can’t handle these extra 3 parameters, but if you roll them into the COSE algorithm ID, then just psk_id is left (and it could be in the kid). LL
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
