Sorry to dig this up but I would very much encourage the implementation for ed25519 as a preferred alternative (which should probably be preferred by default with secp256r1 as fallback)
The OP has made a very valid point and given the significant criticism from the crypto community regarding secp256r1, it makes sense to support a safe alternative.
At safecurves.cr.yp.to curves are primarily evaluated with focus on complexity and implementation considerations. There “unsafe” means that the implementation needs to be performed carefully and may be more complex and error-prone than for other curves.
These “safety attributes” have a direct impact on the resulting security of the overall system they are protecting. They are not unrelated even if those unsafe curves are not proven to be “broken”.
I’m not aware of any reputable cryptographer who seriously recommends to avoid NIST curves because they could be back-doored.
Im not aware of any reputable cryptographer who does NOT recommend to avoid NIST curves because they could be back-doored.
e.g.
https://www.schneier.com/blog/archives/2013/09/the_nsa_is_brea.html/#comment-202922
safecurves.cr.yp.to adds plenty of additional reasons why to avoid those curves when possible.
Nitrokey has the option to implement ed25519 for Fido2 and would thereby support the use of this algorithm by server side implementation as well.
Referring to a lack of serverside support will not help here as they will just point back to nitrokey saying its not supported on this side either.
I do not see how it would make sense for me to buy a Nitrokey Fido2 device and then use suspicious NSA crypto on them when there is an alternative curve that can be used with an increasing number of services (e.g. OpenSSH)
(This is especially relevant considering alternative Fido2 vendors already support ed25519)
Im not a developer, so I cant just go and write a patch for you guys to integrate, but I would offer any help with testing this feature.
Please reconsider implementing ed25519 !