> I’m interested in reducing the “special snowflake” grade of HPKE. > So I would like to add HPKE as a set of algorithms, instead of defining several new data structures that are necessary to use HPKE as well as to express keys for HPKE.
It seems like you're hesitant about introducing a new data structure, but could you please provide specific drawbacks that it would lead to? In my previous email, I highlighted the advantages of the current draft in 6 points. Are there significant issues that would undermine those advantages? At the very least, regarding hpke_sender_info, there is no difference in introducing the alg according to your proposal, as we would still need to introduce a new header value to transmit the encapsulated key. As for hkc, it is not a mandatory parameter, but if we follow the conventions of COSE/JOSE, it is a necessary data structure. In addition, your proposal is only applicable to COSE and cannot be applied to JOSE in a similar manner. I desire consistency with the specifications of both COSE and JOSE, so from that perspective as well, I am opposed to your proposal. Regards, Daisuke 2023年6月7日(水) 20:20 Carsten Bormann <[email protected]>: > > First and foremost, under the current COSE-HPKE spec, the addition of > new algorithms to HPKE has no effect on COSE-HPKE, and it is possible to > use the new HPKE algorithms as they are. > > > > What exactly are we trying to gain by putting in such effort? > > > > Please tell me the advantages you see over the current COSE-HPKE spec. > > I’m interested in reducing the “special snowflake” grade of HPKE. > So I would like to add HPKE as a set of algorithms, instead of defining > several new data structures that are necessary to use HPKE as well as to > express keys for HPKE. > > (Besides, we save a few bytes, which may or may not be relevant for a > specific application.) > > Grüße, Carsten > >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
