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
