Hannes wrote:
I do, however, agree that the cleaner way is to define a new parameter, as you
suggested, and then re-use the HPKE registry. By doing this we also make sure
that the two registries do not get out of sync. So, unless there is an
objection I would go head and make the chance to the draft.
- The current COSE key exchange algorithms comes in pairs such as
ECDH-ES + A128KW (ECDH ES w/ Concat KDF and AES Key Wrap w/ 128-bit key)
ECDH-ES + HKDF-256 (ECDH ES w/ HKDF - generate key directly)
The approaches have different pros and cons. I think it would be good to follow
the same architecture with HPKE in COSE (but continue using HPKE Seal() instead
of AESKW). The difference between using a CEK and deriving a key directly could
easily be signaled with the sign of the ‘hpke-alg' value.
Using (say 'hpke-alg'; label 11) the two approaches could be signaled as
{11 : 17} or {11 : -17}
- I think the current draft and Göran’s ‘hpke-alg' suggestion both lack a
definition of the HPKE AEAD used for the Seal operation. I do not think the
HPKE AEAD follows from the HPKE KEM ID.
Cheers,
John
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
