note for reviewers: this and equivalent in CoseTestMultiSign is a core of testing all overloads

I'm still confused where is this value coming from - it supposedly should be somewhere in the draft

Since the type hierarchy is internal and we know we won't use finalizers, we can use DisposeCore instead of Dispose(bool), if preferred.

I left as is, I like using single pattern everywhere

If the support check is about cert chains, then the class or method should say that. Since the class seems like the wrong answer here, the method (and property) should.

Microsoft.Bcl.Cryptography exposes the types to netstandard 2.0... why wouldn't we expose the new members here to netstandard 2.0? (Unlike SignedCms, COSE doesn't have to worry about netfx compat/limitations)

As far as I can see BuildPqc is only used to decide if Microsoft.Bcl.Cryptography needs to be a referenced.

Since it is used just in this case I would get rid of BuildPqc and put the condition directly on the ItemGroup.

I feel like we usually put conditions on ItemGroup, not individual items..

Why are you restyling this? Is it making it consistent with something else? (AFAIK, the newline style is more prevalent)

I don't recall explicitly changing it so presumably VS did that on my behalf and I didn't notice - will fix

The helper described that it was answering if PSS works in certs, but this is using it as whether PSS works at all. So it'll be wrong on Android.

If PSS doesn't work then why do anything at all? I'd expect "if PSS works, try PSS. If it doesn't, either check we get the right kind of exception, or ignore it"

If ML-DSA is supported, we have 6. Else we have 5. Seems like just supporting unbalanced is the way to go.

Chop consistently

Yeah, this feels dirty.

I think we want to just say "we added a new feature and that if you use it, .Key will be null" (so change the nullability of CoseSigner.Key)... that's the approach that is currently being tried out for CmsSigner. And then we just set a field/property for the ML-DSA (et al) key that we can carry through to signing.

That means that we then want something like CoseVerifier. Or maybe we should make a CoseKey class, if we can serialize it to COSE_Key (https://github.com/dotnet/runtime/blob/26c9fb8e747ec936ff93b27e8c4de7e6bc43ec70/src/libraries/System.Formats.Cbor/tests/CoseKeyHelpers.cs) that sounds like goodness. Then we overload Sign and Verify once (per current method) with CoseKey, and just need to make sure CoseKey has ctors/factories for the supported algorithms.

public sealed class CoseKey
{
    private CoseKey();

    public static CoseKey FromKey(RSA key, RSASignaturePadding, HashAlgorithmName);
    public static CoseKey FromKey(ECDsa key, HashAlgorithmName);
    public static CoseKey FromKey(MLDsa key);

    public int AlgorithmId { get; }
    public int KeyType { get; }

    public byte[] ExportCoseKey();
    public static CoseKey ImportCoseKey(ReadOnlySpan<byte> source);
}

(for example)

And that CoseSigner should really have been CoseKey plus protected and unprotected headers.

Verify only needs the CoseKey, not the full signer. And, voila, we've broken up with AsymmetricAlgorithm.

--

Import/export to COSE_Key format can, of course, be put off until someone asks for it. But keeping it in mind helps name the type. Similarly, we could make the KTY and Alg values internal unless we have a reason to expose them. I'm just thinking forward.

This is going to eagerly check if RSA-PSS is supported in the static constructor which affects test discovery times. We should do this lazily like we do for IsVbsAvailable.

Shouldn't use new() here.