Fix EKU parsing for five-octet Azure OID arcs

[nurfed1]

Problem

Azure Artifact Signing certificates include profile-specific EKUs alongside id-kp-codeSigning. Some arcs in the Azure identity EKUs are greater than 2^28 - 1, so their valid base-128 DER representation requires five octets. The values still fit in u32; they are not oversized OID arcs.

For example, the affected certificates contain identity EKUs such as:

• Public Trust Test: 1.3.6.1.4.1.311.97.1.2.548345392.570456524.348779735.628493769
• Public Trust: 1.3.6.1.4.1.311.97.872172236.817999856.585183201.971782747

The portable trust path currently decodes the complete EKU sequence through x509-cert 0.2.5 / der 0.7 / const-oid 0.9.6. That const-oid version calculates the maximum encoded arc length as the byte width of u32 (four), rather than the five base-128 octets needed to represent all u32 values. As a result, decoding fails on the unrelated Azure identity EKU before psign can observe the ordinary code-signing EKU.

RustCrypto fixed the underlying arc-length calculation in RustCrypto/formats#1592.

Change

This changes only the strict code-signing EKU presence check in the portable CMS fallback. Instead of materializing every EKU as a fixed-width ObjectIdentifier, it:

• parses the extension as one complete DER SEQUENCE, rejecting trailing data;
• requires every sequence member to be an OBJECT IDENTIFIER;
• validates that every OID value is complete and uses canonical base-128 subidentifier encoding;
• compares the encoded value directly with id-kp-codeSigning.

The parser continues validating entries after finding id-kp-codeSigning, so a matching entry cannot hide a malformed later entry.

This does not disable or weaken strict signing-certificate validation. In particular, it avoids requiring --allow-loose-signing-cert, which bypasses the EKU requirement rather than addressing the decode failure. Trust-anchor selection, chain validation, and the required code-signing EKU are unchanged.

Why this is a compatibility bridge

The long-term fix is to move psign's RustCrypto CMS/X.509 dependency graph to versions using the corrected const-oid implementation. That cannot currently be done as an isolated direct dependency bump:

• google/authenticode-rs#199 updates authenticode-rs's direct const-oid dependency, but the cms 0.2 / x509-cert 0.2 path still retains const-oid 0.9.
• google/authenticode-rs#270 demonstrates that updating x509-cert alone leaves incompatible x509-cert 0.2 and 0.3 certificate types because cms 0.2 still uses the older stack.
• The coordinated cms, der, spki, x509-cert, and authenticode-rs migration currently involves prerelease APIs.

This scoped parser is therefore intended as a temporary compatibility fix. It can be removed in favor of the normal ExtendedKeyUsage decoder once that dependency stack can be upgraded together.

Tests and validation

Unit tests cover:

• the complete Azure Public Trust Test EKU set;
• the complete Azure Public Trust EKU set;
• a valid EKU sequence without id-kp-codeSigning;
• canonical unknown arcs wider than u32, which are safe to skip because they are never materialized;
• truncated and non-minimal base-128 OID encodings;
• non-OID sequence entries and trailing DER data;
• malformed entries appearing after a code-signing match.

Validation performed:

• cargo fmt --all -- --check
• the same portable clippy command used by ci-unix.yml, with -D warnings
• cargo test --workspace --lib --bins --locked
• live verification with certificates returned by both Azure Artifact Signing Public Trust Test and Public Trust profiles