Subject: [COSE] draft-ietf-cose-hpke-00 and proposed changes for -01

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Jan 2022 09:36:34 +0000

Hi all,

with draft-ietf-cose-hpke-00 I have submitted the draft version that was subject to the working group call for adoption.
John and Goeran provided feedback already and suggested to re-use the algorithm registry created by HPKE.

In https://github.com/cose-wg/HPKE/blob/main/draft-ietf-cose-hpke.txt the proposed -01 version can be found.

The diff is available here: http://tools.ietf.org//rfcdiff?url1=https://www.ietf.org/archive/id/draft-ietf-cose-hpke-00.txt&url2=https://raw.githubusercontent.com/cose-wg/HPKE/main/draft-ietf-cose-hpke.txt

Please have a look at it and let me know if the proposed changes are inline with the suggestions.

Ciao
Hannes

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.

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 17 Jan 2022 13:18:58 +0200

On Mon, Jan 17, 2022 at 09:36:34AM +0000, Hannes Tschofenig wrote:
> 
> with draft-ietf-cose-hpke-00 I have submitted the draft version that
> was subject to the working group call for adoption. John and Goeran
> provided feedback already and suggested to re-use the algorithm
> registry created by HPKE.
> 

In can make little sense of the way HPKE is used.

- Why are the symmetric and asymmetric parts of HPKE split into two
  different layers? The whole point of HPKE singleshot mode is to
  combine them.

- The layer 1 algorithm is specified as COSE encryption algorithm,
  but for actually performing the encryption/decryption, one needs
  HPKE AEAD ID.

  * How is the mapping between the two done?
  * If new AEAD is added to HPKE, does one also have to register COSE
    algorithm for it?

  Embedding the registry would mean 5 byte algorithm identifiers, as
  there is just not enough space with smaller ones (need continuous
  block of 65534 (sic) algorithm ids).

- Recipients at layer 1 are specified as one-or-more. AFAICT, more than
  one recipient here makes absolutely no sense.
  
- The algorithm ID at layer 2 needs new registrations to take advantage
  of new HPKE algorithms. This especially inclures KEMs, which are one
  of the most important extension points (post-quantum!).

- Decomposing the keys at layer 2 needs code changes to support new
  KEMs. Which likely can not be nontrivially decomposed anyway.

  However, currently HPKE does not have compact NIST curves, which
  allows space saving via decomposition.

  Compromise might be to embed the registries (both may be jointly
  embededed into 5 byte algorithm identifier) and have special values
  for decomposed stuff (and shorthands for X25519/X448).[1]

  If both KEM and KDF can be sepcified, the KDFs SHOULD be matched.

- HPKE is different enough that I think both new kty and a new
  operational mode are justified (I can make very little sense of
  existing operational modes).

- Doing HPKE with two layers with cose_encrypt, easily extends to
  doing HPKE in cose_encrypt0: The only difference is directly operating
  on the plaintext instead operating on the CEK. The limitation is
  only having one recipient.

[1]

E.g.:

- algid=-1 is like algid=0x00010010, but key is compressed like in C509.
- algid=-2 is like algid=0x00020011, but key is compressed like in C509.
- algid=-3 is like algid=0x00030012, but key is compressed like in C509.
- algid=-4 is alias for algid=0x00010020 (X25519 with SHA-256).
- algid=-5 is alias for algid=0x00030021 (X448 with SHA-512).

-Ilari

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 17 Jan 2022 14:51:13 +0000

Thanks for the detailed comments, Ilari.

Let me provide comments below:

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: Monday, January 17, 2022 12:19 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [COSE] draft-ietf-cose-hpke-00 and proposed changes for -01

[Hannes] We are adding another layer to allow for additional use cases.
The use case is to encrypt a payload once for different recipients.

[Hannes] Layer 2 uses the KEM algorithms from Section 7.1 of the HPKE spec:
https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-12#section-7.1

Layer 1 uses the COSE algorithms instead of the algorithms in Section 7.3 of the HPKE spec
https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-hpke-12#section-7.3

[Hannes] It is possible to re-use the AEAD ID values from the HPKE spec instead of the corresponding COSE algorithms.
However, there is not much of variation between the AEAD algorithms in COSE vs. the HPKE spec.

[Hannes] It makes sense if you consider the use of firmware encryption. There, you want to have one CEK to encrypt the firmware image but multiple recipients.

