[TLS] EDDSA/Curve25519 identifiers: Was Re: AES-OCB in TLS

[Michael StJohns <[e-mail]>]

On 6/1/2015 8:53 AM, Ilari Liusvaara wrote:
> I think the current plan with EdDSA and related certficates are to reuse
> ECDSA codepoints, relying on extension (defined by RFC5246) to negotiate.
>
>
I may be misreading this and all you're talking about are code points 
for TLS, but in case you're talking about the more specific issue of 
reusing the current SubjectPublicKeyInfo definitions of id-ecPublicKey 
for certificates containing EdDSA public keys:


RFC 5480 defines the format of an EC public key (as identified by 
1.2.840.10045.2.1 and for that matter by 1.3.132.1.12 and 
1.3.123.1.13).  Note specifically the second bullet on the format of the 
ECPoint octet string.

> 2.2.  Subject Public Key
>
>     The subjectPublicKey from SubjectPublicKeyInfo is the ECC public key.
>     ECC public keys have the following syntax:
>
>       ECPoint ::= OCTET STRING
>
>     Implementations of Elliptic Curve Cryptography according to this
>     document MUST support the uncompressed form and MAY support the
>     compressed form of the ECC public key.  The hybrid form of the ECC
>     public key from [X9.62] MUST NOT be used.  As specified in [SEC1]:
>
>        o The elliptic curve public key (a value of type ECPoint that is
>          an OCTET STRING) is mapped to a subjectPublicKey (a value of
>          type BIT STRING) as follows: the most significant bit of the
>          OCTET STRING value becomes the most significant bit of the BIT
>          STRING value, and so on; the least significant bit of the OCTET
>          STRING becomes the least significant bit of the BIT STRING.
>          Conversion routines are found in Sections 2.3.1 and 2.3.2 of
>          [SEC1].
>
>        o The first octet of the OCTET STRING indicates whether the key is
>          compressed or uncompressed.  The uncompressed form is indicated
>          by 0x04 and the compressed form is indicated by either 0x02 or
>          0x03 (see 2.3.3 in [SEC1]).  The public key MUST be rejected if
>          any other value is included in the first octet.


This RFC mirrors equivalent language in both X9.62/63 and the SecG stuff 
(and for that matter NIST).

So, don't try and overload the current meaning of id-ecPublicKey - 
you'll break a *lot* of things.  And we (the IETF that is) don't 
actually have change control over what that OID means.


Instead, get a new allocation and write a document that looks like 
RFC5480 for the ED and Curve public keys.  You want certificate 
representations for *both*.

Later, Mike