On Wed, Dec 11, 2024 at 12:52 PM Ilari Liusvaara <[email protected]> wrote:
> On Wed, Dec 11, 2024 at 11:44:47AM -0600, Orie Steele wrote: > > Right. > > > > I think the main thing we lose from going from 3 numbers to 1 is > > parsability. > > If the algorithms are meant to be treated as opaque strings / numbers and > > never parsed, then the single number approach (aligned with cose > > registration requests) seems like the best path forward to me. > > While it would be very nasty hack, the COSE numeric algorithm space is > large enough to embed the entire HPKE algorithm combination space (in > 9 byte range). > > I think some very hacky test code I wrote (not sure if it ever actually > wroked) stuffed HPKE algs into 0x4845000100010001 to 0x4845FFFFFFFFFFFE > range (4845 => HE). > > > Both draft-ietf-jose-hpke-encrypt and draft-ietf-cose-hpke need to have > concept of COSE-HPKE/JOSE-HPKE algorithm disjoint from any concrete > algorithm registrations those drafts make. > Please send text, ideally we can cite your text from both specs. > This is to avoid later drafts adding more algorithms from having to > effectively re-define COSE-HPKE/JOSE-HPKE (or leave a lot of interop- > critical stuff implicit). Not only is this overly tedious, it is also > very error-prone[1]. > > > [1] E.g, draft-ietf-jose-hpke-encrypt partially re-defines JWE Key > Encryption, and gets it wrong. > > > > > -Ilari > > _______________________________________________ > jose mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ jose mailing list -- [email protected] To unsubscribe send an email to [email protected]
