Hi Ilari, Thanks for bringing this topic up again.
There are two basic approaches for algorithm indication, namely crypto suites vs. ala carte. Currently, the draft contains the ala carte approach. It was my understanding that the group asked me to do this at the interim meeting in January. I might have misunderstood. So, we first have to decide what approach we want to use. There is no wrong approach here - it is just a preference. Let's assume we don't want the ala carte approach currently in draft and want to individually indicate * KEM * KDF * AEAD (Values are registered at https://www.iana.org/assignments/hpke/hpke.xhtml) The question then arises where to put those values. You are suggesting to go the "middle"-way by combining the KEM and the KDF and to put them into the crv (curve) parameter and to register the values into the COSE Elliptic Curve registry. I personally do not have a strong preference on where to put the values. I am soliciting preferences from the group. Ciao Hannes > 7) I think that combining all the HPKE algorithms into one ciphersuite > is a bad idea. > > While the KEM and KDF could be combined, trying to combine AEAD would > lead into combinatorial explosion, or worse, into broken > combinatorics, which are nasty to handle in any sort of sane way (see > TLS 1.0-1.2 ciphersuites). > > Even with KEM and KDF combined, present HKDF would give 15 different > ciphersuites. > > What I think should be done is just registering the HPKE AEADs as alg > values (there are 3 of those currently), and then having OKP crv's for > the combined KEM and KDF (there are 5 of those currently) in the key. > > That is, alg's like: > > - HPKE_AES_128_GCM (HPKE AEAD 1) > - HPKE_AES_256_GCM (HPKE AEAD 2) > - HPKE_ChaCha20Poly1305 (HPKE AEAD 3) > > And crv's like: > > - HPKE_P_256_HKDF_SHA256 (HPKE KEM 16 KDF 1) > - HPKE_P_384_HKDF_SHA384 (HPKE KEM 17 KDF 2) > - HPKE_P_521_HKDF_SHA512 (HPKE KEM 18 KDF 3) > - HPKE_X25519_HKDF_SHA256 (HPKE KEM 32 KDF 1) > - HPKE_X448_HKDF_SHA512 (HPKE KEM 33 KDF 3) > > > This also mirrors the internal structure of HPKE: Mixing and matching > AEADs is cryptographically kosher, while mxing and matching KDFs is > not (and it is not possible to fix this due to shortcomings of the > standard KEM interface). > IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
