Regional & sovereign cryptography
One evidence chain. Pluggable signing.
Signing is pluggable per jurisdiction. The custody spine, the capsule format and the verification flow stay identical — only the cryptographic profile changes.
It changes how evidence is signed, never what the evidence says.
The default profiles
Out of the box, evidence is signed with Ed25519 or ECDSA P-256 and packaged in signing envelopes. DSSEDead Simple Signing Envelope - a simple, flexible standard for signing arbitrary data with cryptographic signatures
The default signing profile, backed by libsodium.
The default alternative for ecosystems standardised on NIST curves.
Switching profiles does not alter capsule contents. The same evidence is signed under a different algorithm, and both verify the same way.
Jurisdiction profiles
Each profile below is implemented on real cryptographic libraries — not stubs. Pick the profile your regulator or procurement framework expects.
FIPSFederal Information Processing Standards - U.S. government cryptographic standards for secure systems · eIDASElectronic IDentification, Authentication and trust Services - EU regulation for electronic signatures and trust services · SM2Chinese national public key cryptography standard (part of ShangMi suite) required for regulated industries
A restricted algorithm set — RSA, ECDSA, AES-GCM, SHA-2 — for estates that must stay inside FIPS-approved primitives.
Qualified timestamp verification, EU Trust List service, and CAdES signature building.
Stella Ops is not a trust service provider or qualified trust service provider under eIDAS. Stella Ops does not itself provide qualified electronic signatures, qualified electronic seals or qualified electronic time stamps, and does not claim the legal presumptions reserved for qualified trust services. It consumes operator-supplied qualified trust material and records evidence.
SM2 signing, SM3 hashing and SM4 encryption — the Chinese national standards suite.
PKCS#11 integration for hardware-backed keys: RSA, ECDSA and AES-GCM through your existing HSM.
One artifact signed concurrently under several profiles. Dual-stack signatures are verified in tests, so a release can carry a default profile alongside a regional one, each verifiable on its own.
Profile availability describes what the software can do. Certification, validation, and legal effect depend on your modules, your keys, and your assessors.
Additional regional profiles exist and are covered in the technical documentation. See the full profile matrix in the docs
Production vs simulator — the discipline
A signature is only as trustworthy as the provider behind it. Every crypto provider reports its own health, with three flags that decide what its signatures are allowed to back. Simulator providers can never satisfy release evidence.
production
The provider is a real cryptographic implementation, running against real key material.
testOnly
The provider is a simulator. Useful for integration testing; excluded from release evidence by design.
releaseEvidence
Whether this provider's signatures are eligible to back a release decision at all.
The provider health endpoint also reports drift: any divergence between the provider's expected and observed configuration.
Non-empty drift fails closed for release decisions. No override flag, no warn-and-continue.
Post-quantum readiness
The CBOM post-quantum analyzer assesses your cryptographic inventory and reports where quantum-vulnerable algorithms are in use.
Assessment only: it reports readiness, it does not change how evidence is signed.
Where this fits
European vendor, Swiss-hosted infrastructure, self-hosted, air-gap capable — the wider sovereignty story these profiles belong to.
Profile-signed evidence feeds the NIS2, DORA and CRA packs. Enabling a pack starts evidence collection in conservative evidence-only mode; it does not claim regulatory compliance.