As mentioned on bug 1019390 comment 13, some places use secp521r1.
It is a logical progression from suiteb (secp256r1 and secp384r1), so I would expect it to be a common choice.
Note: "some places" means "some instances of postfix".
Another data point: I use a self-compiled nss-softokn (basically, I split it from the unmodified upstream source, instead of using the hobbled source, and set the correct environment variable to make it compile the ECC code).
With that, going to https://www.ssllabs.com/ssltest/viewMyClient.html shows that my Firefox browser is sending the following curves: secp256r1, secp384r1, secp521r1.
The other two curves are the suiteb curves, which AFAIK were enabled by bug 319901. Only secp521r1 is AFAIK missing. If Firefox is choosing this particular set of three curves, it is probable that many others have the same choice. For greater compatibility, it would be a good idea to enable at least these three curves.
And yet another data point: Qualys' SSL server tester (https://www.ssllabs.com/ssltest/) has hardcoded knowledge about a few common browsers (it can be seen at the results page after testing any SSL server). Looking at the latest version of what I would consider the most relevant browsers, I see:
Firefox 24 / Win 7: secp256r1, secp384r1, secp521r1
Chrome 30 / Win 7: secp256r1, secp384r1, secp521r1
IE 11 / Win 8.1: secp256r1, secp384r1
According to ssllabs.com, IE on Win 7 also supports only secp256r1 and secp384r1 so sites that want to be compatible with Windows 7 and Windows 8 CryptoAPI can't use secp521r1.
That doesn't mean that openssl cannot support secp521r though. It just means that you can't have your server configured to support just secp521r if you want to be compatible with IE.
(In reply to Tomas Mraz from comment #5)
> That doesn't mean that openssl cannot support secp521r though. It just means
> that you can't have your server configured to support just secp521r if you
> want to be compatible with IE.
It means, however, that supporting secp521r1 isn't as high a priority.
I created these specific curve bugs because I believe the only curves most people are interested in are secp256r1, secp384r1, secp521r1, secp256k1, and curve25519/ed25519. The first two are already in, and the last one AFAIK is not on openssl yet. Having a separate bug for each curve reduces the noise in the global "enable ecc" bugs.
The postfix issue mentioned above might have been fixed by bug 1022493; see bug 1019390 comment 16. If that is true, that lowers the urgency for this curve; secp256k1 (bug 1021898) becomes the most urgent of the two.
We now have ACK from legal for the secp521r1 curve, not yet for the other curves.
This also impacts the ecdsa-sha2-nistp521 SSH key exchange method (listed as REQUIRED in RFC5656).