The draft representation seems not correct. The original key just had public and private components.
IIRC the reason for the change was to avoid extra text / custom encoding of the points. Imo, new signature algorithms should have very simple keys: One value for public, one value for private, no confusing parameters (crv,n,x,d). If you need crv and y, use EC/EC2 not OKP. It could even have the same kty, as ML-DSA and SLH-DSA, if there is no crv, and the public key is a single value. OS On Mon, Jan 15, 2024, 5:04 AM Alberto Solavagione < [email protected]> wrote: > Hello everybody, > > I have a question about the JWK representation of a BLS key in the draft. > As outlined, the key is categorized as "OKP," where the public key is > presented as a curve point, with the OKP type containing the coordinates > "x" and "y" of the public key. > > In my examination of RFC 8037( > https://www.rfc-editor.org/rfc/rfc8037.html#section-2), I observed a > different OKP definition for X25519, X448, Ed25519, and Ed448 curve keys, > where the public key is treated as a single value in the parameter "x." > > I'm curious about how both cases can be handled cohesively to avoid > introducing inconsistencies and ambiguities within the "OKP" representation > of a key. Your clarification on this matter would be really helpful. > > Thank you in advance for your time. > > Best regards, > > Alberto Solavagione > _______________________________________________ > COSE mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/cose >
_______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
