Hi Laurence, Thanks for your comments. I will think more about the description of alg and revise it (as Ilari also pointed out a mistake about alg).
... this document either has to be information or we have to be OK with the > downref. OHTTP and ECH are also standards track and I think the downref can be accepted. Best, AJITOMI Daisuke 2023年1月31日(火) 4:35 Laurence Lundblade <[email protected]>: > 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
