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
