> > 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.
Umm, I don't think it is necessary to define an independent "alg" for each HPKE mode. I think they are not so different from each other. However, if the purpose of defining another alg is to achieve a minimum COSE message size using an array, it may indeed be a viable option. 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. In my opinion, the sender public key should be treated as pre-shared (registered to the sender in advance) just like "info" (HPKE application supplied information) and "aad" (additional authenticated data) and we should not send it with the existing sender key/kid parameter. But for PSK, there is no parameter for PSK key id, so it presumably would > go into HSI. I agree. It looks to me that the psk_id needs to be defined as an optional parameter in HSI. Subtle detail: It is COSE_HPKE_Sender only for alg=hpke, otherwise it is > some bstr, array or dictionary. Oh, I forgot the details of your proposal. I was against this polymorphic? approach. I'm thinking it would be better to define it specifically as "HPKE Sender Information", not abstracted "encapsulated key info". Regards, Daisuke 2022年11月25日(金) 19:02 Ilari Liusvaara <[email protected]>: > 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 >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
