On Jul 31, 2023, at 12:36 PM, Orie Steele
<[email protected]<mailto:[email protected]>> 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.
}
Well, um, er, these kind seems to maximization the worst to me:
- Not compatible with COSE_Key (some people think this is important; I don’t)
- Not aligned with my point about standards and layering
- Not the easiest alignment with HPKE libraries
- Includes redundant alg and curve info
- Bonus confusion from kid and key use that has point in this context
LL
_______________________________________________
COSE mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/cose
