There probably aren't any such certificates out in the Web PKI because Mozilla's rules prohibit them (and almost as important Firefox won't validate them). But Microsoft trusts a whole bunch of dubious kinda sorta wanna be Certificate Authorities, maybe one of those issued crap with specifiedCurve for a standard curve ? Or maybe a corporate internal CA?
That's a test somebody can do: If you use a Microsoft internal CA can you easily mint these stupid specifiedCurve certificates with it? Or does it make you pick a named curve and emit the OID properly? How about other popular private CA solutions? EJBCA maybe?
As a crypto/ security person your instinct is to say "No" because if something is more complicated but adds no apparent benefit that's a problem. That's why PKIX says "No" here, and it's why Mozilla policy says "No" here. But for a Microsoft sales person trying to land a large deal before the quarter ends the instinctive answer is "Yes" unless one of the technical people can explain why it's inherently unsafe.
This is how Microsoft ends up supporting six different bad ways to do something in Windows - not because they're lousy engineers but because they are willing to do what it takes to make the sale. Of course specifically in security arguably that does make them lousy engineers.
The worst part about such requirements is that they can often turn out to be bogus. One technical person pastes in a description of NIST's P-256 with all the curve details and a game of telephone results in the idea that they want to use specifiedCurve when actually they'll use a named curve because duh, of course they will. But if nobody says "No" the specifiedCurve feature gets backed into a requirements document and actioned.
I have had non-security "requirements" that I pushed back on and six transatlantic conference calls later I'm talking to the person who supposedly "had" the requirement and they go "I have no idea how this got made into a requirement, we don't need this at all" and a bunch of work vanishes instantly. But I do that sort of thing because I'm stubborn, it might well be easier and faster (and more profitable) to just fulfil the unnecessary requirement.
https://groups.google.com/forum/#!topic/mozilla.dev.security...
This gave Ryan a chance to point people at Adam Langley's wise observation that you should not parse things like signatures when you can instead calculate the entire value you expected and then just binary compare - anything that doesn't match is wrong and you needn't care why.
Newer curves, like EdDSA curves, are always each specified with unique OIDs and have a simpler public key grammar. See https://tools.ietf.org/html/rfc8410 Older public curves share an OID and a more generic ("flexible") syntax, thus the ECParameters field. (RSA public keys also have a parameters field, but it's unused. However, annoyingly, some implementations omit the field altogether, others set a NULL value.)