Hi Mike, > The “alg” values are for consumption by code – not people. The IANA > registrations are for consumption by people, and are fully descriptive.
While that is true, there are limits. > Also, this language from > https://www.rfc-editor.org/rfc/rfc7518.html#section-1 applies: > “Names defined by this specification are short because a core > goal is for the resulting representations to be compact.” Compact does not mean everything is as small as possible. We just dont need to use a sentence. For example, we don't have 1 letter header names and number all the possible values from 1 to 100. Then we could have a=15 and save even more space. (That is a ridiculous example, but my point is that there is a tradeoff for readability and understanding by humans.) If a few bytes matters to the application, then it should use compression for the transport/storage or in the body of the JWE. I also think that applications where it does matter are likely already using compression so a shorter name would have no material impact. Or these applications are not going to use HPKE and use another algorithm with smaller values. Regards, -matt > On Dec 12, 2024, at 9:02 AM, Michael Jones <michael_b_jo...@hotmail.com> > wrote: > > The “alg” values are for consumption by code – not people. The IANA > registrations are for consumption by people, and are fully descriptive. > > Also, this language from > https://www.rfc-editor.org/rfc/rfc7518.html#section-1 applies: > “Names defined by this specification are short because a core > goal is for the resulting representations to be compact.” > > -- Mike > > From: Matt Chanda <cha...@apple.com> > Sent: Thursday, December 12, 2024 6:44 AM > To: Orie Steele <orie@transmute.industries> > Cc: Michael Jones <michael_b_jo...@hotmail.com>; Simo Sorce > <s...@redhat.com>; tirumal reddy <kond...@gmail.com>; jose@ietf.org; cose > <c...@ietf.org> > Subject: Re: [jose] JOSE HPKE algorithm identifiers > > Hello! > > Similar to Simo, I'm a hard no on the short names. I prefer the longer names > because I value clarity and readability over saving a few bytes. Although it > can be looked up, it is abstracted too much from the underlying algorithm. > > Regards, > -matt > > > > On Dec 12, 2024, at 8:00 AM, Orie Steele <orie@transmute.industries > <mailto:orie@transmute.industries>> wrote: > > Here are the same name changes, proposed in COSE HPKE: > > https://github.com/cose-wg/HPKE/pull/60 > > OS > > On Thu, Dec 12, 2024 at 7:26 AM Michael Jones <michael_b_jo...@hotmail.com > <mailto:michael_b_jo...@hotmail.com>> wrote: > https://github.com/ietf-wg-jose/draft-ietf-jose-hpke-encrypt/pull/12 creates > short algorithm identifiers, per the JOSE naming conventions > <https://www.rfc-editor.org/rfc/rfc7518.html#section-1>. It uses the names > proposed by Orie. > > > > -- Mike > > > > -----Original Message----- > From: Simo Sorce <s...@redhat.com <mailto:s...@redhat.com>> > Sent: Wednesday, December 11, 2024 1:21 PM > To: Orie Steele <orie@transmute.industries <mailto:orie@transmute.industries>> > Cc: tirumal reddy <kond...@gmail.com <mailto:kond...@gmail.com>>; Michael > Jones <michael_b_jo...@hotmail.com <mailto:michael_b_jo...@hotmail.com>>; > jose@ietf.org <mailto:jose@ietf.org> > Subject: Re: [jose] Re: JOSE HPKE algorithm identifiers > > > > On Tue, 2024-12-10 at 10:16 -0600, Orie Steele wrote: > > > Hey Simo, > > > > > > Can you say which format you prefer for proposed HPKE algorithms? > > > It is not clear which shortened proposal you are objecting to here. > > > > > > > I think HPKE-P256-SHA256-A128GCM is relatively clear. > > Otoh HPKE-P2-S2-A1 is difficult to read and will require a lookup table to > know what A1 or S2 or P2 actually are ... > > > > If size really is an issue we should go full abstract and use a label like > Addd (where ddd is digits, probably corresponding to the code COSE uses) and > not even try to have meaningful text labels. > > > > > OS > > > > > > On Tue, Dec 10, 2024 at 9:44 AM Simo Sorce <s...@redhat.com > > <mailto:s...@redhat.com>> wrote: > > > > > > > This would be a net regression, > > > > these areas are complicated enough that we do not need to add > > > > confusion to save a couple of bytes. > > > > > > > > On Fri, 2024-12-06 at 12:06 +0530, tirumal reddy wrote: > > > > > We can consider the short-form HPKE-P2-S2-A1. > > > > > > > > > > -Tiru > > > > > > > > > > On Fri, 6 Dec 2024 at 01:45, Michael Jones > > > > > <michael_b_jo...@hotmail.com <mailto:michael_b_jo...@hotmail.com>> > > > > > wrote: > > > > > > > > > > > Please see the discussion in the issue > > > > > > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2 > > > > > <https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%252> > > > > > Fgithub.com%2Fietf-wg-jose%2Fdraft-ietf-jose-hpke-encrypt%2Fissu > > > > > > es%2F8&data=05%7C02%7C%7C6fde9dccbc8b4bd1e81308dd1a29c4b5%7C84df > > > > > > 9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C638695488902911696%7CUnkn > > > > > > own%7CTWFpbGZsb3d8eyJFbXB0eU1hcGkiOnRydWUsIlYiOiIwLjAuMDAwMCIsIl > > > > > > AiOiJXaW4zMiIsIkFOIjoiTWFpbCIsIldUIjoyfQ%3D%3D%7C0%7C%7C%7C&sdat > > > > > > a=3pM%2Fw54gezD7hOfgzApDinZkFe8s4%2ByOyD3TYTdPw%2F8%3D&reserved= > > > > > > 0 > > > > (*Algorithm > > > > > > identifiers like HPKE-P256-SHA256-A128GCM are overly verbose*) > > > > > > and add your thoughts there. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks! > > > > > > > > > > > > > > > > > > -- Mike > > > > > > > > > > > > > > > > > > _______________________________________________ > > > > > > jose mailing list -- jose@ietf.org <mailto:jose@ietf.org> To > > > > > unsubscribe send an email > > > > > > to jose-le...@ietf.org <mailto:jose-le...@ietf.org> > > > > > > > > > > _______________________________________________ > > > > > jose mailing list -- jose@ietf.org <mailto:jose@ietf.org> To > > > > unsubscribe send an email to > > > > > jose-le...@ietf.org <mailto:jose-le...@ietf.org> > > > > > > > -- > > > > Simo Sorce > > > > Distinguished Engineer > > > > RHEL Crypto Team > > > > Red Hat, Inc > > > > > > > > _______________________________________________ > > > > jose mailing list -- jose@ietf.org <mailto:jose@ietf.org> > > > To unsubscribe send an email to jose-le...@ietf.org > > > <mailto:jose-le...@ietf.org> > > > > > > > > > > > > > -- > > Simo Sorce > > Distinguished Engineer > > RHEL Crypto Team > > Red Hat, Inc > > > > > > -- > > ORIE STEELE > Chief Technology Officer > www.transmute.industries <http://www.transmute.industries/> > <https://transmute.industries/> > _______________________________________________ > jose mailing list -- jose@ietf.org <mailto:jose@ietf.org> > To unsubscribe send an email to jose-le...@ietf.org > <mailto:jose-le...@ietf.org>
_______________________________________________ jose mailing list -- jose@ietf.org To unsubscribe send an email to jose-le...@ietf.org
