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

[Ilari Liusvaara <[e-mail]>]

On Tue, Jan 18, 2022 at 11:20:34AM +0000, Hannes Tschofenig wrote:
> Hi Ilari,
> 
> [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:'[e-mail]'
>                },
>                // Encrypted CEK
>                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