We started with a COSE_Key representation for the enc output, see
https://mailarchive.ietf.org/arch/msg/cose/K8W5LBXjmPqsmSFO-RdbOh8hlUI/
https://mailarchive.ietf.org/arch/msg/cose/kI10B-xaIUFTeN2lZNXKsgYBMSs/
Then, we went into the domain of
- is it efficient:
https://mailarchive.ietf.org/arch/msg/cose/zg-PfuD2uUi_YgrOJ11wFpGiBbw/
- what does the HPKE RFC really mandate regarding the wire format:
https://mailarchive.ietf.org/arch/msg/cose/OQw-PQ_SgZDUGoolwCFuYffy61Y/
Since it was only me discussing with Ilari and Daisuke, I lost the
argument:
https://mailarchive.ietf.org/arch/msg/cose/oI_cRYbxTEo2Uwn7aXQV0dCmYtA/
Ciao
Hannes
Am 14.07.2023 um 17:39 schrieb lgl island-resort.com:
On Jul 14, 2023, at 8:13 AM, Tschofenig, Hannes
<[email protected]> wrote:
Hi Laurence,
the problem is that the enc is currently an opaque blob where the
format is determined by the implementation of the selected library.
This means that there is zero interoperability between different
implementations unless they happen to produce the same encoding.
I see this as a problem.
Well, yeah it has to interoperate.
Isn’t enc defined by RFC 9180 and doesn’t that give interop? As long
as all HPKE libraries produces / consume the same thing… Seems to me
that it can be something HPKE-specific as long as it interoperates.
LL
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
