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