[Hannes] By re-using the HPKE registry the idea was to re-use new KEMs as they come along.

[Hannes] There is obviously a downside to the re-use of the HPKE registry, as you point out.
Splitting the registry into two appears quite complex to me. Adding new KEMs will, of course, require code changes.
We should indeed think carefully whether this registry re-use offers enough benefits to do it.

[Hannes] We are currently only using the base mode from the HPKE spec and utilize the COSE capabilities for authentication.
The kty is used to describe the encapsulated key and there is no difference in the keys.

[Hannes] If the group wants a variant of COSE-HPKE that supports hybrid public key encryption for a single recipient only then I will, of course, do it.
However, it is not clear to me whether this few additional bytes justify the extra variant. More variants = more complexity.

Ciao
Hannes

[1]

E.g.:

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 17 Jan 2022 18:37:25 +0200

> The use case is to encrypt a payload once for different recipients.

With HPKE, one could do that with two-layer structure (and even mix it
with other modes):

- Layer 0: Message
  - Layer 1: HPKE (CEK for recipient1)
  - Layer 1: HPKE (CEK for recipient2)
  - Layer 1: AES-KW (CEK)
    - Layer 2: ECDH-ES (KEK for recipient3)
  - Layer 1: AES-KW (CEK for recipient4)

That encrypts the message only once, for four recipients:

- recipient1 and recipient2 use HPKE (asymmetric).
- recipient3 uses ECDH-ES (asymmetric)
- recipient4 uses AES (symmetric).

> [Hannes] It is possible to re-use the AEAD ID values from the HPKE
> spec instead of the corresponding COSE algorithms. However, there is
> not much of variation between the AEAD algorithms in COSE vs. the HPKE
> spec.
 
However, using COSE algorithms requires implemntation to translate those
into HPKE algorithms. This is because key derivation depends on HPKE
algorithm ID.

> [Hannes] It makes sense if you consider the use of firmware encryption.
> There, you want to have one CEK to encrypt the firmware image but multiple
> recipients.

It seems that Layer1 is ciphertext and Layer2 is encapsulated key.

So using multiple recipients at this layer would seem to correspond with
trying to use multiple encapsulated keys with the same ciphertext. At
best this produces decryption errors. At worst, it produces corrupt
plaintext.

(HPKE does have multishot mode where the same encapsulated key is used
with multiple ciphertexts.)
 
> [Hannes] By re-using the HPKE registry the idea was to re-use new KEMs

Oh, the algorithm ID is HPKE KEM id. However, there is KDF id too.

For the present KEM algorithms, one could just match the KDF
(16 => 1, 17 => 2, 18 => 3, 32 => 1, 33 => 3), but this might not work
with future KEMs.

E.g., suppose Kyber v3.02 (one of the NISTPQC finalists) was added. 
What KDF does it use? None of the KDFs HPKE has (HKDF with SHA-2) are
in any way related to KDF Kyber internally uses (SHAKE256, which is
related to SHA-3).

> [Hannes] There is obviously a downside to the re-use of the HPKE
> registry, as you point out. Splitting the registry into two appears
> quite complex to me. Adding new KEMs will, of course, require code
> changes. We should indeed think carefully whether this registry re-use
> offers enough benefits to do it.

Well, yes, there are tradeoffs:

- Special processing like compressing keys requires special-casing
  codepoints.
- Reusing the registry means COSE does not have to deal with
  registration requests. :-)

(Add compact NIST curves to HPKE, and then one does not have to deal
with key compression anymore.)

And then HPKE support might be shipped as library, which can change
indepedently of main application, in order to add new algorithms.

> [Hannes] We are currently only using the base mode from the HPKE
> spec and utilize the COSE capabilities for authentication. The
> kty is used to describe the encapsulated key and there is no
> difference in the keys.

Actually, I got an idea that one could use OKP for raw HPKE
encapsulated keys, and other types for compressed encapsulated
keys (one probably only ever wants to compress P-256/P-384/P-521
encapsulated keys). And this would be independent of HPKE KEM
used.

One problem with that is the OKP crv parameter makes absolutely no
sense in such context. And it would not be quite as compact as
C509-style compression with special-case algorithm identifiers.

