John:
When sending the same content to multiple recipients, you have two choices. In
the first alternative, you encrypt the same random value for each recipient's
KEM public key, which results in all of the recipients deriving the same key.
In the second alternative, you encrypt a different random value for each
recipient's KEM public key, which results in each of the recipients deriving a
different key.
The first approach in the one used in out document. It is similar to ECDH-ES +
A128KW.
For each recipient:
Z = randomly generated value.
WZ = Encrypt Z with the recipient's KEM public key.
KEK = KDF(Z)
CEK = randomly generated content-encryption key.
WCEK = Wrap CEK with KEK.
C = Encrypt payload with CEK.
Send SetOf(WZ,WCEK), C.
I think you are suggesting that we should support the second alternative as
well, which is similar to ECDH-ES + HKDF-256.
Z = randomly generated value.
For each recipient:
WZ = Encrypt Z with the recipient's KEM public key.
CEK = KDF(Z)
C = Encrypt payload with CEK.
Send SetOf(WZ), C
During the LAMPS session on Monday, it was suggested that the KEM structure
optionally allow the inclusion of a UKM as a KDF input. That would change the
above to be:
key = KDF(Z, [UKM]), where the UKM is optional KDF input.
Russ
> On Nov 9, 2021, at 8:33 AM, John Mattsson
> <[email protected]> wrote:
>
> 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
