On Thu, Sep 22, 2022 at 11:30:37AM -0400, Richard Barnes wrote: > On Thu, Sep 22, 2022 at 9:57 AM Ilari Liusvaara <[email protected]> > wrote: > > > On Thu, Sep 22, 2022 at 07:49:06AM -0500, Orie Steele wrote: > > > I've been a part of some of those conversations, and I agree that if HPKE > > > is going to define a new key format, it should be possible to represent > > it > > > consistently across serializations... I suggest you share one of the JSON > > > like examples here to explain the concept, those really helped me grok > > it. > > > > A HPKE X25519 public key could look like: > > > > I wouldn't think you would have a key type for "HPKE", but rather, the > public key would be of a type suitable for the HPKE KEM. So if you were > using DHKEM, you would provide "kty": "EC". If you were using Kyber, some > "kty" to be defined.
That would greatly increase both specification and implementation complexity, as one would need to specify for every key type how to convert the keys into format suitable for HPKE, and the application code to actually perform those conversions, again for every supported key type. (And the key format of dedicated Kyber keys is exactly what OKP was designed for.) -Ilari _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
