Here’s a clarification request. Here’s the proposal for the new kty:
4.2. Key Type for COSE_Key
A new generic kty(1) value HPKE-KEM(T.B.D.) is defined to represent
the private and public key used for the HPKE KEM. A key with this
kty has the following parameters:
* The parameter kty(1) MUST be HPKE-KEM(T.B.D).
* The parameter hkc(T.B.D.) MUST be present and contains the HPKE
Key Configuration defined in Section 3.2.1.
* The parameter pub(-1) MUST be present and contains the public key
encoded in a byte string (bstr type).
* The parameter priv(-2) MUST be present if the key is private key
and contains the private key encoded in a byte string (bstr type).
How will you know what the actual serializations for pub(-1) and priv(-2) will
be? They have to vary by KEM, right? For some KEMs those will be some EC key
serialization (there are a few choices I think) and for other some PQ key
serialization.
Also tried to figure out what Ilari’s 1212481536 is. Most KEM and curve IDs are
small integers.
LL
> On May 1, 2023, at 7:29 PM, AJITOMI Daisuke <[email protected]> wrote:
>
> > - I don’t think there should be a new kty for HPKE. There’s probably some
> HPKE-KEM ID and COSE_Key curve mapping, but I don’t think that requires a new
> kty.
>
> As Ilari mentioned repeatedly, I think it is a big problem that we have to
> bear the cost of both making a spec and making implementation changes
> whenever making a new KEM usable in COSE.
> These costs can be easily avoided by defining the key type HPKE-KEM, so I see
> no reason to oppose it from my perspective.
>
> AJITOMI Daisuke
>
> 2023年5月2日(火) 1:33 Laurence Lundblade <[email protected]
> <mailto:[email protected]>>:
> Hi folks,
>
> After we’ve worked through some of the details of
> draft-ajitomi-cose-cose-key-jwk-hpke-kem I have changed my mind and no longer
> support adoption. I think there is COSE work, but it should be in the
> COSE-HPKE draft. Any JOSE-related work should be done as part of the
> JOSE-HPKE work.
>
> My reasons:
>
> - Some of the things, like key_ops, belong in COSE-HPKE because they are
> characteristics of the COSE-HPKE integration not any change to COSE_key.
>
> - I don’t think there should be a new kty for HPKE. There’s probably some
> HPKE-KEM ID and COSE_Key curve mapping, but I don’t think that requires a new
> kty.
>
> - While algorithm negotiation/agreement/advert can be done with a COSE_Key,
> there are many use cases where it can’t because there is no COSE_Key or it
> makes more sense to do it as part of the application protocol layer.
>
> - That really only leaves the COSE_Key algorithm restriction. I believe that
> amounts to the definition of a new COSE_Key parameter, “hkc” and a few
> sentences.
>
> - It seems premature to do the JWK work until JOSE-HPKE is further along.
>
>
> I’m really glad that Ajitomi created this draft and spurred this work along
> even thought I don’t support the draft as is. It is important work and we’re
> better off for the efforts! Maybe Ajitomi is added as an author to COSE-HPKE
> if some of the text and CBOR is brought in?
>
> LL
>
>
> _______________________________________________
> COSE mailing list
> [email protected] <mailto:[email protected]>
> https://www.ietf.org/mailman/listinfo/cose
> <https://www.ietf.org/mailman/listinfo/cose>
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
