Inline: On Tue, Jan 31, 2023 at 5:37 AM AJITOMI Daisuke <[email protected]> wrote:
> 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. > Yes, and I do agree with this approach if it has the consensus and support of the wg... It seems the structure of JOSE and COSE key formats is perhaps too backward facing. Both were created at a time when secp256r1 was used for ECDSA and ECDH.... Most of the newer public key cryptosystems do only 1 thing: curve25519 for ECDH ed25519 for EdDSA kyber for KEMs secp256k1 for ECDH, ECDSA, Schnorr ... (maybe let's not speak of it further : ) When I first learned of HPKE and KEMs, I thought of them as algorithms... but what they really are is a nice way to update all the key agreement capable public key representations to have a single `kty`. It's a chance to set new conventions for post quantum keys. We can get rid of x and d, and replace them with safer labels. We don't need IANA registries for "key types" any more, we can just use the IANA registry for HPKE for all new key types, and then do something similar for signature schemes? If this is indeed the direction folks are wanting to go, I can see a lot of improvements possible. Leveraging the representations of the past, is perhaps not a good design goal for HPKE... Since it prevents us from making the safety and developer experience improvements we could otherwise make. dropping kty: EC and kty: OKP for kty: HPKE-KEM can make things simpler for developers, who do not need to know if they are operating on a lattice or a curve, as long as they use the right kem id. You can drop the "crv" value, since its implied by kem id (your example already does this): https://www.rfc-editor.org/rfc/rfc9180.html#name-dhkemx25519-hkdf-sha256-hkd Now folks will need to search on "kem id" to find all the keys associated with a potential key type or algorithm issue. It would be nice to see recommended or prohibited added, given that DHKEMs might end up toast in the future: https://www.rfc-editor.org/rfc/rfc9180.html#kemid-values All this to say, I'm not opposed to opening this door, I just want to be certain it will stay open before going through it. ... and I'm also interested in how this might change the future of keys used for signatures. > 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> >> > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
