> Why not use the existing okp key type with “alg”: “HPKE” or similar? You can define the additional HPKE-specific fields as you wish (although perhaps best to namespace them somehow to avoid conflicting with other future JWK extensions).
There are some reasons, but the simplest reason is that OKP requires crv (MUST be specified) but there is no need to use crv in HPKE. -- Daisuke 2022年9月22日(木) 23:03 Neil Madden <[email protected]>: > > On 22 Sep 2022, at 14:56, 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: > > > > > > { > > "kty": "HPKE", > > "kem": 32, > > "kdf": 1, > > "pub": "3p7bfXt9wbTTW2HC7OQ1Nz-DQ8hbeGdNrfx-FG-IK08" > > } > > > > kem 32 is X25519, kdf 1 is SHA-256. One could add "aead": 1 to hint the > > sender to use AES-128-GCM. > > > > Private keys have "priv" member containing base64url-encoded private > > key. > > > > > > This kind of format is totally generic for HPKE, requiring no > > maintenance. > > > > Why not use the existing okp key type with “alg”: “HPKE” or similar? You > can define the additional HPKE-specific fields as you wish (although > perhaps best to namespace them somehow to avoid conflicting with other > future JWK extensions). > > — Neil > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
