> > As my example spec should show, it is not too hard.
What I mean is that the effort involved is not commensurate with the benefits gained. It's hard in that sense. — just fall back to making a new registration. 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. Daisuke 2023年6月4日(日) 18:54 Carsten Bormann <[email protected]>: > On 2023-06-04, at 09:45, AJITOMI Daisuke <[email protected]> wrote: > > > > So I’d amend my little formula to > > > > AEAD-Identifier = AEAD-Value == 7 ? 0xFFFF : AEAD-Value + 1 > > or > > AEAD-Identifier = AEAD-Value == 0 ? 0xFFFF : AEAD-Value > > > > …or some such. > > > > Are you suggesting that we write such ID conversion into the spec? > > “The spec” = whoever registers these algorithm IDs. > But remember that this is no “conversion”, it is simply a systematic way > to assign combinations of HPKE identifiers to specific algorithm IDs. > > > I think there are various difficulties with trying to squeeze > information that is originally 6 bytes into 2 bytes. > > As my example spec should show, it is not too hard. > > > It's possible for HPKE to express the category of the algorithm by > turning on specific bits. > > Sure. If that doesn’t fit into the ranges covered by my example > registration, there may be a need for another registration. In this case, > the disadvantage of having to register something on the COSE side to get > new HPKE functionality occurs once, instead of each time somebody wants to > use a “new” combination. > > > Of course, this was a joke. I don't think it's a good idea to assume > that we can control the ID assignment rules of HPKE, or that we can control > them, for the sake of a workaround specification for COSE-HPKE. > > We don’t have to control them (see above). > On the other hand, I believe we can expect the HPKE community not to be > hostile to COSE, so they will only make this necessary if they have a good > reason to. > > >> But that process is trivial. > > > > Indeed, it may be a trivial issue, but I am still opposed to the premise > that we can control the HPKE specification to fit this conversion process. > > No control needed. My proposal works best if there is some form of mutual > respect governing the HPKE-side assignments, but it doesn’t even need that > respect — just fall back to making a new registration. > > Grüße, Carsten > >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
