Add support for ГОСТ Р 34.10 digital signatures

- Implemented the GostKeyValue class for handling public key parameters in ГОСТ Р 34.10 digital signatures.
- Created the GostSignedXml class to manage XML signatures using ГОСТ 34.10, including methods for computing and checking signatures.
- Developed the GostSignedXmlImpl class to encapsulate the signature computation logic and public key retrieval.
- Added specific key value classes for ГОСТ Р 34.10-2001, ГОСТ Р 34.10-2012/256, and ГОСТ Р 34.10-2012/512 to support different signature algorithms.
- Ensured compatibility with existing XML signature standards while integrating ГОСТ cryptography.

docs/security/rootpack_ru_validation.md

@@ -2,7 +2,7 @@
 
 ## Purpose
 
-This runbook documents the repeatable steps for validating the Russian sovereign crypto profile (CryptoPro + PKCS#11) prior to publishing a RootPack bundle. It supplements the crypto routing audit by covering deterministic tests, hardware validation, and the audit metadata artifacts that must be attached to each release.
+This runbook documents the repeatable steps for validating the Russian sovereign crypto profile (CryptoPro on Windows, OpenSSL/Bouncy-managed on Linux, plus PKCS#11) prior to publishing a RootPack bundle. It supplements the crypto routing audit by covering deterministic tests, hardware validation, and the audit metadata artifacts that must be attached to each release.
 
 ## 1. Deterministic Test Harness
 
@@ -20,14 +20,20 @@ This runbook documents the repeatable steps for validating the Russian sovereign
 1. Install CryptoPro CSP (v5.0 or later) on the validation host and import the qualified certificate configured for the deployment.
 2. Configure `StellaOps:Crypto:CryptoPro:Keys` with the container handle and certificate thumbprint and set `StellaOps:Crypto:Registry:ActiveProfile=ru-offline`.
 3. Run the provider diagnostics to confirm the key material is visible:
-   - `stellaops crypto providers --profile ru-offline --json > logs/ru_cryptopro_providers.json`
+   - `dotnet run --project src/Tools/StellaOps.CryptoRu.Cli -- providers --config etc/rootpack/ru/crypto.profile.yaml --profile ru-offline --json > logs/ru_cryptopro_providers.json`
 4. Issue a JWKS fetch (`curl https://authority.local/.well-known/jwks`) and verify the `kid` and `crv` values match the CryptoPro-backed key.
 5. Capture the Authority logs showing `AuthoritySecretHasherInitializer` startup and the `CryptoProviderMetrics` counters for `ru.cryptopro.csp` usage.
 
+### 2.1 Hardware Validation (OpenSSL/Bouncy Linux path)
+
+1. Install OpenSSL with the `gost` engine (or vendor equivalent) on the validation host and import the PEM key/cert that will back `StellaOps:Crypto:OpenSsl:Keys`.
+2. Configure the `OpenSsl` section (PEM path plus `PrivateKeyPassphraseEnvVar`), keep `StellaOps:Crypto:Registry:ActiveProfile=ru-offline`, and restart the services.
+3. Execute a signing workflow and confirm `CryptoProviderMetrics` records `ru.openssl.gost` activity. Linux nodes should no longer attempt to load `ru.cryptopro.csp`.
+
 ## 3. Hardware Validation (PKCS#11 Tokens)
 
 1. Install the vendor PKCS#11 library (e.g., Rutoken `rtPKCS11ECP.dll` or JaCarta) and configure the slot/PIN inside `StellaOps:Crypto:Pkcs11:Keys`.
-2. Switch the registry profile to prioritize `ru.pkcs11` and rerun `stellaops crypto providers --profile ru-offline --json > logs/ru_pkcs11_providers.json`.
+2. Switch the registry profile to prioritize `ru.pkcs11` and rerun `dotnet run --project src/Tools/StellaOps.CryptoRu.Cli -- providers --config etc/rootpack/ru/crypto.profile.yaml --profile ru-offline --json > logs/ru_pkcs11_providers.json`.
 3. Execute a signing workflow (Authority JWKS refresh or Scanner manifest publish) and confirm the `CryptoProviderMetrics` counters record `ru.pkcs11` activity.
 4. Export the token audit logs (if available) and store them with the RootPack evidence bundle.