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. 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? - 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. If we use two separate fields then each individual value would be shorter. For example, the example in the PR is 0x00010001. As you state above, this requires 6 bytes like this: { 2 : 0x00010001 } A1 # map(1) 02 # unsigned(2) 1A 00010001 # unsigned(65537) If we encode it as separate fields then it only needs 4 bytes: { 2 : 0x0001, 3 : 0x0001 } A2 # map(2) 02 # unsigned(2) 01 # unsigned(1) 03 # unsigned(3) 01 # unsigned(1) - 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? - 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? 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. Ciao Hannes IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
