This exception doesn't make sense when there is at least one signature but it used an indefinite length array.

Assuming I recall correctly and that COSE forbids indefinite length arrays then there should be a check for !signaturesLength.HasValue, and a special throw, before this.

(Repeat for basically every place that calls ReadStartArray)

One thing to consider is making a struct wrapper over top of a CborReader (e.g. CoseCborReader) and have it enforce all of these policy things. E.g.

internal struct CoseCborReader
{
    private CborReader _reader;

    internal CoseCborReader(...)
    {
        ...;
    }

    internal int ReadStartArray()
    {
        int? len;

        try
        {
            len = _reader.ReadStartArray();
        }
        catch (CborContentException e)
        {
            ...
        }

        if (!len.HasValue)
        {
            throw new CryptographicException(SR.CoseForbidsIndefiniteArray);
        }

        return len.GetValueOrDefault();
    }
}

In core crypto I've done a similar thing. The AsnValueReader type is a variant of AsnReader, but it always wraps AsnContentException in a CryptographicException (because that's the exception type that the methods threw before we wrote AsnReader)

From https://datatracker.ietf.org/doc/html/rfc8152#section-14, it seems to me that indefinite length is only forbidden for Sig_Structure, the text on that section probably also means that we should use a CborWriter with Canonical conformance mode on CreateToBeSigned.

I can fix the exception messages stating that indefinite-length arrays are forbidden as part of this PR but I would prefer a separate PR to address/validate support of messages using indefinite length arrays, what do you think?

I can't find anything right now stating that indefinite length arrays are forbidden, so for example, can you receive a COSE_Sign message inside a indefinite-length array?

If indefinite length arrays are already inconsistently supported and you'd have to touch currently untouched code to fix it up, then a separate PR makes more sense. If everything that would have to be changed is in this PR already, then we shouldn't merge code we know is wrong.

The current state of the code is the former, an example is CoseMessage.DecodeSign1, it requires a CBOR array of length 4 to successfully decode.