On Mon, Oct 10, 2022 at 02:04:26PM +0000, Hannes Tschofenig wrote: > Hi Ilari, > > The current PR text is largely based on the input provided by Daisuke. > > From your response I understand that you and Daisuke were only in agreement > that you disliked my proposal but are in disagreement regarding your > proposals. > Let me try to find the best of both worlds.
Yes, while the goals are very similar, there is some disagreement about technical approach. > Hence, a few questions below: > > -----Original Message----- > From: COSE <[email protected]> On Behalf Of Ilari Liusvaara > Sent: Monday, October 10, 2022 2:21 PM > To: [email protected] > Subject: Re: [COSE] COSE-HPKE discussion: My conclusion > > On Wed, Oct 05, 2022 at 08:16:44AM +0000, Hannes Tschofenig wrote: > > Hi all, > > > > I have prepared a PR: > > https://github.com/cose-wg/HPKE/pull/9 > > > > Please let me know what you think. > > > > Some quick comments: > > - Why the optional KEM field in the message structure? The recipient > has to be able to dig the KEM from the private key anyway. > > One situation where having KEM id in message could be useful would be > if recipient supports both P-* and CP-* with COSE_Key EC2 private key. > Altough that is not absolutely mandatory, as one can successfully > tiebreak using ek length. > > (When decrypting with P-* and CP-* KEMs using EC2 private key, taking > d value as byte string from key and stuffing it raw into HPKE private > key input should work. With future CP-* KEMs, doing similar thing with > x value when encrypting should also work). > > [Hannes] This is based on the proposal by Daisuke. > Are you saying you don't want the field to be there at all or you want > it to be mandatory? I personally would rather not have any unnecressary fields. And having the field optional is especially nasty: The implementations have to both work without it, and handle wild values. And I do not think there are any situations where that field is strictly needed. > - Not concatenating KDF and AEAD would likely save a bit of space. > The concatenated form takes 6 bytes, but split form would likely > take 4. > > + There is no AEAD 0, so the composite id is pushed to 32 bit > range. And encoding 32 bit integer takes 5 bytes. Plus there is > the key byte for total of 6. > > + Whereas presently assigned AEAD and KEM ids are in the 4.5 > bit range, which takes 1 byte to encode. Two of those plus > two key bytes for total of 4. > > [Hannes] This design was based on the proposal by Daisuke. > It sounds like you are ok with the concatenation idea but you > prefer an alternative encoding for the concatenation. > The address range allocated for AEAD and KEM IDs is 2 bytes, each. > Of course, there are not many ids allocated right now. Well, I thought some applications might mind those 2 bytes. > - I do not see the reason why the COSE HPKE Sender Parameter Registry > is defined. > > It seems to me that any possible extension has to be incompatible > (the present structure seems to be enough to completely use the > HPKE base mode). > > Such incompatible extensions can not be ignored: The decryption > will fail. Therefore such extensions should presumably have their > own alg values, with redefined context structure. > > [hannes] We have to stick the values in some structure. This > was the proposal by Daisuke. What structure would you like to re-use > or define? Well, essentially defining COSE_HPKE_Sender_V2 if there is ever need to add another field. And then assigning new alg value for HPKE with COSE_HPKE_Sender_V2. Adding another field requires major specification work anyway, as it would be using HPKE in a new way. COSE_HPKE_Sender could even be 3 element array (kdf, aead, enc). That would save further 3 bytes from message size. There are also some other applications (e.g. dedicated post-quantum encryption) that might want to use the same header field. So it could be useful to define the header field to accept arbitrary bstr, array or dictionary, and then in COSE-HPKE specify that for the HPKE alg, its COSE_HPKE_Sender. This is purely about future extensibility, not what COSE-HPKE itself does. > - I do not see a way to generically represent long-term HPKE > keys. > > [hannes] That's not surprising because the draft does not describe those. > What long-term HPKEs should the document define? Both the ways below allow representing any HPKE private key or long- term public key, for any KEM, present or future. The OKP mapping even has an example of future KEM. > Two ways this could be done: > > + Define new HPKE kty, with fields: > * kem (integer) > * priv (bstr) > * pub (bstr) > > + Reserve 16-bit aligned range from positive 32-bit elliptic > curve identifiers to HPKE, and then use that with OKP. > > E.g., range 1212481536 to 1212547071 inclusive (0x48450000 > to 0x4845FFFF, 0x4845 is "HE"). > > Then if HPKE defines say KEM 0x0030, keys for that can be > represented as OKP keys with curve 1212481584. > > > - I think having compact NIST curves in HPKE is such importance (saving > quite a bit of space) that COSE-HPKE specification should attempt to > register those (dropping the registrations if someone else does that > first). > > [Hannes] Thanks for the proposed IANA considerations text but isn't this > currently being done in CFRG, if I understood the discussions correctly, > and in draft-harkins-cfrg-dnhpke-02 in particular? > > I don't want to step on their toes. I don't know who is supposed to > define the HPKE algorithms and encodings. Well, as I see it, the problem is that everybody is seemingly assuming someone else has the ball, and thus nothing gets done. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
