On Mon, Jul 31, 2023 at 02:36:51PM -0500, Orie Steele wrote:
>
>
> This depends on how it might be used.
>
> Yes, it's possible to pull apart DHKem output into a kty: EC / crv P256
> setup... but it's also possible to just treat enc a regular bytes:
>
> {
> "kid": "...opaque-dhkem-output",
> "alg": "...", // probably not a thing, but just for argument's sake.
> "kty": "oct",
> "k": "04 + x + y ...."
> }
>
> vs
>
> {
> "kty": "EC",
> "crv": "P-256",
> "x": "mpWfwr7bhFcmmDDQkpc5KGua-PaI7tbakIpZc4rKy38",
> "y": "uqdK_tLp8_7Xt3uH3zhjv5JwPygp-lPGRNdhBSwAkSg",
> "use": "enc", // probably not a thing, but just for argument's sake.
> "key_ops": [ "deriveBits" ], // probably not a thing, but just for
> argument's sake.
> "alg": "..." // probably not a thing, but just for argument's sake.
> }
Because KEM outputs are only ever used once, it does not make sense to
use kid. Similarly on how kid in eph does not make any sense in ECDH-ES.
And I don't think ECDH-ES eph has use or key_ops either? And wouldn't
alg duplicate the same thing twice (as there is already alg in the
message)?
And even DHKem outputs might not be possible to pull apart. E.g.,
CP-256. And for shortcut ciphersuite, CP-256 with KDF1 and AEAD1 is the
highest value candidate (the second would be KEM32 with KDF1 and AEAD3).
> - - HPKE libraries will take care of everything for binary “enc” and be
> > simple to integrate
> >
> >
> Given the encap / decap APIs that each registered kem needs to define I
> agree that avoiding doing surgery on enc is preferred, but I still question
> if it's worth communicating enc in a structured wrapper like a Map or a
> COSE Key, or if it's better to just forward it as is.
As note, there was a version of HPKE sender info that used a map instead
of array. It was changed to array because there was no usecase for map
(as there is no possible compatible extension, and auth/PSK can be
represented in different way) and using array is simpler than map.
> Are there any channel binding considerations related to encap / decap?
No.
-Ilari
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
