Common Criteria Readiness — Direction, Requirements, and Sequence

Version. v0.2 Date. 2026-08-11 Status. Direction document — governs CC-readiness work across the DUNIN7 root componentry. Supersedes v0.1. v0.1 → v0.2 delta. Scope reworked to the two-tier model (root componentry in, application layer out); Stele and FORAY added as third and fourth products, gated; AI-first standing principle added; FIPS 140-3 and public-blockchain items added; two interface contracts added as immediate work; government-credibility posture recorded. Tessera reclassified from "gated product" (v0.1 position) to application-layer consumer (corrected position — Tessera is a use case exploiting root capabilities, not root componentry). Posture. CC-ready, not CC-certified. No lab engagement, no certification claim, until a named buyer or partner puts certification in a deal.

1. Scope — the two-tier model

Tier 1 — Root componentry (in CC scope, managed as potential CC-certifiable):

Tier 2 — Application layer (out of CC scope by architecture):

Tessera, PartsPilot, and every future application. Applications exploit root capabilities; they do not carry the assurance burden. The CC surface of the suite is fixed at four products regardless of how many applications are built.

Composition note. If a buyer ever demands certification of a specific application (plausible for Tessera in government redaction markets), the answer is a small application-scoped ST that draws the TOE around application logic and cites the certified roots as operational environment — a bounded effort, not a fifth root-level program.

Track resolution (the question that started this work). The data protection track is wrong for OVA (seed-fence conflict) and was never GRANTHA's shape. The data-protection-adjacent lane belongs to FORAY — audit-record integrity protection is what FORAY genuinely does. Each product certifies in its own correct category.

2. Standing principles

1. AI-first. Adversaries, consumers, and principals are assumed autonomous by default; human is the special case. Consequences: (a) threat models assume an AI adversary as baseline — tireless, correlating at scale, probing at machine speed; (b) specs, APIs, and operational documents are authored machine-consumable; (c) autonomous principals are first-class in every identity and authorization design. This names a principle the designs already obey (GRANTHA agentic-native, Stele agent-first-class, OVA principal-nature-blind) so it becomes checkable instead of accidental.
2. Claim discipline. Permitted language: "designed to Common Criteria EAL4 assurance requirements," "evaluation-ready." Never "certified," "validated," "CC compliant," or any wording implying a certificate exists. Applies to website, seeds, specs, and sales material.
3. Readiness must not drag. CC-readiness creates no version fixity and no scope pressure before v1.0. An SFR with no backing REQ means the ST claims too much — trim the ST, not grow the product. If readiness starts vetoing design decisions, the methodology is misfiring; raise it.
4. Assurance frame: EAL4+ augmented (candidate augmentations AVA_VAN.5, ADV_SPM) as design target only. The formal verification work is claimed as augmentation evidence, not as a bid for EAL6.
5. Partner-sponsor is the preferred funding shape at trigger time. The readiness evidence pack is what makes that conversation cheap: a sponsor pricing our certification is pricing documentation risk, and ours is near zero.
6. Credibility posture (government/defense). Evaluation-readiness gets us into the room and through the technical conversation — a single-inventor operation with formal verification, ST documents, and a prior EAL2+ evaluation (SBX Enigma) speaks the evaluators' native language. It does not by itself win procurement; actual listing generally requires a completed evaluation. The certificate comes with the buyer's or partner's money.

3. Requirements

3.1 Suite-wide

• R-CC-1. Each Tier 1 product maintains its ST document as a versioned living artifact, updated when the underlying spec changes materially.
• R-CC-2. Every SFR identifier and category label is a candidate until grounded verbatim against published CC:2022 / CC-portal text. Ungrounded items carry CC-GROUND. Same discipline as REQ citation grounding: nothing cited from memory.
• R-CC-3. TOE boundary decisions are written as decision records before they shape spec content.
• R-CC-4. Acceptance criteria remain binary and measurable (existing forge-spec discipline; second consumer: ATE evaluators).
• R-CC-5. Verification artifacts remain standalone versioned documents — the ADV/AVA evidence pack.
• R-CC-6. Flaw-remediation (ALC_FLR) and delivery (ALC_DEL) procedure templates authored when operational docs are first authored; not before.
• R-CC-7. Threat models in all Tier 1 ST documents adopt the AI adversary as baseline (Principle 1a).
• R-CC-8. Cryptographic implementations build on FIPS-validated libraries where available, and the choice is recorded per deployment — FIPS 140-3 readiness by construction, not validation. CC-GROUND current FIPS 140-3 status and validated-module lists at CC-0.
• R-CC-9. The public-blockchain question gets a written answer before any government-facing conversation: why a public permissionless chain (Kaspa) as environment is an integrity feature and not a data-exposure risk. This is expected to be the hardest question in any government room — harder than anything CC asks — and the answer must exist as a versioned document, not improvisation.

