+1 for HPKE-v1-BASE Re title the draft "HPKE Base Mode for COSE” or similar because it’s not a definition of all of HPKE for COSE
Use a fixed array for the sender info that is tied to HPKE-v1-BASE. If there becomes a need to change the array, then we’ll use.an algorithm identifier different from HPKE-v1-BASE. For example, we could have a different array for HPKE-v1-AUTH (if/when someone gets around to it and there is actual need for it to be different). I’m pretty sure HPKE and COSE are well enough understood that we can fix the array now. A fixed array is definitely less code than a map or a variable array. For example with a map you have to do duplicate detection. LL (BTW, I noticed that MLS <https://www.ietf.org/archive/id/draft-ietf-mls-protocol-16.html#name-mls-ciphersuites>, an HPKE-centric message encryption, defines ciphersuites for HPKE. It is near publication, so not just some early draft a fair number of people think ciphersuites for HPKE are a good idea.. For example it defines MLS_128_DHKEMX25519_AES128GCM_SHA256_Ed25519. If you really want to reduce code and message size this is the way to go. There’s definitely few bytes on the wire and you are only decoding one integer (plus the enc) That saving is probably why most of the public key crypto in COSE is ID’d by ciphersuite). > On Dec 9, 2022, at 6:16 AM, Ilari Liusvaara <ilariliusva...@welho.com> wrote: > > On Fri, Dec 09, 2022 at 11:17:32AM +0000, Hannes Tschofenig wrote: >> Hi all, >> >> I would like to get some clarity from the version discussion. >> >> At the beginning we discussed the following question: Do we need >> something other than base mode for HPKE when used with COSE? > > IMO, not currently. However, we should ensure, that such things can be > added in future without allocating new parameters. Which in turn impiles > that HSI (HPKE Sender Info) is either dictionary or polymorphic. > However, since each mode is its own special snowflake, I do not see need > for IANA registry. > > >> Then, the discussions moved into how to encode future versions of HPKE >> into the algorithm identifier. To me the discussion is a bit abstract >> since there is (at least to my knowledge) to plan to work on a new >> version of HPKE (given that the current version is not old). > > Situation with future versions is even worse than with auth-MAC: With > auth-MAC, one at least knows what information needs to be encoded. But > with future versions, nobody even knows what is needed. > > So beyond ensuring HSI parameter is extensible, there is nothing that > can be done. > > > > So in summary: > > - Do just HPKE-v1 base mode for now. > - Possibly other stuff in future. > - Define HSI so that set of fields can change. > - Parametrized by alg. > - No need for registry. > > > > > -Ilari > > _______________________________________________ > COSE mailing list > COSE@ietf.org > https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list COSE@ietf.org https://www.ietf.org/mailman/listinfo/cose
