zccusan FIPS overview

Assurances under development

Future-state: TLS service coverage. Direct RPC TLS configurations already check the AWS-LC provider and configuration mode. Review of every TLS client, including clients constructed by dependencies, remains open. A provider probe alone does not establish their call paths or negotiated algorithms.

Future-state: dependency reachability. The source/dependency inventory and review gate retain alternate-provider and frozen-version advisory findings. The new service-assurance checker records resolved dependency paths and binds review dispositions to full source hashes during offline assembly and assessment. Exact-release semantic dispositions are still needed to establish which APIs each shipped executable can invoke. Dependency presence or absence alone does not prove service coverage.

Future-state: aggregate encryption-key budgets. A tested process-lifetime GCM application-frame attempt counter counts recreated keys and concurrent users without eviction or reset, and fails closed at 2^32 attempts. The bounded registry also rejects previously unseen encryption keys once it holds 65,536 keys. Across nodes and restarts, accepted deployment bounds or coordinated durable accounting remain necessary to keep the total random-IV encryptions under each key within 2^32.

Future-state: encryption-budget telemetry. Standard metrics and performance telemetry now expose consumed and remaining process-local application-frame key budgets and limits, with shared actual-key accounting within that service and no public key identifiers. Tests cover accounting and telemetry privacy; full image validation remains pending. Process-local measurements cannot establish a cross-node or restart-persistent aggregate without corresponding shared accounting.

Future-state: TLS key-usage accounting. The application counter observes only frame encryption through approved_crypto::seal. Rustls/AWS-LC TLS record encryption and direct cryptographic calls by dependencies are outside it. Their separate key-usage controls and review remain open; application metrics cannot establish coverage for every cryptographic key in the process.

Future-state: operational acceptance. Review of external entropy, credential generation/import/rotation, TLS certificates and algorithms, self-test failure handling, permitted build/operating conditions, and Security Policy restrictions remains open for the exact release and deployment. Build checks cannot supply the missing operational observations or a vendor's module-use assertions.

The deployment process below describes decisions that can be made once the applicable assurance above is established. It does not describe the current build as accepted or validated. The crypto integration guide tracks the implementation and remaining review work.

zccusan can use validated cryptography through the AWS-LC 3 Cryptographic Module (static), certificate 5314, within its permitted build and operating conditions. The goal is to establish whether a particular zccusan release, configuration, and set of cryptographic operations satisfy the criteria for its use. Build records, configuration records, tests, and technical review support that decision. The following process explains what each record proves and how to obtain it.

For how releases are compiled and checked before publication, see Offline FIPS compilation.

Deployment goals and how to establish them

Each applicable goal below needs a supported conclusion before it can be used in the deployment assessment. The last column identifies standards or policies for which organizations typically use that conclusion. Regulatory references were reviewed on 2026-09-14; use the applicable version and assessment path.

Establishing the scope of protection

To claim coverage for the selected certificate-5314 profile, the installation needs Amazon Linux 2023 userspace and the listed node conditions. Record the actual node and container properties and compare them with the image and environment guidance. An EKS or GKE service name does not identify those properties.

To establish encryption at rest for a zccusan volume, identify where its persisted data is encrypted and which module performs that operation. Repeat that check for replicas and backups. Obtain the responsible storage component's module documentation and inspect its encryption settings. This connects the stored data to its actual protection; transport-encryption tests cannot establish that connection.

To establish protection for Kubernetes API connections, service-mesh traffic, or external key operations, identify the component performing each operation, obtain its module documentation, and verify its active configuration. For hardware-protected keys or a particular module security level, also compare the actual key handling and certificate with the policy being assessed. zccusan's embedded AWS-LC module cannot establish these properties for other components.

Deployment process

1. Define the decision. Record the exact zccusan workload, protected data, applicable criteria, and the person or assessment process that decides whether the deployment satisfies them. Use this scope to select the goals in the table above.
2. Identify the installed release. Obtain and verify the release and module records described in the first row. Retain the installed image digest and executable hashes so subsequent checks apply to the same code.
3. Establish permitted operation. Capture the node and container properties, compare them with the selected profile and Security Policy, and run the installation's acceptance checks. Record differences and resolve those that prevent use under the profile.
4. Establish coverage of the workload. Use the service map, call-path review, key procedures, and tests to account for each covered cryptographic operation. Inspect separate storage and platform components as described under scope. Obtain the vendor letter when following SG-8 or an assessment policy calling for it. Each conclusion must cite the configuration, test, or review record that supports it.
5. Decide whether the deployment meets the selected criteria. The security team or assessor compares the conclusions from steps 2–4 with the criteria recorded in step 1. Resolve missing support or failed checks before recording a positive finding for the affected criterion. Where specialist interpretation is needed, have a laboratory review the specific module-use or environment question and retain its reasoning with that finding.
6. Preserve the basis for the decision. Before changing the image, node, dependencies, or configuration, compare the proposed change with the accepted installation. Recheck certificate status and repeat the affected inspections, tests, and reviews so the decision remains tied to the code and configuration actually in use.

Vendor statement

NIST CMVP FAQ SG-8 instructs organizations verifying validation to request a signed letter from the application or product vendor. For an application incorporating a module, the letter states that it incorporates a validated module, identifies its certificate number, and states that the module supplies all cryptographic services in the solution. The organization checks these assertions against the CMVP entry, including the version and operating environment.

The open-source project does not issue that letter or attest to the identity or authority of release-signing key holders. An end-user organization following SG-8 can obtain the letter from a vendor that builds or verifies its zccusan distribution and can substantiate the assertions for the exact release and configuration. The vendor must account for every cryptographic service in the specified solution before making the all-services assertion.

Recording the deployment decision

The end result of step 5 is a finding about whether the identified zccusan installation satisfies each criterion selected in step 1. To make that finding reviewable, record the image digest, deployment profile and revision, covered services, criterion, assessment date, and unresolved issues. Link each finding to the build, configuration, service-review, and test records gathered in steps 2–4; a missing record leaves the corresponding conclusion unsupported.

For example, after verifying the relevant records, the assessor could write:

zccusan image [digest], deployed under [profile and revision], satisfies [specific cryptographic criterion] for [covered operations]. The build review [reference] identifies the embedded AWS-LC module covered by certificate 5314; the environment review [reference] establishes permitted operation; and the service review and deployment checks [references] establish approved use for those operations. This finding was made on [date].

This finding applies to the identified installation and services. Step 6 explains how to reassess it when they change. It relies on Amazon's existing module validation and does not issue a CMVP certificate for zccusan. See CMVP FAQ P-17.

To verify module identity and permitted conditions, consult the certificate record and its Security Policy. To verify how the embedded module was built, follow the receipt and procedure checks in the AWS-LC recompilation guide. To verify which implementation handles each application operation, use the service mapping and review instructions in the crypto integration guide.