Comment 5 for bug 1233810

I'll fix the typo.

Re: curve names, this may be a bit hairy. I already dislike OpenSSL's insistence on using nonstandard names for cipher suites, and even RFC4492 is little confused as to what the curves are called. For example, section 5.1.1 (the normative part) says:

        enum {
            sect163k1 (1), sect163r1 (2), sect163r2 (3),
            sect193r1 (4), sect193r2 (5), sect233k1 (6),
            sect233r1 (7), sect239k1 (8), sect283k1 (9),
            sect283r1 (10), sect409k1 (11), sect409r1 (12),
            sect571k1 (13), sect571r1 (14), secp160k1 (15),
            secp160r1 (16), secp160r2 (17), secp192k1 (18),
            secp192r1 (19), secp224k1 (20), secp224r1 (21),
            secp256k1 (22), secp256r1 (23), secp384r1 (24),
            secp521r1 (25),
            reserved (0xFE00..0xFEFF),
            arbitrary_explicit_prime_curves(0xFF01),
            arbitrary_explicit_char2_curves(0xFF02),
            (0xFFFF)
        } NamedCurve;

The text "prime256v1" only appears in the (informative) Appendix A. If I add the list of names, I'd probably follow 5.1.1, which will confuse everyone who's looking for "P-256". Sigh.

FWIW, my patch works unmodified when built against the newly-sort-of-ECC-supporting Fedora OpenSSL. It might be worth adding a comment that secp256r1 and secp284r1 (the NIST Suite B curves) are the most widely supported.

P.S. If I'm reading RFC4492 right (it's not very clear), the server should be able to choose a curve for key exchange based on the allowed curves listed by the client. Does OpenSSL support that? This will be important if/when TLS gains support for curve25519.