> > 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.)
I understand it's pointless but I thought it would be more consistent to support all existing key types. I know this is controversial. 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. +1 > 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. To my understanding, HPKE was designed to be able to support many KEMs, including all the NIST finalists for post-quantum public-key encryption ( https://csrc.nist.gov/News/2020/pqc-third-round-candidate-announcement). So I think that HPKE-KEM kty can apply to the future KEMs (including Kyber) that can be handled by the interfaces defined in RFC9180. Best, AJITOMI Daisuke 2023年1月31日(火) 18:26 Ilari Liusvaara <[email protected]>: > 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 >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
