Hi Ilari, > It is COSE_HPKE_Sender only for alg=hpke, otherwise it is some bstr, array or > dictionary.
Yes, COSE_HPKE_Sender is only used when alg=hpke. Hence, there is no "otherwise" here. Ciao Hannes -----Original Message----- From: COSE <[email protected]> On Behalf Of Ilari Liusvaara Sent: Friday, November 25, 2022 11:02 AM To: [email protected] Subject: Re: [COSE] HPKE Proposals: Something for the group to decide On Thu, Nov 24, 2022 at 11:35:24PM +0900, AJITOMI Daisuke wrote: > Hi Hannes, > > Thanks for updating the examples of my proposal. > > > Thoughts about the direction we should go? > > I would like to reiterate my thoughts. > > I am thinking that it may be necessary to define HPKE Mode Information > (Base, Auth, PSK, AuthPSK) and HPKE Version Information as optional > parameters for HPKE Sender Information (HSI). However, it is possible > that neither is required. I am not sure and would like to hear your > opinions on this point on this mailing list (or perhaps we should ask > the authors of the HPKE spec about this point). I would think all those are sufficiently different that all those should have their own alg. Especially given that the MAC usecase for auth would want export-only, which behaves very differently from base mode. And it might be that not all the extra info goes to HSI. For example, in auth mode, there is sender key/kid, it turns out COSE already has suitable parameter for it. But for PSK, there is no parameter for PSK key id, so it presumably would go into HSI. > If the HSI needs to have at least one optional parameter other than > KEM, then the array structure is not suitable for it very well and my > proposal might be better. Otherwise, Ilari's proposal would be better. Subtle detail: It is COSE_HPKE_Sender only for alg=hpke, otherwise it is some bstr, array or dictionary. So for alg=hpke-auth-exp, one could stuff something like the following into that parameter: COSE_HPKE_EXP_Sender = [ kdf: uint, enc: bstr, ? kem: uint, ]; > Basically, I think small message size is a feature for COSE to pursue, > so it would be better to adopt Ilari's proposal if we can. There is also code complexity difference. However, it is not major (based on trying to implement both), and the "polymorphic" type could cause problems with implementations that decode structures first as opposed to algorithm first (I do not know if any implementation does that). -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
