+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