> [Hannes] If the group wants a variant of COSE-HPKE that supports
> hybrid public key encryption for a single recipient only then I will,
> of course, do it. However, it is not clear to me whether this few
> additional bytes justify the extra variant. More variants = more
> complexity.

Well, OTOH it seems to be pretty trivial to do. And yes, it is
very few bytes saved, rough guess would be a dozen or so.

-Ilari

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 18 Jan 2022 11:20:34 +0000

Hi Ilari,

Thanks for your review. I am focusing on the most important aspect here first.

> The use case is to encrypt a payload once for different recipients.

With HPKE, one could do that with two-layer structure (and even mix it with other modes):

- Layer 0: Message

[Hannes] I think you are suggesting to do this:

   96(
       [
           // protected field with alg=AES-GCM-128
           h'A10101',
           {    // unprotected field with iv
                5: h'26682306D4FB28CA01B43B80'
           },
           // null because of detached ciphertext
           null,
           [  // COSE_recipient_outer

             / protected / h'a1013818' / {
            \ hpke-alg \ 1:16 \ HPKE/P-256+HKDF-256 \
                    hpke-aead-id: 1     //     AES-128-GCM
             } / ,
            / unprotected / {
                // HPKE encapsulated key
                / ephemeral / -1:{
                       / kty / 1:2,
                 / crv / -1:1,
                 / x / -2:h'98f50a4ff6c05861c8...90bbf91d6280',
                  / y / -3:true
              },
            // kid for recipient static ECDH public key
            / kid / 4:[email-masked]'
               },
               // Encrypted CEK
               h'FA55A50CF110908DA6443149F2C2062011A7D8333A72721A',
               ]
           ]
        ]
   )

Instead of this:

   96(
       [
           // protected field with alg=AES-GCM-128
           h'A10101',
           {    // unprotected field with iv
                5: h'26682306D4FB28CA01B43B80'
           },
           // null because of detached ciphertext
           null,
           [  // COSE_recipient_outer
               h'',          // empty protected field
               {             // unprotected field with ...
                    1: 1     //     alg=A128GCM
               },
               // Encrypted CEK
               h'FA55A50CF110908DA6443149F2C2062011A7D8333A72721A',
               / recipients / [  // COSE_recipient_inner
                [
                  / protected / h'a1013818' / {
                      \ hpke-alg \ 1:16 \ HPKE/P-256+HKDF-256 \
                    } / ,
                  / unprotected / {
                    // HPKE encapsulated key
                    / ephemeral / -1:{
                      / kty / 1:2,
                      / crv / -1:1,
                      / x / -2:h'98f50a4ff6c05861c8...90bbf91d6280',
                      / y / -3:true
                    },
                    // kid for recipient static ECDH public key
                    / kid / 4:[email-masked]'
                  },
                  // empty ciphertext
                  / ciphertext / h''
                ]
               ]
           ]
        ]
   )

I constructed the variant in the draft based on my understanding of how the COSE author wants to use layering. If we can use a more optimized version, I am all for it.

Ciao
Hannes

---

From: Ilari Liusvaara <[email-masked]>
Date: Thu, 20 Jan 2022 19:49:13 +0200

>                h'FA55A50CF110908DA6443149F2C2062011A7D8333A72721A',

Yeah, thereabouts.

I am not sure what is the best precise variation to use.

- I would like there being generic support for all HPKE algorithms.
  The most compact way of doing this is:
  * Have new alg=hpke. Which has the AEAD id as parameter.
  * Have new kty=hpke. Which has the KEM and KDF ids as parameters,
    as well as raw public/encapsulated key.

  However, this runs into size issues with P-x curves.

  HPKE encapsulated key for KEM=33, KDF=2, would be roughly:

  -1:{
	1:<id-kty-hpke>,
	-1:33,
	-2:2,
	-3:h'...'
  }

  This would be 11 bytes of overhead, assuming typical PQC sizes.

- Solving the P-x size issues, option a):

  * With EC2, do not include explicit KEM and KDF ids.
  * The public keys are unpacked into public/encapsulated keys.
 
  Roughly corresponds to the above, but with no hpke-alg.

- Solving the P-x size issues, option b):

  * Use the HPKE kty, with negative KEM id.
  * Pack the P-x keys using the same compression as in C509.

  AFAICT, this is one byte more compact than a) with P-x keys.
  The ephemeral key would roughly be:

  -1:{
	1:<id-kty-hpke>,
	-1:-1
	-3:h'0398f50a4ff6c05861c8...90bbf91d6280'
  }

  For X25519 and X448, the both options above save 3 bytes.

