Hi Ilari,

Looked at PR9 <https://github.com/cose-wg/HPKE/pull/9> and PR10 
<https://github.com/cose-wg/HPKE/pull/10>. (Orie, there’s the links for you).

If you look at Appendix Example C.3.1 in RFC 9052 
<https://www.rfc-editor.org/rfc/rfc9052.html#name-direct-ecdh> (and pasted 
below) you can see what I’m talking about in when I say that the AEAD algorithm 
is identified in the body header parameter and that it is separate from the 
recipient algorithm ID. In this example, there are two algorithm IDs, one in 
the body for AES-GCM 128 and one in the COSE_Recipient for ECDH-ES + HKDF-256.

I believe this is really useful when you want to bulk encrypt the payload 
(which might be large) once for multiple recipients. With multiple recipients 
the key agreement algorithm could be different for each recipient even thought 
the bulk algorithm is the same. Perhaps two are HPKE and two are Key Wrap from 
6.2 <https://www.rfc-editor.org/rfc/rfc9053.html#name-key-wrap>?  Might be good 
to have one PQ and one non-PQ too.

Note that to actually do this we have to define an HPKE variant where what is 
output from Encap() is used with key wrap similar to section 6.4 in RFC 9053 
<https://www.rfc-editor.org/rfc/rfc9053.html#name-key-agreement-with-key-wrap>.

I also believe having two algorithm IDs like this makes more sense because the 
bulk AEAD ID for the body payload is associated with the body header parameters 
and this makes the processing of the body more straight forward.

LL


96(
  [
    / protected h'a10101' / << {
        / alg / 1:1 / AES-GCM 128 /
      } >>,
    / unprotected / {
      / iv / 5:h'c9cf4df2fe6c632bf7886413'
    },
    / ciphertext / h'7adbe2709ca818fb415f1e5df66f4e1a51053ba6d65a1a0
c52a357da7a644b8070a151b0',
    / recipients / [
      [
        / protected h'a1013818' / << {
            / alg / 1:-25 / ECDH-ES + HKDF-256 /
          } >>,
        / unprotected / {
          / ephemeral / -1:{
            / kty / 1:2,
            / crv / -1:1,
            / x / -2:h'98f50a4ff6c05861c8860d13a638ea56c3f5ad7590bbf
bf054e1c7b4d91d6280',
            / y / -3:true
          },
          / kid / 4:'[email protected]'
        },
        / ciphertext / h''
      ]
    ]
  ]
)




> On Nov 9, 2022, at 3:03 PM, Ilari Liusvaara <[email protected]> wrote:
> 
> On Wed, Nov 09, 2022 at 10:45:50AM +0000, Laurence Lundblade wrote:
>> Hi,
>> 
>> I noticed that RFC 9810 (HPKE) has an identifier for AEAD algorithms.
>> The IANA COSE algorithm registry also has an identifier for this. 
>> 
>> I want to confirm that COSE HPKE will use identifiers from the COSE
>> space in the algorithm ID body header parameter, not the identifier
>> from RFC 9810.
> 
> In PR9/PR10 proposals, the alg field will contain new COSE algorithm
> value for HPKE (not yet assigned), and the aead field in sender
> structure will contain RFC 9180 AEAD id value (some have already
> been assigned).
> 
> 
> 
> -Ilari
> 
> _______________________________________________
> COSE mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/cose

_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose

Reply via email to