Hi Orie, I also agree that we should solve for HPKE related key representations for > COSE and JOSE consistently, and holistically.
Thanks. I feel the same way. 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. We've had this same conversation before but I aim to make new KEMs, including Kyber, available for JWK and COSE_Key as soon as they are registered in the HPKE IANA registry. I am against standardizing JWK and COSE_Key expressions for every post-quantum KEM such as Kyber if it is assumed to be used in HPKE. Best, AJITOMI Daisuke 2023年1月31日(火) 4:41 Orie Steele <[email protected]>: > 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" > } > > > { > "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 ?* > } > > 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. > > For example, kty : EC, OKP, "Kyber", etc... I wrote a draft for kyber > trying to align it with the post quantum signatures draft: > https://datatracker.ietf.org/doc/draft-steele-cose-kyber/ > > This is the most challenging part of understanding how IETF intends for > folks familiar with JOSE and COSE to upgrade to HPKE.... > > We need to make sure communication on this point is clear. > > I don't yet feel that we have clarity on how `kty` and `alg` are supposed > to be used at IETF... > > Possibly we now have confusion over JOSE and COSE... and adding HPKE to > the mix is making this problem more pressing. > > There are "many" paths forward, but which one is correct or > "recommended"... that part is not clear to me. > > Regards, > > OS > > > > On Mon, Jan 30, 2023 at 6:00 AM AJITOMI Daisuke <[email protected]> wrote: > >> Hi Ilari, >> >> Thanks for your quick review. >> >> - HPKE is not standardized (and AFAIK, IRTF is not allowed to >>> standardize anything). It is informational RFC, intended to be used >>> as a building block. >> >> >> You are referring to the first sentence of the Introduction. Thank you >> for pointing this out. I will revise the wording. >> >> - For EC2 or OKP keys, there is possibility that there are multiple >>> valid KEM values. For example, due to future compact curves (EC2 >>> only) or SHA-3 support. The first seems very likely, the second seems >>> unlikely. >> >> >>> For HPKE-KEM, supporting multiple KEMs would be very annoying, so >>> one can restrict to a single KEM. >> >> >> I was also aware of this point, which is why only one KEM can be >> specified. >> >> - I don't think one can specify default value for alg outside definition >>> of kty itself, as key parameters can not be critical. >> >> >>> After all, if one feeds key with hkc but not alg to an old COSE >>> implementation (that does not support HPKE), it will probably happily >>> use the existing ECDH-ES mechanism (that the recipient may or may not >>> be able to handle). >> >> >> It is true that the alg cannot be omitted when it's used with an >> existing key type. I'll fix it. >> >> - I think the hkc stuff should be inlined for HPKE-KEM keys, as kem >>> (which is always a single value) is now very important as it subtypes >>> the key (all the existing kty's which have subtypes always have the >>> subtype at top level). >> >> >> I wondered whether the hkc should be inlined or not and I thought it >> would be fine either way. >> >> However the opinion that "kem" should be at the top level might be taken >> into account. >> >> - The JOSE stuff seems premature. I don't think there is any serious >>> proposal on how to integrate HPKE, and the COSE-HPKE stuff does not >>> port over, due to compact representation working differently and the >>> alg/enc split (plus probably some more details). >> >> >> I don't think the definition for JWK is premature. >> >> From my point of view, JWK is not only for JOSE. It can be used with COSE >> and it can be used for various web applications. That's why I have not used >> the term "JOSE" in this draft. >> >> An example of the widespread use of COSE is the EUDCC (EU Digital COVID >> Certificate), where public keys were published in JWK format via JWKS >> endpoints in European countries, rather than in COSE_Key format. >> >> - The PSK and AUTH modes seem premature: >>> * Auth modes require rather different usage from non-auth modes >>> to avoid significant attacks. This would likely even show up in >>> sender structures. >>> * I don't think anyone what a worked out proposal for adding PSK modes >>> to COSE. I only went so far as to observe it would need a new header >>> parameter. >> >> >> I don't know if it's premature, but at least I think neither the PSK nor >> the public key of the sender for authentication is relevant to the HPKE Key >> configuration information (or HPKE recipient information) defined in this >> draft. >> >> Both of them should be implicitly shared by other means so I think >> defining "alg"s for all HPKE modes would not cause any major problems. >> >> - Section 4.2. "Key Type for COSE_Key" seems to have copypasted from >>> the corresponding JOSE text without chagning base64url to bstr. >> >> >> Oops, I made a mistake. I'll fix it. >> >> Best, >> AJITOMI Daisuke >> >> >> 2023年1月30日(月) 18:07 Ilari Liusvaara <[email protected]>: >> >>> On Mon, Jan 30, 2023 at 05:54:30AM +0900, AJITOMI Daisuke wrote: >>> > Hi folks, >>> > >>> > Last weekend I submitted an Internet-Draft entitled "COSE Key and JSON >>> Web >>> > Key Representation for Key Encapsulation Mechanism (KEM) of Hybrid >>> Public >>> > Key Encryption (HPKE)". >>> > >>> > >>> https://datatracker.ietf.org/doc/draft-ajitomi-cose-cose-key-jwk-hpke-kem/ >>> > >>> > The COSE-HPKE under discussion defines the information including an >>> > encapsulated key sent from the sender to the recipient (HPKE sender >>> > information), but on the other hand, the sender needs to know the >>> recipient >>> > public key and HPKE key configuration information (KDFs/AEADs >>> supported by >>> > the recipient, etc.) beforehand. >>> > >>> > I thought this information (HPKE recipient information, so to speak) >>> was >>> > worth expressing in COSE_Key and JWK and I wrote this draft. >>> > >>> > Maybe it's controversial, but this draft defines (1) a common key >>> parameter >>> > for defining the HPKE key configuration information in existing key >>> types >>> > that can be used for key derivation ("EC" and "OKP") and (2) a generic >>> key >>> > type for HPKE that can also be used to represent post-quantum KEMs to >>> be >>> > defined in the future. >>> > >>> > I would very much appreciate your comments. >>> >>> Some comments: >>> >>> - HPKE is not standardized (and AFAIK, IRTF is not allowed to >>> standardize anything). It is informational RFC, intended to be used >>> as a building block. >>> >>> - For EC2 or OKP keys, there is possibility that there are multiple >>> valid KEM values. For example, due to future compact curves (EC2 >>> only) or SHA-3 support. The first seems very likely, the second seems >>> unlikely. >>> >>> For HPKE-KEM, supporting multiple KEMs would be very annoying, so >>> one can restrict to a single KEM. >>> >>> - If compact NIST stuff gets added to HPKE, there is no longer guarantee >>> there is unique KEM for EC2 keys, as the keys could be used >>> >>> - I don't think one can specify default value for alg outside definition >>> of kty itself, as key parameters can not be critical. >>> >>> After all, if one feeds key with hkc but not alg to an old COSE >>> implementation (that does not support HPKE), it will probably happily >>> use the existing ECDH-ES mechanism (that the recipient may or may not >>> be able to handle). >>> >>> - I think the hkc stuff should be inlined for HPKE-KEM keys, as kem >>> (which is always a single value) is now very important as it subtypes >>> the key (all the existing kty's which have subtypes always have the >>> subtype at top level). >>> >>> - The JOSE stuff seems premature. I don't think there is any serious >>> proposal on how to integrate HPKE, and the COSE-HPKE stuff does not >>> port over, due to compact representation working differently and the >>> alg/enc split (plus probably some more details). >>> >>> - The PSK and AUTH modes seem premature: >>> * Auth modes require rather different usage from non-auth modes >>> to avoid significant attacks. This would likely even show up in >>> sender structures. >>> * I don't think anyone what a worked out proposal for adding PSK modes >>> to COSE. I only went so far as to observe it would need a new header >>> parameter. >>> >>> - Section 4.2. "Key Type for COSE_Key" seems to have copypasted from >>> the corresponding JOSE text without chagning base64url to bstr. >>> >>> >>> >>> -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 >> > > > -- > *ORIE STEELE* > Chief Technical Officer > www.transmute.industries > > <https://www.transmute.industries> >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
