Fix EcdsaVerify.CheckECDsa when cert is OpenSSL

[alanssitis]

Description

Certificate OID friendly name is not cross-platform. The certificate on
Windows is of type ECDsaCng while on Ubuntu it is of type ECDsaOpenSsl.

This causes the friendly names to differ, where it's nistP256 with
ECDsaCng and ECDSA_P256 with ECDsaOpenSsl. The OID value is the same
with both.

Type of change

Please delete options that are not relevant.

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How has this been tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

Test configuration: Encountered when running MakeCredential on a Linux machine. You can verify the friendly name issue with the following code snippet:

// Certificate was copied from a MakeCredential call, it is an attestation certificate.
var cert = new X509Certificate2(Convert.FromHexString("308202EC308201D4A00302010202090088A1B9C54F6C20BE300D06092A864886F70D01010B0500302E312C302A0603550403132359756269636F2055324620526F6F742043412053657269616C203435373230303633313020170D3134303830313030303030305A180F32303530303930343030303030305A306F310B300906035504061302534531123010060355040A0C0959756269636F20414231223020060355040B0C1941757468656E74696361746F72204174746573746174696F6E3128302606035504030C1F59756269636F205532462045452053657269616C20313136393739333431363059301306072A8648CE3D020106082A8648CE3D03010703420004FDCDFA1676A915726A3B55446C7FB5D2BF60070D34663EFA40E80CE0D21E4E1C02A5D267B8D97A92242DD41793B24FD9D0F48153293F95B3389A44BFC27AB517A381943081913013060A2B0601040182C40A0D0104050403050403301006092B0601040182C40A0C0403020107302206092B0601040182C40A020415312E332E362E312E342E312E34313438322E312E373013060B2B0601040182E51C0201010404030205203021060B2B0601040182E51C0101040412041073BB0CD4E50249B89C6FB59445BF720B300C0603551D130101FF04023000300D06092A864886F70D01010B050003820101003C25CCCE20FF720F3B988B3630A09C060B09986D458DBA890FBBF34E3112CA4C7BD17D94617F92D11D7ED68C3D2427089FA3BDB997F3BB6FE1B863EDF0F5AD6D2B4D3004608CC70DC5FE819CC6C9FE4E0EB3590656DC75CDF10C5F6F9BED9D7EE52B9A26BA050FCAAED706A881A858B6A2A1C5C633E3652605A902C4D43C437C956DC57CACBC6D6AFED9139116A09006AA2DBE7D4A2B4D2AC497275E18F5A1BA962685A522FCABE05E21EE9704767C346C4685976784EBBAA308202EC308201D4A00302010202090088A1B9C54F6C20BE300D06092A864886F70D01010B0500302E312C302A0603550403132359756269636F2055324620526F6F742043412053657269616C203435373230303633313020170D3134303830313030303030305A180F32303530303930343030303030305A306F310B300906035504061302534531123010060355040A0C0959756269636F20414231223020060355040B0C1941757468656E74696361746F72204174746573746174696F6E3128302606035504030C1F59756269636F205532462045452053657269616C20313136393739333431363059301306072A8648CE3D020106082A8648CE3D03010703420004FDCDFA1676A915726A3B55446C7FB5D2BF60070D34663EFA40E80CE0D21E4E1C02A5D267B8D97A92242DD41793B24FD9D0F48153293F95B3389A44BFC27AB517A381943081913013060A2B0601040182C40A0D0104050403050403301006092B0601040182C40A0C0403020107302206092B0601040182C40A020415312E332E362E312E342E312E34313438322E312E373013060B2B0601040182E51C0201010404030205203021060B2B0601040182E51C0101040412041073BB0CD4E50249B89C6FB59445BF720B300C0603551D130101FF04023000300D06092A864886F70D01010B050003820101003C25CCCE20FF720F3B988B3630A09C060B09986D458DBA890FBBF34E3112CA4C7BD17D94617F92D11D7ED68C3D2427089FA3BDB997F3BB6FE1B863EDF0F5AD6D2B4D3004608CC70DC5FE819CC6C9FE4E0EB3590656DC75CDF10C5F6F9BED9D7EE52B9A26BA050FCAAED706A881A858B6A2A1C5C633E3652605A902C4D43C437C956DC57CACBC6D6AFED9139116A09006AA2DBE7D4A2B4D2AC497275E18F5A1BA962685A522FCABE05E21EE9704767C346C4685976784EBBAAB361C4E94979581E3794A15176FDCAE99D0A1C8E5E7D7206AB2604B668957F8E54969F265584A6EAD78BA9E98520D14B0EEB4F94626E6B2AEC52E4EBC0B2F80A6E5FBBD63871092B361C4E94979581E3794A15176FDCAE99D0A1C8E5E7D7206AB2604B668957F8E54969F265584A6EAD78BA9E98520D14B0EEB4F94626E6B2AEC52E4EBC0B2F80A6E5FBBD63871092"));
var ecdsa = cert.GetECDsaPublicKey();
if (ecdsa is null)
{
    throw new NotImplementedException();
}
Console.WriteLine(ecdsa);
var pars = ecdsa.ExportParameters(false);
Console.WriteLine(pars.Curve.Oid.FriendlyName);
Console.WriteLine(pars.Curve.Oid.Value);

• Firmware version: 5.4.3
• Yubikey model: This behavior can be seen in Yubico USB A and USB C keychains, and USB C nanos.

Checklist:

• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have run dotnet format to format my code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[DennisDyallo]

Hi @alanssitis and thanks for bringing this to our attention. Using the the globally unique Oid.Value over the Oid.FriendlyName should make the codebase more reliable when run across different platforms. Unless @GregDomzalski has more historical context?
I'm inclined to merge this PR as is, but I don't have an Ubuntu machine close by to test it, will get to it as quickly as I can.
I might as well ask you if you discovered similar oversights anywhere else in codebase and if so are you able to test and report your findings? It would be much appreciated. Have a good weekend!

[GregDomzalski]

Nope. Probably just an oversight. I agree comparing with OID seems like the better thing to do.

It looks like we have a trailing . at the end of Value. - I am assuming that should probably not be there?

[DennisDyallo]

Thanks for the contribution @alanssitis!