Re: ECKeyValue example is bad

[forwarding this to public xml security list for continued discussion and resolution on that list]

Jim,  thanks for noting the issue.  Apologies for the delay in processing.

All, please review the following proposed XML Signature 1.1 errata item:

(for https://www.w3.org/2008/xmlsec/errata/xmldsig-core-11-errata.html)

[[

E05: Correct encoding of ECDSA public key in Section 4.5.2.3 "The ECKeyValue Element"

Added:
TBD

Accepted
XML Security WG  Call for Consensus via email TBD

Raised:
29 January 2018

Class:
informative (example)

Affects conformance:
No

Section  4.5.2.3 Example 7 ( https://www.w3.org/TR/xmldsig-core/#sec-ECKeyValue )  the Public Key Value is listed as 

vWccUP6Jp3pcaMCGIcAh3YOev4gaa2ukOANC7Ufg
 Cf8KDO7AtTOsGJK7/TA8IC3vZoCy9I5oPjRhyTBulBnj7Y

This value should be replaced with 

bd671c50fe89a77a5c68c08621c021dd839ebf881a6b6ba4380342ed47e009ff
0a0ceec0b533ac1892bbfd303c202def6680b2f48e683e3461c9306e9419e3ed

(as noted line break added for printed page width_

]]

Please comment on whether you agree that this is correct or whether a different curve point should be used.

Thanks, Frederick


> On Jan 29, 2018, at 10:02 PM, Jim Wigginton <terrafrost@php.net> wrote:
> 
> 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 Friday, 10 August 2018 22:56:14 UTC