Hi! Seems like a necessary thing. Glad you are doing it.
The sole stated purpose of the “alg” parameter in RFC 9052 is to restrict the use of the key to that algorithm. 9052 says, "Key usage restriction to this algorithm” This draft presents it for use as algorithm negotiation. It says, "In HPKE, the sender of a ciphertext needs to know in advance not only the recipient public key, but also the HPKE mode, the KEM associated with the key, and the set of supported KDF and AEAD algorithms”. COSE has all the same algorithm negotiation issues before it supported HPKE. COSE discusses algorithm negotiation in the profiles section: "Applications may need to provide some type of negotiation or discovery method if multiple algorithms or message structures are permitted." At the moment I can’t see any problem with use of the “alg” parameter for negotiation even though 9052 doesn’t mention that. But, I think “alg" MUST also specify restriction as that is the standardized stated purpose of the “alg” parameter. It seems to me that the new hkc (HPKE Key Configuration) parameter/structure is basically an extension/detail of the “alg” parameter. That seems like the right thing to do here. I believe that as an extension of the “alg” parameter its purpose must be to restrict the key use to the algorithms in the hkc (HPKE Key Configuration) parameter / structure)… The recipient MUST verify the algorithms in hkc (HPKE Key Configuration) matches and if they don’t match the key MUST NOT be used. Curiously, 9052 only allows on algorithm to be specified per key. This draft allows for multiple HPKE algorithms (one KEM, multiple KDFs and multiple AEADs). Seems a little out of line from 9052, but that seems OK given the nature of HPKE. This document is standards track. It kind of makes normative reference to HPKE which is not standards track. That seems like it might be allowed, but a bit of a stretch. Personally, I’d like to see HPKE in a standards track document, but it seems unlikely that will happen before this document gets published, so this document either has to be information or we have to be OK with the downref. LL > On Jan 29, 2023, at 1:54 PM, AJITOMI Daisuke <[email protected]> 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. > > Best regards, > AJITOMI Daisuke > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
