+1 as well Mike Prorock mesur.io
On Wed, Jan 11, 2023, 10:54 Orie Steele <[email protected]> wrote: > > On Wed, Jan 11, 2023 at 10:44 AM Laurence Lundblade <[email protected]> > wrote: > >> 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). >> > > I agree. > > >> 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/ >> >> 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 >> >> 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] >> https://www.ietf.org/mailman/listinfo/cose >> >> >> _______________________________________________ >> COSE mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/cose >> > > > -- > *ORIE STEELE* > Chief Technical Officer > www.transmute.industries > > <https://www.transmute.industries> > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
