GOST Provider Validation

GOST signing evidence is provider-backed. The in-process StellaOps.Cryptography.Plugin.Gost provider is a local software harness for GOST R 34.11-2012 hashes and explicit generated GOST-R34.10-2012-256 test signing only. It must not advertise generated GOST-R34.10-2012-512 signing.

GOST support is a regional cryptography route, not a bank-specific feature. Stella Ops keeps an open-source substitution path for deployments whose certification policy allows it, and reserves vendor-specific routes for installations that require certified provider evidence.

Production GOST 2012-512 signing must resolve to one of the provider-backed routes:

Route selection is fail-closed. A configured provider hint that cannot satisfy the requested GOST capability and algorithm must fail instead of falling back to another provider. If no provider advertises GOST12-512 signing, the registry must reject signing rather than using the local software harness or simulator aliases.

CI may use deterministic provider contract harnesses to prove provider name, key id, algorithm, and fail-closed behavior. These tests are not release signing evidence. Licensed CryptoPro CSP validation remains operator-provided evidence unless CI is explicitly provisioned with the licensed package and matching key material.

ARM64 Note

Stella Ops first-party .NET service images are ARM64-ready on Debian/Ubuntu glibc linux-arm64. Local Russian vendor GOST providers are not supported on ARM64 Stella Ops installations in this release unless the operator obtains a provider-supported Debian/Ubuntu linux-arm64 package and matching route evidence. Operators who require a certified Russian GOST provider on ARM64 should contact their GOST provider and request ARM64 Linux support for the target container ABI. Where certification rules allow substitution, use the OpenSSL GOST or PKCS#11 routes above instead of depending on a local vendor-specific package.