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.
--RLB
>
>
> {
> "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.
>
>
>
> -Ilari
>
> _______________________________________________
> jose mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/jose
>
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
