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

[Ilari Liusvaara <[e-mail]>]

On Fri, Feb 28, 2020 at 10:24:46AM -0800, Jim Schaad wrote:
> 
> I believe that the correct result that has been implemented for both JOSE
> and COSE is to take encoding that is specified in RFC 8152 and use that as
> the public key.  I know that I compared all of my code with the text vectors
> in RFC 8152 so that I will be shocked if this is not true.  If this is not
> clear in either document then we need to change that text.
 
I am not sure I agree.

The correct interpretation for JOSE is to take the contents of "x"
field, base64url decode it, and stuff the result raw into Ed25519
signing/verification (as defined by RFC 8032) as an octet string
(and "d" is base64url decoded and stuffed raw into Ed25519 signing).

I can take the keypair test vector from RFC 8037 and stuff it into
program that definitely takes the above interpretation (I wrote it)
and it both passes key consistency check and passes signature self-
verify check.

Now, the same program also supports COSE keys. When coding that support,
I assumed that COSE way is straightforward port of JOSE (encode
constants as integers, encode base64url'd string as raw bstr), and thus
the code just stuffs whatever is in "x" field raw into Ed25519 signing/
verification (as defined by RFC 8032) as an octet string (and "d" is
another bstr and stuffed raw into Ed25519 signing as octet string).


Now RFC 8152 says:

"This contains the x-coordinate for the EC point.  The octet string
represents a little-endian encoding of x."

Which is just plain wrong for Ed25519 and Ed448. As the public key is
encoding of y coordinate together with sign bit of x coordinate. And
even that COSE should not be concerned with: It should treat RFC 8032
public keys as octet strings.

And even for X25519 and X448, it is not quite correct, because the
X25519 and X448 public keys are not integers, they are octet strings
(which happen to be little-endian encoding of x coordinate of an
elliptic-curve point).

Now, it is possible to recover the y coordinate of Ed25519 and Ed448
keys from the x coordinate, but the algorithm is fairly slow (due to
calculating the lth multiple), and I do not think it has ever been
implemented.

What I think all COSE implementations of EdDSA do is to stuff the
bstr x raw into RFC 8032 EdDSA implementations as octet string (that is
definitely what my code is doing).


-Ilari