On Mon, Jan 30, 2023 at 01:41:13PM -0600, Orie Steele wrote:
> Thank you for doing this.... It is extremely helpful.
>
> I really value the examples in the appendix.
>
> I also agree that we should solve for HPKE related key representations for
> COSE and JOSE consistently, and holistically.
>
> As was discussed previously, there is potential confusion regarding `kty`
> and `alg` for HPKE.
>
> The examples you provide highlight this clearly:
>
> {
> "kty": "OKP", // as expected per:
> https://www.rfc-editor.org/rfc/rfc8037#appendix-A.6
> "kid": "01",
> "crv": "X25519",
> "alg": "HPKE-v1-Base", // previously maybe ECDH-ES+A256KW ... See
> https://www.rfc-editor.org/rfc/rfc8037#appendix-A.6
> "hkc": {
> "kem": 0x020,
> "kdfs": [0x001, 0x002, 0x003],
> "kems": [0x001, 0x002]
> },
> "x": "y3wJq3uXPHeoCO4FubvTc7VcBuqpvUrSvU6ZMbHDTCI"
> }
I think using OKP this way is just pointless, one could just as well
use HPKE-KEM keys for this. (The same is not true for EC2 HPKE keys,
because keys can be decompressed.)
In the present proposal, the only changes would be changing kty to
"HPKE-KEM" and dropping "crv". Even the encoding of the public key
blob turns out to be the same.
> {
> "kty": "HPKE-KEM", // previously OKP ... See
> https://www.rfc-editor.org/rfc/rfc8037#appendix-A.7
> "kid": "01",
> "alg": "HPKE-v1-Base", // previously ECDH-ES+A256KW ... See
> https://www.rfc-editor.org/rfc/rfc8037#appendix-A.7
> "hkc": {
> "kem": 0x021,
> "kdfs": [0x001, 0x002, 0x003],
> "kems": [0x001, 0x002]
> },
> "pub":
> "IkLmc0klvEMXYneHMKAB6ePohryAwAPVe2pRSffIDY6NrjeYNWVX5J-fG4NV2OoU77C88A0mvxI",
> *// why not x ?*
> "priv":
> "rJJRG3nshyCtd9CgXld8aNaB9YXKR0UOi7zj7hApg9YH4XdBO0G8NcAFNz_uPH2GnCZVcSDgV5c"
> *// why not d ?*
> }
I think "pub" and "priv" are better names than "x" and "d" (which don't
even reflect how HPKE presently operates, let alone in the future). If
one wanted one letter names, then I think "p" and "s" would be the best
ones.
> There was some discussion on this previously:
> https://mailarchive.ietf.org/arch/msg/cose/r4nzABx8F3RHQ_Kb1jYisBm5l3M/
>
> Things I like:
>
> `hkc` encapsulates a lot of registration complexity... these are
> parameterized of the "alg" registered IMO.
> "alg": "HPKE-v1-Base" ... I like this framing, since it works without
> needing to add a new `kty`... *in other words, it works with existing
> registry entries for kty.*
>
> Things that concern me a bit:
>
> "kty": "HPKE-KEM"
>
> In practice, I would expect this to apply to DHKEMs, Kyber KEMs, and any
> future KEMs... and yet, each of these key types are different ... Many are
> already registered.
It does not apply to those. Pretty much the entiere COSE-HPKE is about
how to encode raw inputs or outputs of HPKE library. RFC 9180 says
substantial amounts about how such library should look like.
DHKEMs, Kyber KEMs and future KEMs are very different from that. The
keyshapes are different, and fundamential constraint in both COSE and
JOSE is that different keyshapes must have different kty's.
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