And looks like I underestimated the space savings from cose_encrypt0
if one only has one recipient. The savings are more like 50 bytes or
so (more for 192-bit and 256-bit levels).

-Ilari

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 21 Jan 2022 13:15:50 +0000

Hi Ilari,

You are again raising good points, namely

1) Should we convey the KEM ID, and KDF ID explicitly? I think so.
2) If we do, where should this information go? You suggest to put them into the COSE key (ephemeral key) structure. I would have thought that the unprotected header would be more appropriate but I do not really have a strong preference.
3) Should we define a new kty id? If we place the KEM ID and the KDF ID into the COSE key structure then I think it would be a good idea to define a new kty id.

I am curious what others in the group think about this idea.

I lost you when you are were talking about the "size issues" and tried to solve the issues. Maybe you could elaborate a bit what problem you see. IMHO we cannot use COSE_Encrypt0 because we need the recipient structure, which is not present with the COSE_Encrypt0.

You also seem to define new key formats. What prevents us from re-using the existing COSE key formats? Section 13 of RFC 8152 defines various ECC key formats and those could be re-used. Since there is no compressed point format, we could add it.

I am also not sure why you talk about PQC algorithms. Neither COSE nor HPKE define PQC algorithms. Do you think we should define them in this document?

Ciao
Hannes

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: Thursday, January 20, 2022 6:49 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [COSE] draft-ietf-cose-hpke-00 and proposed changes for -01

Yeah, thereabouts.

  -1:{
        1:<id-kty-hpke>,
        -1:33,
        -2:2,
        -3:h'...'
  }

  -1:{
        1:<id-kty-hpke>,
        -1:-1

And looks like I underestimated the space savings from cose_encrypt0 if one only has one recipient. The savings are more like 50 bytes or so (more for 192-bit and 256-bit levels).

-Ilari

---

From: Ilari Liusvaara <[email-masked]>
Date: Fri, 21 Jan 2022 16:17:47 +0200

> 1) Should we convey the KEM ID, and KDF ID explicitly? I think so.

Well, I think that all HPKE algorithms should be supported in generic
way, so that COSE does not have to deal with registering HPKE algorithms
the second time.

> 2) If we do, where should this information go? You suggest to put 
> them into the COSE key (ephemeral key) structure. I would have
> thought that the unprotected header would be more appropriate but
> I do not really have a strong preference.

Well, for KDF id, one could stick it either inside ephemeral key
structure, or the main headers. However, I think that one will run
into cases where:

- KDF is implicit from KEM. E.g. KEM 17 is probably combined with
  KDF 2.
- KDF is not implicit from KEM. E.g. KEM 48 goes with KDF ???.

> 3) Should we define a new kty id? If we place the KEM ID and the
> KDF ID into the COSE key structure then I think it would be a
> good idea to define a new kty id.

Well, there are not just HPKE encapsulated keys, HPKE also has
public and private keys.

While reusing OKP for generic case would be possible (at cost
of a few bytes, since crv will be pushed to 5 byte territory),
I think new kty would be cleaner.

> I lost you when you are were talking about the "size issues" and tried
> to solve the issues. Maybe you could elaborate a bit what problem you
> see.

The size issue is that HPKE currently uses uncompressed P-256/P-384/
P-521. This makes public keys and ephemeral keys a few dozen bytes
larger than they should be if one uses NIST curves.

And I came up with two ways of representing compressed ephemeral
key (and public key).

> IMHO we cannot use COSE_Encrypt0 because we need the recipient
> structure, which is not present with the COSE_Encrypt0.

HPKE itself does not seem to need the recipient.

> You also seem to define new key formats. What prevents us from
> re-using the existing COSE key formats? Section 13 of RFC 8152
> defines various ECC key formats and those could be re-used.
> Since there is no compressed point format, we could add it.

One of the ideas I had for key compression was reusing the existing
formats. And these are the cases where there is an obvious KDF to
use.

Then there is question how generic HPKE keys should be presented.

> I am also not sure why you talk about PQC algorithms. Neither
> COSE nor HPKE define PQC algorithms. Do you think we should
> define them in this document?

