I’m in favor of both of these. In addition to previous reasons in favor of #2, the use of COSE’s mechanism for distinguishing one sort of parameter (parameter labels) seems better than making up a new mechanism (polymorphism of a parameter). COSE implementations already have to decode header parameter labels and switch on them. Many will have code handy for this.
LL > On Jan 11, 2023, at 4:51 AM, Hannes Tschofenig <[email protected]> > wrote: > > Hi all, > > To move forward with the COSE-HPKE draft two open issues need to be > addressed. I posted a mail in December, see > https://mailarchive.ietf.org/arch/msg/cose/Cv-UumRRmmXWzrDHAhOAk0iV6fI/ > <https://mailarchive.ietf.org/arch/msg/cose/Cv-UumRRmmXWzrDHAhOAk0iV6fI/> > > The two open issues (IMHO) are: > > > 1. Should we make the kem_id in the encapsulated_key structure mandatory, > as Laurence suggested. > 2. Should we avoiding the polymorphic approach for the encapsulated_key > registration, as Daisuke suggested. > > To make it easier to understand these two issues, let me point you the > current version of the PR: > https://github.com/cose-wg/HPKE/blob/9914fa6f84b28046ee29762551798760dbaa3b7f/draft-ietf-cose-hpke.md > > <https://github.com/cose-wg/HPKE/blob/9914fa6f84b28046ee29762551798760dbaa3b7f/draft-ietf-cose-hpke.md> > > Regarding issue#1, we are talking about changing the encapsulated_key > structure > > from > > encapsulated_key = [ > kdf_id : uint, ; kdf id > aead_id : uint, ; aead id > enc : bstr, ; enc > ? kem_id : uint, ; kem id > ] > > to: > > encapsulated_key = [ > kdf_id : uint, ; kdf id > aead_id : uint, ; aead id > kem_id : uint, ; kem id > enc : bstr, ; enc > ] > > > Regarding issue#2, the change relates to how the encapsulated_key structure > is registered in the COSE IANA registry (under COSE header parameters). > > Change from: > Name: encapsulated_key > Label: TBD2 (Assumed: -4) > Value type: bstr / [any] / { any => any } > Value Registry: N/A > Description: Encapsulated key for KEM-like algorithms > To: > Name: encapsulated_key > Label: TBD2 (Assumed: -4) > Value type: Array > Value Registry: N/A > Description: Encapsulated key for KEM-like algorithms > > In a future, if the HPKE gets extended to algorithms that are not compatible > with the encapsulated_key structure then a new one has to be defined due to > the lack of extensibility of the array and its fixed set of fields. > > Your feedback will be valuable and allows me to resubmit a new draft version. > > 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 > <https://www.ietf.org/mailman/listinfo/cose>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
