>
> So umm, this might be a bit disruptive, but I’d like it to be considered.
One more proposal has come up and I'm having fun.
I think your idea should be considered as one candidate solution because it
has a clear advantage for object code size.
HPKE-KDF => uint,
> HPKE-AEAD => uint,
> HPKE-KEM => uint,
> HPKE_Enc => bstr
Perhaps the following headers may need to be added as well.
HPKE-Version => uint,
HPKE-Mode => uint,
HPKE-PSK-ID => bstr,
> 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.
Yes, two bytes smaller than the HPKE sender map.
But I think we need to discuss whether we can consume 4 to 7 first class
(<24) header values only for HPKE.
In principle, I don't think it is a good idea to have multiple pieces of
information that need to be used together separated into different header
values.
However, if the COSE WG will decide that minimizing object code size should
be pursued, I have no reason to disagree.
Regards,
Daisuke
2022年11月26日(土) 7:24 Laurence Lundblade <[email protected]>:
> 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]>
> 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]
> https://www.ietf.org/mailman/listinfo/cose
>
>
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose
>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
