- From: Jim Wigginton <terrafrost@php.net>
- Date: Mon, 29 Jan 2018 21:02:54 -0600
- To: public-xmlsec-comments@w3.org
- Message-ID: <CAKY7Jh4Wx3wQCC+qHZ81FtvOA-KM7td5Nas=xrOk4q9EUMjxcg@mail.gmail.com>
https://www.w3.org/TR/xmldsig-core/#sec-ECKeyValue gives the following example of an ECDSA key: <ECKeyValue xmlns="http://www.w3.org/2009/xmldsig11#"> <NamedCurve URI="urn:oid:1.2.840.10045.3.1.7" /> <PublicKey> vWccUP6Jp3pcaMCGIcAh3YOev4gaa2ukOANC7Ufg Cf8KDO7AtTOsGJK7/TA8IC3vZoCy9I5oPjRhyTBulBnj7Y </PublicKey> </ECKeyValue> Here's what it says regarding the encoding of the PublicKey: The PublicKey element contains a Base64 encoding of a binary representation > of the x and y coordinates of the point. Its value is computed as follows: > > - Convert the elliptic curve point (x,y) to an octet string by first > converting the field elements x and y to octet strings as specified in > Section 6.2 of [ECC-ALGS] (note), and then prepend the concatenated result > of the conversion with 0x04. Support for > Elliptic-Curve-Point-to-Octet-String conversion without point compression > is required. > > > - Base64 encode the octet string resulting from the conversion in Step > 1. > > From that I'd expect that the first character of the base64 decoded text would be 04 but it isn't. It's BD. Here's the full decoded value: bd671c50fe89a77a5c68c08621c021dd839ebf881a6b6ba4380342ed47e009ff0a0ceec0b533ac1892bbfd303c202def6680b2f48e683e3461c9306e9419e3ed As such I think the example is a bad one and I think the standard needs to be updated with a new one.
Received on Tuesday, 30 January 2018 08:50:11 UTC