3.2 OVA

• R-CC-10. TOE boundary: the off-chain OVA application. Kaspa L1, the KIP-16 verifier, FORAY, and consumers are operational environment.
• R-CC-11. The REQ→SFR mapping must be re-grounded by CC against the live spec (V3.2) before treated as authoritative; stale-risk rows are flagged in the skeleton.
• R-CC-12. The FPR family (unlinkability, anonymity, unobservability) is OVA's differentiating claim set. Any amendment weakening an FPR-mapped REQ is raised to the Operator before authoring — same mechanism as the seed fence. The AI-first adversary sharpens, not changes, the existing conclusion: the temporal axis (REQ-V1) matters more under a tireless correlating adversary.

3.3 GRANTHA

• R-CC-13. CC posture embedded from the first spec row via GRANTHA_CC_HANDOFF-v0_2.md.
• R-CC-14. Stele and FORAY (including the unbuilt batching mode) are operational environment; OVA, where consumed, is environment.
• R-CC-15. Administration-is-access expressed through FMT with an explicit ST argument — argued, never assumed.
• R-CC-16. Grant-composition formal verification structured as ADV_SPM-shaped evidence.

3.4 Stele (gated)

• R-CC-17. ST frame authored when Stele reaches spec-shaped maturity — not before; premature frames against unsettled designs are maintenance debt.
• R-CC-18. Stele's ST work is expected to break new ground arguing agent identity into FIA terms — the suite's most novel ST argument, and a differentiation asset of the same kind as GRANTHA's administration-is-access.

3.5 FORAY (gated)

• R-CC-19. ST skeleton authored when the bundle-then-anchor batching mode is built. FORAY is simultaneously the most certifiable product (complete, live, frozen at v4.1 — could enter evaluation tomorrow) and the wrong one to certify now (a v4.1 certificate could not be cited by GRANTHA's A.FORAY assumption, which is written against the unbuilt mode).
• R-CC-20. FORAY's self-evidencing property — a tamper-evident, on-chain-anchored audit trail is close to what ALC and operational-integrity evidence establishes by procedure — is recorded as an ST argument no conventional audit product can make.

3.6 Interface contracts (immediate cross-cutting work)

• R-CC-21. Stele principal-reference contract — what Stele guarantees about authenticated principal references (including the human-vs-autonomous nature property already requested of the Stele owners), consumed by GRANTHA. Substance of A.STELE from GRANTHA's side; TOE-description material from Stele's side. Authored as a versioned document; needed regardless of CC.
• R-CC-22. FORAY emission contract — what consumers hand FORAY, what FORAY guarantees back, including the batching mode's intended guarantees. Substance of A.FORAY for both existing STs; TOE-description material for FORAY's eventual skeleton; resolves GRANTHA's dependency on the unbuilt mode in writing.

4. Sequence

5. Cost acceptance

Three layers: (1) existing discipline — binary ACs, versioned artifacts, formal verification, findings ledgers, git — costs zero and is the majority of the evidence; (2) the readiness delta — ST maintenance, mapping rows during authoring, boundary checks, contracts, claim discipline — accepted at roughly 5–10% overhead on spec-authoring sessions, amortized into work already being done; (3) actual evaluation — 12–24 months, six figures — deferred to the CC-10 trigger and expected to arrive with the buyer's or partner's money.

6. Standing risks

• Category/PP drift. CC-portal categories and the NIAP catalog change; CC-0 results decay. Re-ground at trigger time.
• Version fixity. Nothing pre-trigger creates fixity obligations; do not let readiness slow spec evolution.
• Scope creep via CC. Readiness never adds features (Principle 3).
• Application-layer creep. Tier 2 stays out. A request to bring an application into CC scope is answered with the composition note, not with a fifth root program.