I do agree that compression in the transport is the natural solution to base64url inflation of text based formats (like JSON). COSE / CBOR is also a better choice for use cases where size really matters. However, short names are easier to read, write and compare, and there is some aesthetic alignment to the tradition of JOSE which might be worth preserving, if we can get consensus to do so.
Regards, OS On Thu, Dec 12, 2024 at 9:34 AM Matt Chanda <[email protected]> wrote: > 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 <[email protected]> > 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 <[email protected]> > *Sent:* Thursday, December 12, 2024 6:44 AM > *To:* Orie Steele <[email protected]> > *Cc:* Michael Jones <[email protected]>; Simo Sorce < > [email protected]>; tirumal reddy <[email protected]>; [email protected]; cose < > [email protected]> > *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 <[email protected]> > 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 <[email protected]> > 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 <[email protected]> > Sent: Wednesday, December 11, 2024 1:21 PM > To: Orie Steele <[email protected]> > Cc: tirumal reddy <[email protected]>; Michael Jones < > [email protected]>; [email protected] > 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 <[email protected]> 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 > > > > > <[email protected]> > > > > > 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 -- [email protected] To unsubscribe send an email > > > > > > to [email protected] > > > > > > > > > > > _______________________________________________ > > > > > jose mailing list -- [email protected] To unsubscribe send an email to > > > > > [email protected] > > > > > > > > -- > > > > Simo Sorce > > > > Distinguished Engineer > > > > RHEL Crypto Team > > > > Red Hat, Inc > > > > > > > > _______________________________________________ > > > > jose mailing list -- [email protected] > > > > To unsubscribe send an email to [email protected] > > > > > > > > > > > > > > -- > > Simo Sorce > > Distinguished Engineer > > RHEL Crypto Team > > Red Hat, Inc > > > > > > -- > > > *ORIE STEELE*Chief Technology Officer > www.transmute.industries > <https://transmute.industries/> > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] > > > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list -- [email protected] To unsubscribe send an email to [email protected]
