- 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