Common Criteria Readiness — Direction, Requirements, and Sequence

Version. v0.1 Date. 2026-08-11 Status. Direction document — governs CC-readiness work across OVA and GRANTHA. Authored by Claude.ai with the Operator; grounding actions assigned to CC. Scope. Both products. OVA (spec exists, V3.2 live) and GRANTHA (pre-record, no spec yet). Posture. CC-ready, not CC-certified. No lab engagement, no certification claim, until a named buyer or partner puts certification in a deal.

1. Direction (the settled decisions)

These were settled in the originating session and are restated here as the standing frame:

1. Category: Access Control Devices and Systems — for both products. The data protection track is wrong for OVA (it collides with the seed's fence: OVA must not carry, store, protect, or release a data object). If a data-protection-track certification is ever wanted, it belongs to the future separate data-object-protection mechanism, not OVA.
2. Target assurance frame: EAL4+ augmented (candidate augmentations: AVA_VAN.5, ADV_SPM), claimed as design target only. Not EAL6 — the formal verification work is claimed as augmentation evidence, not as a bid for high-assurance evaluation.
3. Certification is a post-v1.0 activity against a frozen TOE. Readiness work now; evaluation only on commercial trigger.
4. Partner-sponsor is the preferred funding shape when the trigger comes. The readiness evidence pack is what makes that conversation cheap.
5. Claim discipline (standing rule). 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.

2. Requirements (what CC-readiness obligates, per product)

2.1 Both products

• R-CC-1. Maintain a Security Target skeleton as a versioned living document (OVA: OVA_ST_SKELETON-vN_M.md; GRANTHA: GRANTHA_ST_FRAME-vN_M.md), updated when the underlying spec changes materially.
• R-CC-2. Every SFR identifier used in ST documents is treated as a candidate until grounded verbatim against the published CC:2022 Part 2 text. Ungrounded identifiers carry the flag [CC-GROUND]. This is the same discipline as REQ citation grounding: no component cited from memory.
• R-CC-3. TOE boundary decisions are written down as decision records before they shape spec content, not after.
• R-CC-4. Acceptance criteria in all specs remain binary and measurable (existing forge-spec discipline). This is unchanged practice, now with a second consumer: ATE evaluators.
• R-CC-5. Verification artifacts remain standalone, versioned documents (existing practice) — they are the ADV/AVA evidence pack.
• R-CC-6. Add the two assurance areas current practice does not naturally produce, when operational docs are authored: flaw remediation procedure (ALC_FLR) and delivery procedure (ALC_DEL). Templates only, pre-v1.0.

2.2 OVA-specific

• R-CC-7. The OVA TOE boundary is the off-chain OVA application (egg lifecycle, abstract proof interface, interrogation handler). Kaspa L1, the KIP-16 verifier, FORAY, and consumer applications are operational environment, expressed as environmental assumptions. This boundary informs how Deferred Cycle C rows are eventually authored.
• R-CC-8. The REQ→SFR mapping in the ST skeleton must be re-grounded against the live spec (V3.2) by CC before it is treated as authoritative. The v0.1 mapping was authored against the V3 copy available to Claude.ai; specific stale-risk rows are flagged in the skeleton.
• R-CC-9. The FPR family (unlinkability, anonymity, unobservability) is OVA's differentiating claim set and must survive every future spec amendment. Any amendment that weakens an FPR-mapped REQ is raised to the Operator before authoring — same mechanism as the seed fence.

2.3 GRANTHA-specific

• R-CC-10. CC posture is embedded from the first spec row, not retrofitted. The GRANTHA handoff document (GRANTHA_CC_HANDOFF-v0_1.md) carries the standing obligations into the GRANTHA project.
• R-CC-11. Stele is operational environment (identity assurance stays outside the TOE). FORAY is operational environment (including the future batching mode). The TOE is the grant engine: issuance, evaluation, revocation, composition.
• R-CC-12. The administration-is-access model is expressed through FMT components with an explicit ST argument — it is an unconventional reading and must be argued, never assumed.
• R-CC-13. The grant-composition formal verification target is structured as ADV_SPM-shaped evidence (formal security policy model), mirroring OVA's verification program pattern.

3. Sequence

| Step | What | Owner | Gate / trigger | |---|---|---|---| | CC-0 | Ground CC:2022 status, exact Part 2 component wording for FDP / FCS / FPR / FMT / FIA / FPT / FAU / FTP candidates, current CC-portal category definitions, and current NIAP PP catalog for access-control-adjacent PPs. Clear all [CC-GROUND] flags in both ST documents. | CC (web retrieval) + Claude.ai (judgment) | Immediate. Blocks nothing but flag-clearing. | | CC-1 | OVA: re-ground the REQ→SFR mapping against live V3.2; resolve the flagged stale-risk rows; record the TOE boundary decision as a decision record in protocols/ova/design/. | CC grounds; Claude.ai authors v0.2 | Immediate, after CC-0. | | CC-2 | GRANTHA: deliver the handoff into the GRANTHA project; CC posture governs Discovery→spec transition and all REQ authoring. | Operator delivers; GRANTHA project executes | Immediate. | | CC-3 | GRANTHA ST frame gains a real REQ→SFR mapping as GRANTHA REQ rows come into existence. | GRANTHA project | As spec is authored. | | CC-4 | ALC_FLR / ALC_DEL procedure templates. | Claude.ai | When operational docs are first authored; not before. | | CC-5 | ST skeletons maintained on spec change; FPR-weakening check (R-CC-9) on every OVA amendment. | Standing | Continuous. | | CC-6 | Dormant. No lab, no consultant retainer, no certification spend. | — | Trigger: a named buyer or named partner puts certification in a deal. On trigger: freeze TOE version, select lab, enter evaluation with the evidence pack. |

4. Standing risks

• Category/PP drift. CC portal categories and the NIAP PP catalog change. Re-ground at CC-6 trigger time; do not rely on CC-0 results if years have passed.
• Version fixity. A certificate binds to one TOE version. Nothing pre-trigger creates fixity obligations; do not let CC-readiness slow spec evolution.
• Scope creep via CC. CC-readiness must not become a reason to add features. An SFR with no backing REQ means the ST claims too much — trim the ST, not grow the product.

DUNIN7 · Done In Seven LLC · Miami, Florida CC Readiness — Direction, Requirements, and Sequence — v0.1 — 2026-08-11