[COSE] draft-ietf-cose-rfc8152bis-algs-06: Incompatible encoding of EdDSA public keys

[Andrew Kozlik <[e-mail]>]

Hello everyone,

I encountered a bug in libfido2 (
https://github.com/Yubico/libfido2/issues/136), which leads me to propose
some changes in COSE encoding of EdDSA public keys. Here is the problem:

The standard encoding of EdDSA public keys as defined in
https://tools.ietf.org/html/rfc8032#section-5.1.2 encodes the y-coordinate
and the sign of the x-coordinate of the EC point as the public key. COSE on
the other hand encodes only the x-coordinate as the public key, see
https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-06#section-7.2.
There are two problems with this discrepancy:

1. As far as I know, all libraries support only the standard RFC 8032
encoding of public EdDSA keys. Computing the y-coordinate from the
x-coordinate and vice versa is not straightforward, because it involves
some multi-precision modular arithmetic, making it very problematic to use
the COSE format for anyone who is not well versed in the mathematics of
ECC. Even if libraries were to support both encodings in the future, it
would cause a lot of pointless confusion to developers.

2. There is no way to determine the sign of the y-coordinate from knowing
only the x-coordinate. Thus when verifying a signature, one has to try both
signs for the y-coordinate of the public key and accept the signature if
either of the two signature verifications passes.

To resolve these issues, I propose the following changes:

1. In Table 18,
https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-06#section-7.1,
the key type of Ed25519 and Ed448 keys should be changed to EC2.

2. In Section 7.1.1,
https://tools.ietf.org/html/draft-ietf-cose-rfc8152bis-algs-06#section-7.1.1,
the 'x' parameter of EC2 keys should be allowed to contain either the sign
bit or the value of the x-coordinate for the EC point. In addition there
should be a requirement stating that if the 'x' or 'y' parameter is present
in the structure, then at least one of them MUST be of CBOR type bstr.

Cheers,
Andrew Kozlik