govoplan-voting/docs/CERTIFIABLE_VOTING_PROGRAM.md

Native certifiable Voting program

Objective and non-claim

GovOPlaN may develop a native end-to-end verifiable Voting provider, but the current platform and bundled local_confidential provider are not certified voting products. Certification cannot be obtained by adding a label, tests, or general platform security controls. It applies to a precisely bounded Target of Evaluation (TOE), version, evaluated configuration, lifecycle, and evidence set assessed by an independent laboratory and certification authority.

The native provider must therefore be an isolated assurance component behind voting.provider.<id>, not an implicit claim over all of GovOPlaN. Voting owns the governed ballot lifecycle and evidence projection; the TOE owns ballot secrecy, cryptographic casting, verification, tallying, and the evaluated ceremony. Policy, Access, Identity Trust, Encryption, Forms Runtime, Workflow Engine, Committee, Decisions, Audit, Records, and Reporting may support the journey without being silently pulled into the TOE.

Program stages

1. Protection profile and legal target

• identify election classes, jurisdictions, attack potential, voting principles, accessibility duties, and retention obligations;
• select the applicable BSI Protection Profile/TR and Common Criteria target;
• engage a recognized evaluation facility before fixing the architecture;
• write the Security Target, assumptions, threats, organizational policies, security objectives, and evaluated configuration.

2. TOE and trust boundaries

• specify client, election server, bulletin board, verifier, tally component, key ceremony, build/release chain, time source, and operator boundaries;
• define electorate preparation and archival as explicit supporting processes when they are outside the TOE;
• prohibit node-local authoritative state and undeclared side channels;
• define compromise, suspension, challenge, annulment, recovery, and evidence export before implementation.

3. Protocol and independent review

• select a published, independently reviewed end-to-end verifiable protocol;
• use reviewed cryptographic libraries and parameter suites rather than designing new cryptography;
• provide individual and universal verification without exposing vote choice;
• define coercion-resistance claims truthfully, including what is not solved;
• commission independent cryptographic and privacy review before production.

4. Conformance implementation

• implement canonical ballot/electorate/result/evidence encodings;
• bind every cast and tally artifact to the frozen definition and electorate;
• provide deterministic conformance fixtures, malformed-input suites, property tests, fault injection, and cross-implementation verification;
• preserve receipt privacy and prevent credentials, raw votes, or private keys from entering GovOPlaN evidence projections;
• expose certification state through VotingProviderAssuranceDeclaration.

5. Controlled lifecycle

• reproducible, signed builds and reviewed dependencies;
• role-separated source, release, election, key-custody, and audit authority;
• vulnerability handling, maintenance impact analysis, SBOM, provenance, and controlled update path for in-progress elections;
• production ceremonies, backup/restore, disaster recovery, secure deletion, monitoring, incident response, and independently witnessed evidence.

6. Evaluation and operation

• laboratory pre-evaluation and gap remediation;
• formal Common Criteria evaluation/certification of an exact TOE version;
• target-specific deployment acceptance against the evaluated configuration;
• certificate and maintenance-report monitoring;
• fail-closed retirement or profile downgrade when validity expires or the evaluated configuration changes.

Work-product gates

Native implementation can proceed through fixtures and research profiles, but the external_certified runtime profile remains unavailable until all of these are independently evidenced:

• approved Security Target and TOE boundary;
• independent protocol/cryptographic review;
• conformance and adverse-condition evidence;
• controlled build and release provenance;
• operational ceremony and recovery evidence;
• valid product/version/configuration-specific certificate.

Research, evaluation, and certified states are separate. A provider in evaluation may support a bounded test profile, but cannot become certified by configuration or administrator override.