On Sun, Apr 23, 2023 at 12:59:08PM -0700, Laurence Lundblade wrote: > On Apr 22, 2023, at 12:54 AM, Ilari Liusvaara <[email protected]> > wrote: > > > > On Fri, Apr 21, 2023 at 06:15:31PM -0700, Laurence Lundblade wrote: > >> A couple of observations: > >> > >> HPKE isn’t an algorithm like RSA or the PQ algorithms or EC. It’s a > >> user of those algs (except RSA). We’re not defining new a key type the > >> way RFC 8230, RFC 8812 and RFC 9053 do. We already have the key types > >> to work with HPKE KEMs. Seems like the sole thing is to define how > >> alg restriction with the alg parameter works for HPKE. > > > > I do not think this is correct. > > > > - We do not have key tpyes to work with HPKE KEMs. All the current ones > > yes, but that is one expert review away from changing. In contrast, > > the HPKE kty truly offers key type for all HPKE KEMs. > > These are just key serialization formats. I don’t see why an expert > would disallow them or what the basis of that prohibition would be. > The threat that an expert will revoke use of key type with HPKE is > probably not a good strategy to win people over to HPKE. It makes me > look at the lack of policy and criteria for the HPKE IANA algorithm > registry with worry. It would also be hard to enforce any sort of > global prohibition.
I did not mean any prohibition or any sort of revocation. I meant, e.g., draft-cfrg-schwabe-kyber-01 getting approved in expert review. Afterwards, the present kty's are no longer sufficient. > I don’t want a new kty for HPKE. > - A new key type would bring the need for conversion to/from The new key type would directly encode values to/from HPKE, making the conversion trivial. All the other kty's require nontrivial conversion. - OKP needs remapping the crv value. - EC2 needs highly nontrivial conversion, including point decompression. -Ilari _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
