I will add your proposal to the Git Repo as well, Laurence. IMHO it makes sense to consider it.
From: COSE <[email protected]> On Behalf Of Laurence Lundblade Sent: Friday, November 25, 2022 11:24 PM To: Hannes Tschofenig <[email protected]> Cc: [email protected] Subject: Re: [COSE] HPKE Proposals: Something for the group to decide So umm, this might be a bit disruptive, but I’d like it to be considered. Instead of defining a sub-array or sub-map for the HPKE parameters, I propose they be first-class COSE parameters. We’d define 4 new COSE parameters<https://www.iana.org/assignments/cose/cose.xhtml#header-parameters>: HPKE-KDF => uint, HPKE-AEAD => uint, HPKE-KEM => uint, HPKE_Enc => bstr They will all have integer labels and we could probably get assignments less than 24, so the labels only take up one byte. For a typical COSE-HPKE message, it would be about two bytes bigger than the HPKE sender array and smaller than the HPKE sender map. The advantage I’m going for here is object code size. My COSE implementation has generic code to for COSE parameters maps of integers and strings. That code is reused for body header parameters, signature parameters, recipient parameters and COSE keys. If we use the proposed sub-array or sub-map, then another layer of parameter decoding will be needed. I’d guess that this is about 100 bytes of additional object code, a 5 to 10% increase in a super optimized COSE_Encrypt implementation. I assume that at least some other compiled-code implementations would be similar to my implementation that the savings would occur there too. This probably has little effect on python code size. To be clear they parameter values, the actual identifiers of algorithms would still be from the HPKE space. (Though if they could be from the COSE, space some more code could probably be saved as a small identifier mapping layer could be avoided in some cases. It’s unfortunate to me that HPKE defines yet another standard for identifying algorithms. I thought we’d finally converged on a good and universal one with COSE. Note that COSE’s algorithm registry is more sophisticated allowing several levels of specification. HPKE, for example, doesn’t allow for proprietary IDs nor does it require standardization of any new IDs. Part of the problem here is that HPKE is NOT a standard, just an informational draft. IMO it really should run through the IETF standards process). LL On Nov 24, 2022, at 4:14 AM, Hannes Tschofenig <[email protected]<mailto:[email protected]>> wrote: Hi all, I have updated the two proposals from Ilari & Daisuke and I think they are detailed enough to make a decision. Daisuke's proposal is here: https://github.com/cose-wg/HPKE/blob/d54703e0894f69f74db34526fb5c5f300ff3e03e/draft-ietf-cose-hpke.md Ilari's proposal is here: https://github.com/cose-wg/HPKE/blob/010965883cf02d357d972e05dbb96795069f68ba/draft-ietf-cose-hpke.md At this point in time it is probably best to look at the examples. The main differences between the two proposals are: * Terminology: Daisuke uses the term HPKE Sender Information structure to refer to the payload that contains the HPKE information while Ilari calls it encapsulated_key structure. * Encoding: Ilari uses an array for the encapsulated_key structure with no option for extensibility. As a result there is no need to register the parameter labels. Daisuke uses a map structure for the HPKE sender information. Thoughts about the direction we should go? 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]<mailto:[email protected]> https://www.ietf.org/mailman/listinfo/cose 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
