Hi Orie, Let's set aside the discussion about new key types for now. It's not related to this thread's topic for "alg".
In my previous email, I highlighted the advantages of the current draft in 6 points compared to your proposal. I'd like to hear the counterarguments to each topic. > ... but following the conventions and fully specifying HPKE with alg, should be resolved first. I am asserting that your proposal does not follow the conventions of COSE. > COSE HPKE will need to update registries, so let's make the minimal updates necessary to support what the industries wants to use. "Firmware Encryption with SUIT Manifests" is at the industry layer, while COSE-HPKE is at the generic layer. > We don't need to expose a new way to parameterize alg. "hkc" is not a parameterized alg. > If we don't know which alg values for COSE HPKE need to be registered, we can wait till people show up who do. Since we don't know it, the current specification that accepts everything is sufficient. There are no problems at all. > A simple RFC that follows conventions doesn't take long to update the registry. It might be simple, but it's clearly a waste of effort. Best, Daisuke 2023年6月7日(水) 21:25 Orie Steele <[email protected]>: > +1 > > HPKE should work without creating new key types for dh kems, and should > work with existing APIs that currently generate keys and envelopes based on > alg. > > A single equality check should confirm if the suite is acceptable to the > recipient, if they have a restricted key. > > The size and expression of the alg value, should be debated, but following > the conventions and fully specifying HPKE with alg, should be resolved > first. > > COSE HPKE will need to update registries, so let's make the minimal > updates necessary to support what the industries wants to use. > > We don't need to create new key types. > > We don't need to expose a new way to parameterize alg. > > If we don't know which alg values for COSE HPKE need to be registered, we > can wait till people show up who do. > > A simple RFC that follows conventions doesn't take long to update the > registry. > > OS > > On Wed, Jun 7, 2023, 6:20 AM Carsten Bormann <[email protected]> wrote: > >> > First and foremost, under the current COSE-HPKE spec, the addition of >> new algorithms to HPKE has no effect on COSE-HPKE, and it is possible to >> use the new HPKE algorithms as they are. >> > >> > What exactly are we trying to gain by putting in such effort? >> > >> > Please tell me the advantages you see over the current COSE-HPKE spec. >> >> I’m interested in reducing the “special snowflake” grade of HPKE. >> So I would like to add HPKE as a set of algorithms, instead of defining >> several new data structures that are necessary to use HPKE as well as to >> express keys for HPKE. >> >> (Besides, we save a few bytes, which may or may not be relevant for a >> specific application.) >> >> 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
