Re: [TLS] Curve25519 in TLS and Additional Curves in TLS

[Manuel Pégourié-Gonnard <[e-mail]>]

On 03/04/2014 19:35, Andrey Jivsov wrote:
> My reply regarding the current draft with clarification from Manuel follows:
> 
> RFC 5246 is listed as a normative reference. As such, it defines the the 
> encoding for the
> 
>     opaque something <1..2^8-1>
> 
> The reader is expected to know that "something" is encoded with an additional byte for the length. Thus, I find the item (2) in sec. 2.3 confusing (IMHO more confusing than helpful).
> 
>>     Note that ECPoint.point differs from the definition of public keys in
>>     [Curve25519  <http://tools.ietf.org/html/draft-josefsson-tls-curve25519-04#ref-Curve25519>] in two ways: (1) the byte-ordering is big-endian, wich
>>     is more uniform with how big integers are represented in TLS, and (2)
>>     there is an additional length byte (so ECpoint.point is actually 33
>>     bytes), again for uniformity (and extensibility).
> 
> Would the following be clearer:
> 
>> Unlike the definition of public keys specified in [Curve25519],
>> ECPoint.point uses big-endian byte ordering. As defined in [RFC5246],
>> the ECPoint.point is serialized with one-byte block size. The payload must be 32
>> bytes, even when one or more leading bytes are zeros.
> 
Thanks for the helpful suggestion.

Manuel.