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 _______________________________________________ COSE mailing list [email protected] https://www.ietf.org/mailman/listinfo/cose