I am expecting that once NIST comes with PQC algorithm recommendations,
those will be added to HPKE. And with generic HPKE algorithm support,
those would be immediately usable in COSE.

-Ilari

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Jan 2022 10:27:16 +0000

Hi Ilari,

Thanks again for your input. A few responses below:

-----Original Message-----
From: [email-masked] <[email-masked]>
Sent: Friday, January 21, 2022 3:18 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]
Subject: Re: [COSE] draft-ietf-cose-hpke-00 and proposed changes for -01

> 1) Should we convey the KEM ID, and KDF ID explicitly? I think so.

Well, I think that all HPKE algorithms should be supported in generic way, so that COSE does not have to deal with registering HPKE algorithms the second time.

[Hannes] I checked the TLS ESNI spec and there, if I understand correctly, the KEM ID is not explicitly communicated. The KDF ID is.

> 2) If we do, where should this information go? You suggest to put them
> into the COSE key (ephemeral key) structure. I would have thought that
> the unprotected header would be more appropriate but I do not really
> have a strong preference.

Well, for KDF id, one could stick it either inside ephemeral key structure, or the main headers.

[Hannes] What would be your preference?

However, I think that one will run into cases where:

[Hannes] In the ESNI spec, the KDF is explicitly communicated in the HpkeSymmetricCipherSuite structure.
Regardless of whether some parameters can be communicated implicitly or explicitly, there is still the question about where the information has to go.

(What is KEM 48?)

> 3) Should we define a new kty id? If we place the KEM ID and the KDF
> ID into the COSE key structure then I think it would be a good idea to
> define a new kty id.

Well, there are not just HPKE encapsulated keys, HPKE also has public and private keys.

While reusing OKP for generic case would be possible (at cost of a few bytes, since crv will be pushed to 5 byte territory), I think new kty would be cleaner.

[Hannes] Having a new kty id parameter is OK for me. I am not sure what you mean by "HPKE also has public and private keys". The newly defined structure is supposed to communicate only the ephemeral public key

> to solve the issues. Maybe you could elaborate a bit what problem you

The size issue is that HPKE currently uses uncompressed P-256/P-384/ P-521. This makes public keys and ephemeral keys a few dozen bytes larger than they should be if one uses NIST curves.

And I came up with two ways of representing compressed ephemeral key (and public key).

[Hannes] Thanks for the clarification.

[Hannes] Here is how I understand COSE: " COSE_Encrypt0 is  used when a recipient structure is not needed because the key to be used is known implicitly." So, the "recipient" structure is really only the name of the place where certain information is supposed to go. In my understanding we have to put the HPKE related info into the recipient structure.

> re-using the existing COSE key formats? Section 13 of RFC 8152 defines
> various ECC key formats and those could be re-used.

One of the ideas I had for key compression was reusing the existing formats. And these are the cases where there is an obvious KDF to use.

[Hannes] If you also want to introduce support for compressed ECC keys then it makes sense to introduce a new kty id.

> I am also not sure why you talk about PQC algorithms. Neither COSE nor
> HPKE define PQC algorithms. Do you think we should define them in this
> document?

I am expecting that once NIST comes with PQC algorithm recommendations, those will be added to HPKE. And with generic HPKE algorithm support, those would be immediately usable in COSE.

[Hannes] To have them immediately usable the COSE fields have to exist where they should be placed. Why is the immediate usage so important? Most likely specification work will be needed by the HPKE authors as well since it is not just about adding an entry to the IANA registry.

Ciao
Hannes

-Ilari

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 24 Jan 2022 14:53:21 +0100

>                      \ hpke-alg \ 1:16 \ HPKE/P-256+HKDF-256 \

echo 'a1013818' | pretty2diag.rb
{1: -25}

(Not 16).

You might be better off using the <<…>> notation [1].

/ protected/ << { 1: -25 } >>

Grüße, Carsten

[1]: https://www.rfc-editor.org/rfc/rfc8610.html#appendix-G.3

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Jan 2022 14:32:40 +0000

Thanks, Carsten.

The examples are still very much in flux since we have to agree on the core structure first. I think we are getting there and the interim meeting this will certainly help as well!

