Neil and Ilari, thank you for your feedback, you have identified the problem correctly. Based on all of the responses I see that the intention was to define the OKP key type in COSE to be compatible with the JOSE definition, which is something that I wholeheartedly support. I therefore retract my initial proposal of changing the key type to EC2.
Clearly then, the COSE definition of OKP which is currently given in RFC 8152 is completely wrong for Ed25519 and Ed448 and needs to be fixed. Neil, I don't think it's necessary to define a separate type for x-only public keys. Changing the name of the 'x' parameter to something more generic like 'pub' would make a lot of sense though, especially seeing as it got Jim so terribly confused. Andrew On Sat, Feb 29, 2020 at 10:52 AM Ilari Liusvaara <[email protected]> wrote: > 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
