I agree with all of that but the first step is to confirm the high-level direction.
Once the high level direction is confirmed, I am sure we can quickly work out the details. You, Carsten and others have proposed solutions already. We need to make this first step asap. If we wait till the IETF meeting we need to do the confirmation on the mailing list pushing the decision making into the holiday period... Ciao Hannes Am 20.07.2023 um 14:39 schrieb Orie Steele:
There needs to be an integer / string value for alg. It needs to work with keys and envelopes. It needs to express an HPKE suite, which is a combination of details which become irrelevant once named properly. It's not that these details don't matter, it's that the average developer doesn't need to know them to use HPKE. Here are the APIs a developer needs: 1. K = Gen(alg) 2. CT = Encrypt(alg, k.Public, PT) 3. PT = Decrypt (alg, k.Private, CT) Notice that when alg specifies HPKE properly, a single integer or string is enough to satisfy these. In the case that the key representation carries the alg, it can be ommited from 2 and 3. This is also the case if you discover alg separately from the key. The goal is make discovery and use of hpke as simple as possible. You just compare a string or integer that a recipient supports, to a list of strings or integers you support. This comparison tells you all you need, to use HPKE, with parties that support it. There are other ways to do this. They are not as good, and they break conventions. OS On Thu, Jul 20, 2023, 6:10 AM Hannes Tschofenig <[email protected]> wrote: Hi Carsten, part of the problem is that quickly get lost in details while we should actually stay at the high level. The disagreement is at the highest level. This is not even a new topic: the concept of algorithm registration in security protocol is around for 30 or so years. Ciao Hannes Am 20.07.2023 um 12:21 schrieb Carsten Bormann: > Hi Hannes, > > I’m afraid this is even more confusing than your last note. > >> On 2023-07-20, at 11:48, Tschofenig, Hannes <[email protected]> wrote: >> >> Hi Mike, >> >> Here is the question the working group is facing. >> >> Should there >> • be a single value associated with the combination of KEM, KDF, and AEAD, or > “The” combination? Each combination? All combinations? > (Which means there is an additional data item containing the specific combination.) > >> • individual values for each of them. > Individual *data items*, with values defined for each to be used in combination for those additional data items? > >> The former design is often called ciphersuite. > Is “former” (a)? If (a) says “each specific combination”, I can parse that. > >> We used (a) in earlier versions of the COSE-HPKE draft (see, for example, draft-ietf-cose-hpke-01 ) and (b) in later versions of the draft (see, for example, draft-ietf-cose-hpke-05). >> >> Based on my assessment of the feedback from the group, there is a preference to switch back to the ciphersuite approach. > Right. > > (And I have made a proposal to more or less solve the biggest problem with ciphersuites, but that is somewhat orthogonal.) > > Grüße, Carsten > > > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
