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
