Yes, confirming high level direction. I support registering string / integer values for "alg" that fully specify how to use HPKE.
I object to registering "partial" or "polymorphic" values for "alg", that require extra stuff to be useful. OS On Thu, Jul 20, 2023 at 8:27 AM Hannes Tschofenig <[email protected]> wrote: > 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 <hannes.tschofenig= >> [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 [email protected]https://www.ietf.org/mailman/listinfo/cose > > -- ORIE STEELE Chief Technology Officer www.transmute.industries <https://transmute.industries>
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