-----Original Message-----
From: Carsten Bormann <[email-masked]>
Sent: Monday, January 24, 2022 2:53 PM
To: Hannes Tschofenig <[email-masked]>
Cc: [email-masked]; [email-masked]
Subject: Re: [COSE] draft-ietf-cose-hpke-00 and proposed changes for -01

(Not 16).

Grüße, Carsten

---

From: Ilari Liusvaara <[email-masked]>
Date: Mon, 24 Jan 2022 18:32:44 +0200

On Mon, Jan 24, 2022 at 10:27:16AM +0000, Hannes Tschofenig wrote:
> way, so that COSE does not have to deal with registering HPKE
> algorithms the second time.
> 
> [Hannes] I checked the TLS ESNI spec and there, if I understand
> correctly, the KEM ID is not explicitly communicated. The KDF ID is.

The KEM ID is in the public key structure.

... Hmm... One could actually omit the KEM id from ephemeral key,
unless some shortcut notation is used (since knowledge which KEM is
used is needed in order to uncompress the ephemeral key).

> structure, or the main headers.
> 

That seems rather hairy question I am not sure about answer to...

> [Hannes] In the ESNI spec, the KDF is explicitly communicated in
> the HpkeSymmetricCipherSuite structure. Regardless of whether some
> parameters can be communicated implicitly or explicitly, there is
> still the question about where the information has to go.

The idea behind implicit KDF is to derive it from the KEM. However,
that can not be assumed to always work. It works with the present KEMs,
but not necressarily with the future ones.

> (What is KEM 48?)

Oops, that should have been some presently unknown KEM that might not
have known internal KDF. E.g., Kyber512 v3.02 (which indeed does not
correspond with any known KDF).
 
And these KEMs that do not correspond to any known KDF are exactly the
ones where implicit KDF breaks down.

> While reusing OKP for generic case would be possible (at cost of a few
> bytes, since crv will be pushed to 5 byte territory), I think new kty
> would be cleaner.
> 
> [Hannes] Having a new kty id parameter is OK for me. I am not sure
> what you mean by "HPKE also has public and private keys". The newly
> defined structure is supposed to communicate only the ephemeral public
> key

I mean, COSE_key can hold public or private keys for any algorithm
supported by COSE (with exception of HSS-LMS private keys).

HPKE does define format for its public and private keys.

> [Hannes] Here is how I understand COSE: " COSE_Encrypt0 is used when a
> recipient structure is not needed because the key to be used is known
> implicitly." So, the "recipient" structure is really only the name of
> the place where certain information is supposed to go. In my
> understanding we have to put the HPKE related info into the recipient
> structure.

My understanding is that the reason why one can not do ECDH-ES with
COSE_Encrypt0 is that ECDH-ES places the asymmetric stuff in different
layer as symmetric stuff, which means two layers minimum, but
COSE_Encrypt0 only allows one layer, so it just will not work.

But HPKE combines asymmetric and symmetric operations, which means it
maps most cleanly to one layer, which would fit COSE_Encrypt0.

> [Hannes] If you also want to introduce support for compressed ECC
> keys then it makes sense to introduce a new kty id.

Actually, I only managed to save one byte with new kty id for the
compressed ECC case.

As to why it saves one byte, for P-256 EC2 uses:

A4 01 02 20 01 21 58 20 <32bytes> 22 F4/F5

And new kty with implicit KDF and C509-style compression would be
something like:

A3 01 xx 20 20 21 58 21 02/03 <32 bytes>

New kty id would make more sense for the cases that are not compressed
ECC.

> [Hannes] To have them immediately usable the COSE fields have to exist
> where they should be placed. Why is the immediate usage so important?
> Most likely specification work will be needed by the HPKE authors as
> well since it is not just about adding an entry to the IANA registry.

Yes, HPKE needs to do specification work for that. But if there is a
generic way to dump random HPKE parameters into COSE message, then one
does not have to do any specification work in COSE.

-Ilari

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 24 Jan 2022 16:50:33 +0000

Hi Ilari,

Let me quickly jump to one point in your email below:

> [Hannes] I am not sure

I mean, COSE_key can hold public or private keys for any algorithm supported by COSE (with exception of HSS-LMS private keys).

[Hannes] That's true. The ESNI spec also defines a configuration format (ECHConfig). While ECHConfig does not include the private key, it can otherwise serve as a template for defining a format for configuring HPKE-needed information.

More responses later....

Ciao
Hannes