Hi Richard, there are already structures in COSE for describing a public key. The information HPKE exposes is a public key (plus other things).
Hence, the question is therefore: How many ways do we need to encode public keys in COSE? The reason for proposing this document to the group was the use case we had in SUIT. SUIT is about firmware updates for IoT devices. The HPKE libraries you list below are probably written for Web use cases. Here is the library I have been working on: https://github.com/Mbed-TLS/mbedtls/pull/5078 If you think the output of the pseudo HPKE API should also be sent over the wire then the HPKE RFC maybe should not have said that it does not define a wire protocol. Ciao Hannes From: COSE <[email protected]> On Behalf Of Richard Barnes Sent: Wednesday, September 28, 2022 7:59 PM To: [email protected] Subject: [COSE] COSE_Key for HPKE encapsulated key Hi all, It was brought to my attention that this working group is considering representing the "enc" output of HPKE as a COSE_Key as opposed to an opaque byte string [1]. This is a category error and a bad idea. HPKE defines the encapsulated key to be a byte string. It is **coincidentally** a serialized public key with DHKEM. All the HPKE libraries I could find correctly produce an opaque byte string for the "enc" output: Reference implementation: https://github.com/cisco/go-hpke/blob/master/hpke.go#L382 Chrome/BoringSSL: https://boringssl.googlesource.com/boringssl/+/refs/heads/master/include/openssl/hpke.h#213 Firefox/NSS: https://searchfox.org/mozilla-central/source/security/nss/lib/pk11wrap/pk11hpke.c#41 Webex/MLSpp: https://github.com/cisco/mlspp/blob/main/lib/hpke/include/hpke/hpke.h#L198 Representing the "enc" output as anything other than opaque bytes is a mistake. It would require the COSE implementation to parse the "enc" output, causing a bunch of unnecessary work and inviting error. (If you want to represent it as opaque bytes plus some metadata, sure. But But don't parse it.) I'm not sure which of the chairs' options that maps to, but both the COSE_Key and Ilari's OKP proposal look incorrect to me, because they both imply that the value is a key. I think Daisuke Ajitomi's proposal is closer to correct. In any case, I hope this helps clear things up. --Richard [1] https://mailarchive.ietf.org/arch/msg/cose/qzYaUCkogRSt53A3oCaTe-IwQDI/ IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
