[Chair hat on]
I’ll note that the COSE working group is already the party defining
post-quantum algorithm representations for COSE (and JOSE). See the working
group draft
https://www.ietf.org/archive/id/draft-ietf-cose-post-quantum-signatures-00.html.
-- Mike
From: COSE <[email protected]> On Behalf Of Hannes Tschofenig
Sent: Thursday, September 29, 2022 7:48 AM
To: Richard Barnes <[email protected]>
Cc: [email protected]
Subject: Re: [COSE] COSE_Key for HPKE encapsulated key
My point is that it is very likely that someone will want to introduce PQC
algorithms in COSE as well.
Ciao
Hannes
From: Richard Barnes <[email protected]<mailto:[email protected]>>
Sent: Thursday, September 29, 2022 3:54 PM
To: Hannes Tschofenig
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [COSE] COSE_Key for HPKE encapsulated key
The "enc" outputs aren't public keys for PQ algorithms, though. Don't get
mixed up.
On Thu, Sep 29, 2022 at 9:45 AM Hannes Tschofenig
<[email protected]<mailto:[email protected]>> wrote:
It is highly likely that people will define public key formats for all PQC
algorithms. Hence, the same issue will surface there as well.
The point compression was something Ilari brought up and less interesting to me.
From: COSE <[email protected]<mailto:[email protected]>> On Behalf Of
Richard Barnes
Sent: Thursday, September 29, 2022 3:35 PM
To: Hannes Tschofenig
<[email protected]<mailto:[email protected]>>
Cc: [email protected]<mailto:[email protected]>
Subject: Re: [COSE] COSE_Key for HPKE encapsulated key
Hey Hannes,
What you are saying is only true with HPKE used with ECDH, not HPKE in general
(e.g., with Kyber). If you design a COSE thing that treats "enc" as a public
key, then it will only apply to ECDH, not HPKE in general.
To the point (heh) about point compression: Whatever the HPKE mechanism is,
it's going to need a way to specify the public-key algorithm. If you wanted to
declare a public key algorithm that was effectively, "P-256 but you translate
the 'enc' value to a compressed point", that would be fine, since (1) that's
scoped to a specific algorithm and (2) it leaves the HPKE logic unchanged, it
just adds a compress/decompress step.
--RLB
On Thu, Sep 29, 2022 at 5:34 AM Hannes Tschofenig
<[email protected]<mailto:[email protected]>> wrote:
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]<mailto:[email protected]>> On Behalf Of
Richard Barnes
Sent: Wednesday, September 28, 2022 7:59 PM
To: [email protected]<mailto:[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.
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.
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
