[Dawn Wang (DawnWang17)]

Summary Adds four signing options to CoseSignTool and removes a hardcoded RSA padding choice. ### 1. Hash algorithm selection --HashAlgorithm / --ha on sign, and --aas-hash-algorithm for the Azure Artifact Signing provider. Accepts SHA256 (default), SHA384, SHA512, case-insensitively and with an optional dash (sha-384). The indirect signature path already supported SHA384 end-to-end; the direct sign path was hardcoded to SHA256. ### 2. CBOR-valued custom headers --CborProtectedHeaders / --cbph and --CborUnProtectedHeaders / --cbuh take label=base64 pairs and place the decoded bytes into the header verbatim. The existing int and string header options encode values on the caller's behalf, so they cannot express a structure that is already CBOR-encoded — for example an existing vendor signature blob carried alongside the COSE signature. Each decoded value must be exactly one well-formed CBOR data item; malformed CBOR, trailing bytes, invalid base64, and empty values are rejected during argument parsing rather than producing a signature with an undecodable header. Labels that parse as an integer become integer header labels, anything else becomes a string label. ### 3. RSA signature padding (RS* algorithm support) --aas-rsa-padding selects PSS (default) or PKCS1. The COSE algorithm prefixes PS and RS are accepted as aliases. This is the part that actually makes RS256/RS384/RS512 reachable: CoseSign1MessageFactory previously hardcoded RSASignaturePadding.Pss for every RSA key, so no combination of options could produce an RS* signature. | --aas-hash-algorithm | PSS (default) | PKCS1 | |---|---|---| | SHA256 | PS256 | RS256 | | SHA384 | PS384 | RS384 | | SHA512 | PS512 | RS512 | The padding is exposed through a new optional capability interface, ISupportsRsaSignaturePadding, following the existing ISupportsScittCompliance pattern. It is deliberately not a member of ICoseSigningKeyProvider: that interface targets netstandard2.0, which does not support default interface implementations, so adding it there would be a breaking change for external implementers. Providers that do not implement it keep the previous PSS behavior. ### 4. Credential exclusion and caching --aas-exclude-credentials takes a comma-separated list, and the same list may be supplied as an ExcludeCredentials JSON array. Names are case-insensitive with an optional Credential suffix. An unrecognized name throws rather than being silently ignored, since silently ignoring it would leave a credential the caller believes is excluded still in the chain. DefaultAzureCredential probes its chain in order and a credential that cannot succeed still costs a timeout, so excluding known-inapplicable credentials removes that delay. Credentials are also now cached per distinct exclusion set rather than constructed per signing call. DefaultAzureCredential caches tokens for its own lifetime, so the previous per-call construction discarded the token cache and re-authenticated for every artifact. ## Testing Full suite passes: 1281 passed, 0 failed across all 13 test projects. New tests: - HashAlgorithmHelperTests — valid/invalid names, casing, dashes, defaults, configuration binding. - RsaSignaturePaddingHelperTests — all padding spellings and the full hash x padding -> COSE algorithm mapping. - CborHeaderHelperTests — integer vs string labels, protected vs unprotected placement, preservation of existing headers, base64 padding in values, and rejection of malformed specs, invalid base64, empty values, malformed CBOR, and trailing bytes. - RsaSignaturePaddingTests — signs real messages and asserts the COSE alg header is -257/-258/-259 (RS256/RS384/RS512) and -37/-38/-39 (PS256/PS384/PS512), plus a regression test that a default provider still produces PS256. - AzureCredentialFactoryTests — cache reuse for equivalent exclusion sets, distinct instances for different sets, name normalization, unknown-name rejection, and GetExclusions from both the CLI value and the JSON array. Also verified end-to-end from the built CLI: signing with --HashAlgorithm SHA384 --CborProtectedHeaders produced a COSE_Sign1 with alg = PS384 and both CBOR headers present with byte-identical values. New test project CoseSignTool.AzureArtifactSigning.Plugin.Tests is added to the solution and to .github/workflows/dotnet.yml, matching the existing plugin test projects. ## Docs docs/CoseSignTool.md and docs/CertificateProviders.md updated with the new options, the algorithm mapping table, and the credential exclusion list.

5. Azure Artifact Signing MST proxy

mst_register now accepts --proxy-endpoint, --account-name, --cert-profile-name, and optional --correlation-id. When --proxy-endpoint is supplied, the command calls Azure.ArtifactSigning.MST.TransparencyClient.RegisterTransparencyAsync; without it, the existing direct-ledger behavior is unchanged.

CoseSignTool mst_register \
  --endpoint https://debugruisuprivatetrust.confidential-ledger.azure.com \
  --proxy-endpoint https://api-canary.northcentralus.codesigning.azure.net/ \
  --account-name MyAccount --cert-profile-name MyProfile \
  --payload sample_payload.txt --signature sample_payload.cose \
  --output registration-result.json

The proxy authenticates with DefaultAzureCredential and returns the application/cose transparency receipt in the JSON output. It uses Azure.ArtifactSigning.MST 0.1.186-jaxel-add-artifact-signing-mst-sdk.5 from the Prod-RW-ACS feed; the package's Azure.Core 1.62 dependency is isolated to the MST plugin.

Proxy-path tests cover option wiring, SDK request arguments and COSE body, receipt output, validation, and preservation of the direct path. Full suite: 1285 passed, 5 skipped, 0 failed. Debug and Release solution builds pass with 0 warnings.

[Musabbir Khan (musabbir)]

 LoadSigningKeyProvider()  branches to  LoadSigningKeyProviderFromPlugin() , which calls  plugin.CreateProvider(configuration, …)  and never reads  HashAlgorithm . Only the local-certificate branch consumes it. So:

cosesigntool sign --HashAlgorithm SHA512 --aas-endpoint … → signs SHA256

The operator asked for SHA512, got SHA256, and nothing said otherwise. Should it fail when  --HashAlgorithm  is combined with a plugin provider.

[Musabbir Khan (musabbir)]

Consider adding an option to specify a CBOR file for the protected header.
Base64 strings can be quite large and requires copy/pasting.

For file: --cbph ext-sig file.cbor
for base64 string --cbph ext-sig=gaUBOQEABFRTRvP3y8JLG....

[Musabbir Khan (musabbir)]

Should we consider adding a size check to the cbor header?

[microsoftruisu]

Follow-up fix for COSE statement issuer generation: DawnWang17#2

The Artifact Signing certificate carries both tenant- and profile-scoped EKUs. The current deepest/greatest heuristic selects the tenant EKU, causing MST policy rejection. This PR selects the trailing profile-scoped EKU. Verified with 61 tests and a live MST SDK registration returning HTTP 200.