From 410fb550f0a54f51a18fbef931f38a73cb07a652 Mon Sep 17 00:00:00 2001 From: "W. Alexander Ousley" Date: Mon, 12 Oct 2026 15:55:43 +0800 Subject: [PATCH 1/8] docs(crosswalk): NIST SP 800-53 Rev 5 and DoD AI Tailoring Guide mapping for v0.2 claims Adds docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md: for each Trust Record claim, the SP 800-53 controls it is evidence for, what it establishes, what the assessor still needs, and the Tailoring Guide item it answers. Names what a record does not evidence for an authorization package. Nav and CHANGELOG updated. Informative only; no normative change. Signed-off-by: W. Alexander Ousley --- CHANGELOG.md | 1 + .../nist-sp800-53-dod-ai-tailoring.md | 70 +++++++++++++++++++ mkdocs.yml | 1 + 3 files changed, 72 insertions(+) create mode 100644 docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md diff --git a/CHANGELOG.md b/CHANGELOG.md index fd453a11..60ac51a7 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -11,6 +11,7 @@ Format: [Semantic Versioning](https://semver.org/). Spec versions follow `MAJOR. ## [Unreleased] +- **NIST SP 800-53 Rev 5 and DoD AI Tailoring Guide cross-walk.** `docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md` maps each v0.2 Trust Record claim to the SP 800-53 controls it is evidence for, states what each claim establishes and what the assessor still needs, and names the three things a record does not evidence for an authorization package (TEVV results, control implementation across the boundary, non-repudiation against an operator-held key). Includes a citation form for assessment artifacts. Contributed by Antagon Inc. Informative only: no schema, wire-format or normative change. - **Accuracy pass on non-normative text.** Examples, schema descriptions, adapter docstrings and unsigned test records use vendor-neutral placeholders (`example-provider`, `example-model`), the Section 6.2 list keeps confidential-computing and standards diff --git a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md new file mode 100644 index 00000000..e878d364 --- /dev/null +++ b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md @@ -0,0 +1,70 @@ +# NIST SP 800-53 Rev 5 and DoD AI Tailoring Guide Cross-walk + +US federal and Department of Defense systems are authorized under the Risk Management Framework (RMF). An assessor preparing an authorization package asks, for each security control, what evidence shows it is in place. This page says, for each claim in a TRACE v0.2 Trust Record, which SP 800-53 Rev 5 controls that claim is evidence for, what the evidence establishes, and what it does not. It is for ISSOs, assessors, and authorizing-official staff. TRACE records what happened; it does not implement a control. + +> **Non-normative.** This document is informative only. Nothing here changes TRACE v0.2 schema fields, wire formats, required claims, or conformance requirements. References to "TRACE" mean the TRACE v0.2 Trust Record as defined in [`spec/trace-v0.2.md`](../../spec/trace-v0.2.md). Control identifiers are from NIST SP 800-53 Revision 5. Tailoring Guide references are to the DoD CIO *AI Cybersecurity Risk Management Tailoring Guide*, version 2, 14 July 2025, which names controls for AI models in its Table 2-2 and Section 3. + +--- + +## Purpose + +The Tailoring Guide tells a DoD program which SP 800-53 controls to apply to an AI model: integrity (SI-7 and enhancements), provenance (SR-4, SR-4(3)), audit protection (AU-9(3), AU-12(3)), and the inclusion of model test and evaluation (TEVV) results, acquisition source, and training background in the authorization package (§3.1.3, §3.1.5). It does not say how a signed runtime record satisfies any of them. This page closes that gap for TRACE v0.2 so an assessor can cite a Trust Record against a control without inventing the mapping. + +A Trust Record is evidence *for* a control, not an implementation *of* it. The assessor still judges whether the evidence is adequate for the system's impact level. Where a claim's assurance depends on verified attestation, the row says so: naming a TEE in `runtime.platform` does not itself establish hardware backing, and a `software-only` record (§3.1.1) carries software commitments without hardware evidence. See [trust levels](../trust-levels.md). + +Field names are exact TRACE v0.2 claim names from §3.1 and the §3.2 wire-format example. Sub-field references such as `model.weights_digest`, `policy.bundle_hash`, `runtime.measurement`, `appraisal.status`, and `references.rel` refer to the nested fields shown there and in `schema/trace-claim.json`. + +--- + +## Mapping table + +| TRACE claim | SP 800-53 Rev 5 controls | Evidence TRACE can provide | Limitations / what the assessor still needs | Tailoring Guide reference | +|---|---|---|---|---| +| `subject` | IA-2, IA-9, CM-8 | A workload identity (SPIFFE SVID or DID URI) names the agent, tool, or model invocation the record is about; with `cnf` it binds that identity to the record-signing key. Supports non-person-entity identification (IA-9) and a component inventory entry (CM-8). | Identity is asserted by the issuing domain. Which permissions that identity holds in external systems is outside the record. | §3.1.5 component inventory | +| `model` (`model_id`, `version`, `weights_digest`, `aibom_uri`) | SI-7, SI-7(1), SI-7(15), SR-4, SR-4(3), CM-14 | `model.weights_digest` is a digest of the model artifact that ran, so a later integrity check (SI-7(1)) or an authenticity check against a signed manifest (SI-7(15), CM-14) has a value to compare. `model.aibom_uri` points at a bill of materials for SR-4 provenance. | The record commits to the digest; verifying that the digest matches an approved, signed artifact is the assessor's step. `aibom_uri` is a pointer, not attested content. | Table 2-2 SI-7, SR-4 for AI models; §3.1.3 SBOM (OMB M-22-18) | +| `runtime` (`platform`, `measurement`, `rim_uri`) | SI-7(9), SI-7(17), SC-39, SA-19 | `runtime.measurement` is the measured-boot or workload composite digest; with verified attestation evidence and `appraisal.platform_measurement` (§3.1.5) it establishes which layers ran what. Supports boot integrity (SI-7(9)), process isolation (SC-39), and component authenticity (SA-19). | Only when attestation evidence is verified. A `software-only` record establishes none of these; a TEE name alone establishes nothing. Layers not listed as `established` in `appraisal.platform_measurement` are not established. | §2 "protect the integrity ... of AI systems" | +| `policy` (`bundle_hash`, `enforcement_mode`, `version`) | AC-3, AC-6, CM-6, CM-7, SI-10 | `policy.bundle_hash` names the policy set bound to the execution; `policy.enforcement_mode` states whether it was `enforce`d, `advisory`, `silent`, or merely `declared`. Supports configuration-settings evidence (CM-6) and, for `enforce`, access-enforcement evidence (AC-3). | `declared` is not evidence that any rule was checked (schema text). `silent` means denies were allowed. The assessor must read the mode, not just the hash. | §3.1.3 model integrity checks | +| `data_class` | AC-16, RA-2, MP-2 | The classification label the producer applied to inputs and outputs of the execution. Supports security-attribute (AC-16) and categorization (RA-2) evidence. | States the label applied, not which data was read, written, or egressed. | §3.1.1 data origin and reliability | +| `tool_transcript` (`hash`, `call_count`, `transcript_uri`) | AU-2, AU-3, AU-12, AC-6(9), SI-4 | `tool_transcript.hash` is a commitment to the instrumented MCP/A2A transcript and `tool_transcript.call_count` bounds observed call volume. Supports audit-event (AU-2, AU-12) and privileged-function logging (AC-6(9)) evidence at protocol boundaries. | A commitment, not a verbatim log. Calls inside the binary that never crossed an instrumented boundary are not captured. | §3.1.3 AU-6 auditing | +| `origin` (`kind`, `producer`) | AU-3(1), AU-10 | Names who assembled the record when it was not the executing runtime. Lets an assessor distinguish self-produced evidence from a `third-party-control-plane` or `log-import` assembly. | A non-`self` origin MUST carry `runtime.platform: "software-only"` (§3.1.1); the assessor should treat such records as operator-asserted. | — | +| `references` (`rel`, `id`, `resolver`, `digest`) | CA-2, CA-6, SA-11 (as pointers only) | A `condition-appraisal` reference points at an independent check's finding (a test run); an `authorized-intent` reference points at an authorization decided before execution; an `approval-outcome` reference points at a human approval. These let a record be tied to TEVV results and authorization artifacts the package holds elsewhere. | A reference is a pointer, not evidence (§3.1.2 rule 3). The referenced object must be obtained and verified separately; TRACE v0.2 does not define its format. See "What TRACE does not evidence" below. | §3.1.3, §3.1.5 TEVV results in the package | +| `reproducibility` (`function`, `code_identity`, `input_closure`, `transcript_digest`) with `appraisal.re_execution` | SA-11(1), CA-2, SI-7(6) | Where present and re-executed by a verifier with outcome `reproduced` (§3.1.4), establishes that the named deterministic coordination function over the pinned closure yields the recorded transcript. Supports independent re-performance evidence. | `not-attempted` is neither pass nor fail. Establishes nothing about model calls, which are inputs, or about side effects. | — | +| `build_provenance` (`slsa_level`, `builder`, `digest`, `provenance_depth`) | SA-10, SA-11, SA-15, SR-3, SR-4, CM-14 | SLSA provenance for the running code and model: who built it, from what, at what level. `appraisal.provenance_depth_verified` records how deep the verifier checked. Supports configuration-management (SA-10), development-process (SA-15), and supply-chain (SR-3, SR-4) evidence. | Depth claimed is not depth verified; read `appraisal.provenance_depth_verified`. Transitive dependencies are covered only at `transitive` depth. | §3.1.3 SBOM; §3.1.5 acquisition source | +| `appraisal` (`status`, `verifier`, `method`, `provenance_depth_verified`, `platform_measurement`) | CA-2, CA-7, RA-5 | The verifier's EAR judgment (`affirming`, `warning`, `contraindicated`, `none`) with the named verifier. Supports assessment (CA-2) and continuous-monitoring (CA-7) evidence when the verifier is independent of the operator. | An appraisal by the operator's own verifier is self-assessment. `none` means no appraisal was performed. | §3.1.5 cybersecurity T&E results | +| `transparency` | AU-9, AU-9(3), AU-11 | A SCITT receipt URI for an append-only log entry. When the verifier obtains and checks the inclusion proof against a log or checkpoint it trusts, supports tamper-evident audit retention (AU-9(3)) and retention evidence (AU-11). | In v0.2 the claim is a URI reference, not proof of inclusion. Without a verified inclusion proof it establishes only that the producer named a log. | Table 2-2 AU-9(3) | +| `cnf` and the record signature (§3.2.1, §3.2.2) | AU-10, SC-12, SC-13, SC-17 | The record is signed over its RFC 8785 canonical form by the `cnf` key; schema validity alone confers no trust and unbound records are rejected. Supports non-repudiation (AU-10) and cryptographic-protection (SC-13) evidence. Hardware-held keys, when attestation is verified, support SC-12 key-management evidence. | Non-repudiation is as strong as the key's custody and the verifier's trust in it. Operator-held software keys bind the record to the operator, not to hardware. | DoDI 8500.01 cryptographic protections | +| `iat`, freshness window and clock-skew rules (§3.2.2) | AU-8, AU-8(1) | Issued-at time and the spec's default 24-hour freshness and 5-minute skew tolerance give the assessor a bounded time of issuance. | `iat` is the producer's clock. See [verifying after the freshness window](../verifying-after-the-freshness-window.md). | — | +| `TraceRevocation/1.0` statements (§3.2.3) | IA-5(1), SC-12(1), SC-17 | Log-ordered revocation of record-signing keys; a verifier reports the revocation-check outcome. Supports key-lifecycle evidence. | A missing revocation bundle is reported as unchecked, not as pass. | — | +| `delegation` (`parent_record_hash`, `credential_id`) (§3.1.3) | AC-2(7), AC-6, AU-3(1) | Lets a verifier walk an offline-verifiable delegation chain across agents and see which parent record and credential each hop acted under. Supports privileged-account and least-privilege evidence across hops. | Only hops that issued a record carrying `delegation` are in the chain. | — | + +--- + +## What TRACE does not evidence + +The table marks per-claim limits. Three apply across the whole record and matter most to an authorization package. + +**TRACE does not carry TEVV results.** The Tailoring Guide requires model test and evaluation results, acquisition source, training background, and cybersecurity T&E results in the authorization package (§3.1.3, §3.1.5). A Trust Record proves what model ran, under what policy, in what environment. It does not state whether that model was tested, what the result was, or whether an official accepted the risk. §2.4 of the spec makes output correctness a permanent scope boundary. A v0.2 record can *point* at such results through `references` with `rel` `condition-appraisal` or `authorized-intent`, but the referenced object's format and verification are outside v0.2. An assessor citing a Trust Record for SA-11, CA-2, or CA-6 is citing the pointer, not the result. + +**TRACE does not implement a control.** Every row above is evidence that a condition held for one execution. Whether the control is implemented across the system boundary, for every execution, is a CA-7 continuous-monitoring question that one record cannot answer. A complete chain of records, each verified, with a trusted transparency log, is the shape of that answer; a single record is not. + +**Operator-held keys bind to the operator.** Where `runtime.platform` is `software-only`, or attestation is not verified, the signature establishes that the operator's key signed the record. For AU-10 non-repudiation against the operator, the assessor needs either verified hardware key custody or an independent transparency log the operator cannot rewrite. + +--- + +## Suggested citation form + +For an authorization package or an assessment-results artifact: + +> Evidence: TRACE v0.2 Trust Record, `eat_profile` `tag:agentrust-io.com,2026:trace-v0.2`, record digest `sha256:…` (RFC 8785 canonical form, §3.1.3 preimage), `runtime.platform` ``, `appraisal.status` `` by ``, `transparency` `` (inclusion proof verified: yes/no). Cited for: SI-7, SR-4, AU-9(3), AU-10, CA-7. + +The parenthetical "inclusion proof verified" and the `appraisal.verifier` name are what let a reviewer tell an operator-asserted record from an independently appraised one. + +--- + +## References + +- NIST SP 800-53 Rev 5, *Security and Privacy Controls for Information Systems and Organizations*, September 2020 (with updates). +- DoD CIO, *AI Cybersecurity Risk Management Tailoring Guide*, version 2, 14 July 2025. +- NIST SP 800-37 Rev 2, *Risk Management Framework for Information Systems and Organizations*. +- OMB M-22-18, *Enhancing the Security of the Software Supply Chain through Secure Software Development Practices*. +- TRACE v0.2, `spec/trace-v0.2.md`, §3.1 through §3.3. diff --git a/mkdocs.yml b/mkdocs.yml index 88c57e11..35cb8b22 100644 --- a/mkdocs.yml +++ b/mkdocs.yml @@ -247,6 +247,7 @@ nav: - Acta decision receipts: docs/crosswalks/acta-decision-receipts.md - CHAP review decisions: docs/crosswalks/chap-review-decisions.md - N'KEMBA institutional reconstruction: docs/crosswalks/nkemba-institutional-reconstruction.md + - NIST SP 800-53 and DoD AI Tailoring Guide: docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md - Guides: - Tutorials: - Sign your first trust record: docs/tutorials/signing-your-first-trust-record.md From 2f7d84668053526ce3735955e8fe987415a26b27 Mon Sep 17 00:00:00 2001 From: Srinivasa Consultants <78673153+dinakarjs@users.noreply.github.com> Date: Sun, 18 Oct 2026 10:00:18 +0530 Subject: [PATCH 2/8] docs: supply mechanical cleanup for RMF crosswalk review Replace the five requested em dash cells with n/a and restore the changelog to the PR base so the conflicting changelog hunk disappears. Signed-off-by: Srinivasa Consultants <78673153+dinakarjs@users.noreply.github.com> --- CHANGELOG.md | 1 - docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md | 10 +++++----- 2 files changed, 5 insertions(+), 6 deletions(-) diff --git a/CHANGELOG.md b/CHANGELOG.md index 60ac51a7..fd453a11 100644 --- a/CHANGELOG.md +++ b/CHANGELOG.md @@ -11,7 +11,6 @@ Format: [Semantic Versioning](https://semver.org/). Spec versions follow `MAJOR. ## [Unreleased] -- **NIST SP 800-53 Rev 5 and DoD AI Tailoring Guide cross-walk.** `docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md` maps each v0.2 Trust Record claim to the SP 800-53 controls it is evidence for, states what each claim establishes and what the assessor still needs, and names the three things a record does not evidence for an authorization package (TEVV results, control implementation across the boundary, non-repudiation against an operator-held key). Includes a citation form for assessment artifacts. Contributed by Antagon Inc. Informative only: no schema, wire-format or normative change. - **Accuracy pass on non-normative text.** Examples, schema descriptions, adapter docstrings and unsigned test records use vendor-neutral placeholders (`example-provider`, `example-model`), the Section 6.2 list keeps confidential-computing and standards diff --git a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md index e878d364..1cfc1163 100644 --- a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md +++ b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md @@ -26,16 +26,16 @@ Field names are exact TRACE v0.2 claim names from §3.1 and the §3.2 wire-forma | `policy` (`bundle_hash`, `enforcement_mode`, `version`) | AC-3, AC-6, CM-6, CM-7, SI-10 | `policy.bundle_hash` names the policy set bound to the execution; `policy.enforcement_mode` states whether it was `enforce`d, `advisory`, `silent`, or merely `declared`. Supports configuration-settings evidence (CM-6) and, for `enforce`, access-enforcement evidence (AC-3). | `declared` is not evidence that any rule was checked (schema text). `silent` means denies were allowed. The assessor must read the mode, not just the hash. | §3.1.3 model integrity checks | | `data_class` | AC-16, RA-2, MP-2 | The classification label the producer applied to inputs and outputs of the execution. Supports security-attribute (AC-16) and categorization (RA-2) evidence. | States the label applied, not which data was read, written, or egressed. | §3.1.1 data origin and reliability | | `tool_transcript` (`hash`, `call_count`, `transcript_uri`) | AU-2, AU-3, AU-12, AC-6(9), SI-4 | `tool_transcript.hash` is a commitment to the instrumented MCP/A2A transcript and `tool_transcript.call_count` bounds observed call volume. Supports audit-event (AU-2, AU-12) and privileged-function logging (AC-6(9)) evidence at protocol boundaries. | A commitment, not a verbatim log. Calls inside the binary that never crossed an instrumented boundary are not captured. | §3.1.3 AU-6 auditing | -| `origin` (`kind`, `producer`) | AU-3(1), AU-10 | Names who assembled the record when it was not the executing runtime. Lets an assessor distinguish self-produced evidence from a `third-party-control-plane` or `log-import` assembly. | A non-`self` origin MUST carry `runtime.platform: "software-only"` (§3.1.1); the assessor should treat such records as operator-asserted. | — | +| `origin` (`kind`, `producer`) | AU-3(1), AU-10 | Names who assembled the record when it was not the executing runtime. Lets an assessor distinguish self-produced evidence from a `third-party-control-plane` or `log-import` assembly. | A non-`self` origin MUST carry `runtime.platform: "software-only"` (§3.1.1); the assessor should treat such records as operator-asserted. | n/a | | `references` (`rel`, `id`, `resolver`, `digest`) | CA-2, CA-6, SA-11 (as pointers only) | A `condition-appraisal` reference points at an independent check's finding (a test run); an `authorized-intent` reference points at an authorization decided before execution; an `approval-outcome` reference points at a human approval. These let a record be tied to TEVV results and authorization artifacts the package holds elsewhere. | A reference is a pointer, not evidence (§3.1.2 rule 3). The referenced object must be obtained and verified separately; TRACE v0.2 does not define its format. See "What TRACE does not evidence" below. | §3.1.3, §3.1.5 TEVV results in the package | -| `reproducibility` (`function`, `code_identity`, `input_closure`, `transcript_digest`) with `appraisal.re_execution` | SA-11(1), CA-2, SI-7(6) | Where present and re-executed by a verifier with outcome `reproduced` (§3.1.4), establishes that the named deterministic coordination function over the pinned closure yields the recorded transcript. Supports independent re-performance evidence. | `not-attempted` is neither pass nor fail. Establishes nothing about model calls, which are inputs, or about side effects. | — | +| `reproducibility` (`function`, `code_identity`, `input_closure`, `transcript_digest`) with `appraisal.re_execution` | SA-11(1), CA-2, SI-7(6) | Where present and re-executed by a verifier with outcome `reproduced` (§3.1.4), establishes that the named deterministic coordination function over the pinned closure yields the recorded transcript. Supports independent re-performance evidence. | `not-attempted` is neither pass nor fail. Establishes nothing about model calls, which are inputs, or about side effects. | n/a | | `build_provenance` (`slsa_level`, `builder`, `digest`, `provenance_depth`) | SA-10, SA-11, SA-15, SR-3, SR-4, CM-14 | SLSA provenance for the running code and model: who built it, from what, at what level. `appraisal.provenance_depth_verified` records how deep the verifier checked. Supports configuration-management (SA-10), development-process (SA-15), and supply-chain (SR-3, SR-4) evidence. | Depth claimed is not depth verified; read `appraisal.provenance_depth_verified`. Transitive dependencies are covered only at `transitive` depth. | §3.1.3 SBOM; §3.1.5 acquisition source | | `appraisal` (`status`, `verifier`, `method`, `provenance_depth_verified`, `platform_measurement`) | CA-2, CA-7, RA-5 | The verifier's EAR judgment (`affirming`, `warning`, `contraindicated`, `none`) with the named verifier. Supports assessment (CA-2) and continuous-monitoring (CA-7) evidence when the verifier is independent of the operator. | An appraisal by the operator's own verifier is self-assessment. `none` means no appraisal was performed. | §3.1.5 cybersecurity T&E results | | `transparency` | AU-9, AU-9(3), AU-11 | A SCITT receipt URI for an append-only log entry. When the verifier obtains and checks the inclusion proof against a log or checkpoint it trusts, supports tamper-evident audit retention (AU-9(3)) and retention evidence (AU-11). | In v0.2 the claim is a URI reference, not proof of inclusion. Without a verified inclusion proof it establishes only that the producer named a log. | Table 2-2 AU-9(3) | | `cnf` and the record signature (§3.2.1, §3.2.2) | AU-10, SC-12, SC-13, SC-17 | The record is signed over its RFC 8785 canonical form by the `cnf` key; schema validity alone confers no trust and unbound records are rejected. Supports non-repudiation (AU-10) and cryptographic-protection (SC-13) evidence. Hardware-held keys, when attestation is verified, support SC-12 key-management evidence. | Non-repudiation is as strong as the key's custody and the verifier's trust in it. Operator-held software keys bind the record to the operator, not to hardware. | DoDI 8500.01 cryptographic protections | -| `iat`, freshness window and clock-skew rules (§3.2.2) | AU-8, AU-8(1) | Issued-at time and the spec's default 24-hour freshness and 5-minute skew tolerance give the assessor a bounded time of issuance. | `iat` is the producer's clock. See [verifying after the freshness window](../verifying-after-the-freshness-window.md). | — | -| `TraceRevocation/1.0` statements (§3.2.3) | IA-5(1), SC-12(1), SC-17 | Log-ordered revocation of record-signing keys; a verifier reports the revocation-check outcome. Supports key-lifecycle evidence. | A missing revocation bundle is reported as unchecked, not as pass. | — | -| `delegation` (`parent_record_hash`, `credential_id`) (§3.1.3) | AC-2(7), AC-6, AU-3(1) | Lets a verifier walk an offline-verifiable delegation chain across agents and see which parent record and credential each hop acted under. Supports privileged-account and least-privilege evidence across hops. | Only hops that issued a record carrying `delegation` are in the chain. | — | +| `iat`, freshness window and clock-skew rules (§3.2.2) | AU-8, AU-8(1) | Issued-at time and the spec's default 24-hour freshness and 5-minute skew tolerance give the assessor a bounded time of issuance. | `iat` is the producer's clock. See [verifying after the freshness window](../verifying-after-the-freshness-window.md). | n/a | +| `TraceRevocation/1.0` statements (§3.2.3) | IA-5(1), SC-12(1), SC-17 | Log-ordered revocation of record-signing keys; a verifier reports the revocation-check outcome. Supports key-lifecycle evidence. | A missing revocation bundle is reported as unchecked, not as pass. | n/a | +| `delegation` (`parent_record_hash`, `credential_id`) (§3.1.3) | AC-2(7), AC-6, AU-3(1) | Lets a verifier walk an offline-verifiable delegation chain across agents and see which parent record and credential each hop acted under. Supports privileged-account and least-privilege evidence across hops. | Only hops that issued a record carrying `delegation` are in the chain. | n/a | --- From 09d57bfafb1fd2f814d6162e386ad0329f918518 Mon Sep 17 00:00:00 2001 From: Srinivasa Consultants <78673153+dinakarjs@users.noreply.github.com> Date: Sun, 18 Oct 2026 10:08:07 +0530 Subject: [PATCH 3/8] docs: bound NIST crosswalk enhancements to verified evidence Use base SA-11 for deterministic re-performance rather than the static analysis enhancement. Require separate evidence for cryptographic protection and runtime application self-protection; link official NIST page references. DoD guide references remain externally unverified. Independent review confirmed the three-line mapping and reference scope. This companion preserves the original crosswalk contribution. Signed-off-by: Srinivasa Consultants <78673153+dinakarjs@users.noreply.github.com> --- docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md index 1cfc1163..e6757c6c 100644 --- a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md +++ b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md @@ -22,13 +22,13 @@ Field names are exact TRACE v0.2 claim names from §3.1 and the §3.2 wire-forma |---|---|---|---|---| | `subject` | IA-2, IA-9, CM-8 | A workload identity (SPIFFE SVID or DID URI) names the agent, tool, or model invocation the record is about; with `cnf` it binds that identity to the record-signing key. Supports non-person-entity identification (IA-9) and a component inventory entry (CM-8). | Identity is asserted by the issuing domain. Which permissions that identity holds in external systems is outside the record. | §3.1.5 component inventory | | `model` (`model_id`, `version`, `weights_digest`, `aibom_uri`) | SI-7, SI-7(1), SI-7(15), SR-4, SR-4(3), CM-14 | `model.weights_digest` is a digest of the model artifact that ran, so a later integrity check (SI-7(1)) or an authenticity check against a signed manifest (SI-7(15), CM-14) has a value to compare. `model.aibom_uri` points at a bill of materials for SR-4 provenance. | The record commits to the digest; verifying that the digest matches an approved, signed artifact is the assessor's step. `aibom_uri` is a pointer, not attested content. | Table 2-2 SI-7, SR-4 for AI models; §3.1.3 SBOM (OMB M-22-18) | -| `runtime` (`platform`, `measurement`, `rim_uri`) | SI-7(9), SI-7(17), SC-39, SA-19 | `runtime.measurement` is the measured-boot or workload composite digest; with verified attestation evidence and `appraisal.platform_measurement` (§3.1.5) it establishes which layers ran what. Supports boot integrity (SI-7(9)), process isolation (SC-39), and component authenticity (SA-19). | Only when attestation evidence is verified. A `software-only` record establishes none of these; a TEE name alone establishes nothing. Layers not listed as `established` in `appraisal.platform_measurement` are not established. | §2 "protect the integrity ... of AI systems" | +| `runtime` (`platform`, `measurement`, `rim_uri`) | SI-7(9), SI-7(17) (conditional), SC-39, SA-19 | `runtime.measurement` is the measured-boot or workload composite digest; with verified attestation evidence and `appraisal.platform_measurement` (§3.1.5) it establishes which layers ran what. Supports boot integrity (SI-7(9)), process isolation (SC-39), and component authenticity (SA-19). | Only when attestation evidence is verified. A `software-only` record establishes none of these; a TEE name alone establishes nothing. Layers not listed as `established` in `appraisal.platform_measurement` are not established. SI-7(17) additionally needs verified evidence of runtime application self-protection mechanisms that detect and block exploitation; a TEE measurement alone does not establish that capability. | §2 "protect the integrity ... of AI systems" | | `policy` (`bundle_hash`, `enforcement_mode`, `version`) | AC-3, AC-6, CM-6, CM-7, SI-10 | `policy.bundle_hash` names the policy set bound to the execution; `policy.enforcement_mode` states whether it was `enforce`d, `advisory`, `silent`, or merely `declared`. Supports configuration-settings evidence (CM-6) and, for `enforce`, access-enforcement evidence (AC-3). | `declared` is not evidence that any rule was checked (schema text). `silent` means denies were allowed. The assessor must read the mode, not just the hash. | §3.1.3 model integrity checks | | `data_class` | AC-16, RA-2, MP-2 | The classification label the producer applied to inputs and outputs of the execution. Supports security-attribute (AC-16) and categorization (RA-2) evidence. | States the label applied, not which data was read, written, or egressed. | §3.1.1 data origin and reliability | | `tool_transcript` (`hash`, `call_count`, `transcript_uri`) | AU-2, AU-3, AU-12, AC-6(9), SI-4 | `tool_transcript.hash` is a commitment to the instrumented MCP/A2A transcript and `tool_transcript.call_count` bounds observed call volume. Supports audit-event (AU-2, AU-12) and privileged-function logging (AC-6(9)) evidence at protocol boundaries. | A commitment, not a verbatim log. Calls inside the binary that never crossed an instrumented boundary are not captured. | §3.1.3 AU-6 auditing | | `origin` (`kind`, `producer`) | AU-3(1), AU-10 | Names who assembled the record when it was not the executing runtime. Lets an assessor distinguish self-produced evidence from a `third-party-control-plane` or `log-import` assembly. | A non-`self` origin MUST carry `runtime.platform: "software-only"` (§3.1.1); the assessor should treat such records as operator-asserted. | n/a | | `references` (`rel`, `id`, `resolver`, `digest`) | CA-2, CA-6, SA-11 (as pointers only) | A `condition-appraisal` reference points at an independent check's finding (a test run); an `authorized-intent` reference points at an authorization decided before execution; an `approval-outcome` reference points at a human approval. These let a record be tied to TEVV results and authorization artifacts the package holds elsewhere. | A reference is a pointer, not evidence (§3.1.2 rule 3). The referenced object must be obtained and verified separately; TRACE v0.2 does not define its format. See "What TRACE does not evidence" below. | §3.1.3, §3.1.5 TEVV results in the package | -| `reproducibility` (`function`, `code_identity`, `input_closure`, `transcript_digest`) with `appraisal.re_execution` | SA-11(1), CA-2, SI-7(6) | Where present and re-executed by a verifier with outcome `reproduced` (§3.1.4), establishes that the named deterministic coordination function over the pinned closure yields the recorded transcript. Supports independent re-performance evidence. | `not-attempted` is neither pass nor fail. Establishes nothing about model calls, which are inputs, or about side effects. | n/a | +| `reproducibility` (`function`, `code_identity`, `input_closure`, `transcript_digest`) with `appraisal.re_execution` | SA-11, CA-2; SI-7(6) (conditional) | Where present and re-executed by a verifier with outcome `reproduced` (§3.1.4), establishes that the named deterministic coordination function over the pinned closure yields the recorded transcript. Supports independent re-performance evidence. | `not-attempted` is neither pass nor fail. Establishes nothing about model calls, which are inputs, or about side effects. Re-performance is not static code analysis (SA-11(1)). SI-7(6) additionally needs verified cryptographic protection of the pinned artifacts and closure to detect unauthorized changes; a reproduced transcript alone does not establish that mechanism. | n/a | | `build_provenance` (`slsa_level`, `builder`, `digest`, `provenance_depth`) | SA-10, SA-11, SA-15, SR-3, SR-4, CM-14 | SLSA provenance for the running code and model: who built it, from what, at what level. `appraisal.provenance_depth_verified` records how deep the verifier checked. Supports configuration-management (SA-10), development-process (SA-15), and supply-chain (SR-3, SR-4) evidence. | Depth claimed is not depth verified; read `appraisal.provenance_depth_verified`. Transitive dependencies are covered only at `transitive` depth. | §3.1.3 SBOM; §3.1.5 acquisition source | | `appraisal` (`status`, `verifier`, `method`, `provenance_depth_verified`, `platform_measurement`) | CA-2, CA-7, RA-5 | The verifier's EAR judgment (`affirming`, `warning`, `contraindicated`, `none`) with the named verifier. Supports assessment (CA-2) and continuous-monitoring (CA-7) evidence when the verifier is independent of the operator. | An appraisal by the operator's own verifier is self-assessment. `none` means no appraisal was performed. | §3.1.5 cybersecurity T&E results | | `transparency` | AU-9, AU-9(3), AU-11 | A SCITT receipt URI for an append-only log entry. When the verifier obtains and checks the inclusion proof against a log or checkpoint it trusts, supports tamper-evident audit retention (AU-9(3)) and retention evidence (AU-11). | In v0.2 the claim is a URI reference, not proof of inclusion. Without a verified inclusion proof it establishes only that the producer named a log. | Table 2-2 AU-9(3) | @@ -63,7 +63,7 @@ The parenthetical "inclusion proof verified" and the `appraisal.verifier` name a ## References -- NIST SP 800-53 Rev 5, *Security and Privacy Controls for Information Systems and Organizations*, September 2020 (with updates). +- NIST SP 800-53 Rev 5, [*Security and Privacy Controls for Information Systems and Organizations*](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf), September 2020 (with updates). See SA-11(1), printed p. 277; SI-7(6), printed p. 346; and SI-7(17), printed p. 348, for the enhancement boundaries above. - DoD CIO, *AI Cybersecurity Risk Management Tailoring Guide*, version 2, 14 July 2025. - NIST SP 800-37 Rev 2, *Risk Management Framework for Information Systems and Organizations*. - OMB M-22-18, *Enhancing the Security of the Software Supply Chain through Secure Software Development Practices*. From d3497e33d6f351910def5a8474d2c23a7a6a6fcc Mon Sep 17 00:00:00 2001 From: Srinivasa Consultants <78673153+dinakarjs@users.noreply.github.com> Date: Sun, 18 Oct 2026 19:35:00 +0530 Subject: [PATCH 4/8] docs: correct mirrored DoD crosswalk citations and bound tailoring claims Retain previous mechanical and NIST corrections. Correct table/page references and record source provenance limits without changing normative TRACE behavior. Signed-off-by: Srinivasa Consultants <78673153+dinakarjs@users.noreply.github.com> --- docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md index e6757c6c..d1cd3420 100644 --- a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md +++ b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md @@ -2,13 +2,13 @@ US federal and Department of Defense systems are authorized under the Risk Management Framework (RMF). An assessor preparing an authorization package asks, for each security control, what evidence shows it is in place. This page says, for each claim in a TRACE v0.2 Trust Record, which SP 800-53 Rev 5 controls that claim is evidence for, what the evidence establishes, and what it does not. It is for ISSOs, assessors, and authorizing-official staff. TRACE records what happened; it does not implement a control. -> **Non-normative.** This document is informative only. Nothing here changes TRACE v0.2 schema fields, wire formats, required claims, or conformance requirements. References to "TRACE" mean the TRACE v0.2 Trust Record as defined in [`spec/trace-v0.2.md`](../../spec/trace-v0.2.md). Control identifiers are from NIST SP 800-53 Revision 5. Tailoring Guide references are to the DoD CIO *AI Cybersecurity Risk Management Tailoring Guide*, version 2, 14 July 2025, which names controls for AI models in its Table 2-2 and Section 3. +> **Non-normative.** This document is informative only. Nothing here changes TRACE v0.2 schema fields, wire formats, required claims, or conformance requirements. References to "TRACE" mean the TRACE v0.2 Trust Record as defined in [`spec/trace-v0.2.md`](../../spec/trace-v0.2.md). Control identifiers are from NIST SP 800-53 Revision 5. Tailoring Guide references are to the DoD CIO *AI Cybersecurity Risk Management Tailoring Guide*, version 2, 14 July 2025, with the selected controls and guidance in Tables 1-2, 2-2, 3-2 and Section 3. --- ## Purpose -The Tailoring Guide tells a DoD program which SP 800-53 controls to apply to an AI model: integrity (SI-7 and enhancements), provenance (SR-4, SR-4(3)), audit protection (AU-9(3), AU-12(3)), and the inclusion of model test and evaluation (TEVV) results, acquisition source, and training background in the authorization package (§3.1.3, §3.1.5). It does not say how a signed runtime record satisfies any of them. This page closes that gap for TRACE v0.2 so an assessor can cite a Trust Record against a control without inventing the mapping. +The Tailoring Guide supports control selection and tailoring for AI systems. Relevant entries include integrity (Table 2-2, printed p. 37), provenance (Table 1-2, p. 30), audit protection (Table 2-2, p. 32), and authorization-package evidence (§3.1.3, p. 16; §3.1.5, p. 21). This page suggests bounded TRACE evidence mappings; the assessor determines applicability and adequacy. Its mappings do not establish control implementation or authorization. A Trust Record is evidence *for* a control, not an implementation *of* it. The assessor still judges whether the evidence is adequate for the system's impact level. Where a claim's assurance depends on verified attestation, the row says so: naming a TEE in `runtime.platform` does not itself establish hardware backing, and a `software-only` record (§3.1.1) carries software commitments without hardware evidence. See [trust levels](../trust-levels.md). @@ -20,8 +20,8 @@ Field names are exact TRACE v0.2 claim names from §3.1 and the §3.2 wire-forma | TRACE claim | SP 800-53 Rev 5 controls | Evidence TRACE can provide | Limitations / what the assessor still needs | Tailoring Guide reference | |---|---|---|---|---| -| `subject` | IA-2, IA-9, CM-8 | A workload identity (SPIFFE SVID or DID URI) names the agent, tool, or model invocation the record is about; with `cnf` it binds that identity to the record-signing key. Supports non-person-entity identification (IA-9) and a component inventory entry (CM-8). | Identity is asserted by the issuing domain. Which permissions that identity holds in external systems is outside the record. | §3.1.5 component inventory | -| `model` (`model_id`, `version`, `weights_digest`, `aibom_uri`) | SI-7, SI-7(1), SI-7(15), SR-4, SR-4(3), CM-14 | `model.weights_digest` is a digest of the model artifact that ran, so a later integrity check (SI-7(1)) or an authenticity check against a signed manifest (SI-7(15), CM-14) has a value to compare. `model.aibom_uri` points at a bill of materials for SR-4 provenance. | The record commits to the digest; verifying that the digest matches an approved, signed artifact is the assessor's step. `aibom_uri` is a pointer, not attested content. | Table 2-2 SI-7, SR-4 for AI models; §3.1.3 SBOM (OMB M-22-18) | +| `subject` | IA-2, IA-9, CM-8 | A workload identity (SPIFFE SVID or DID URI) names the agent, tool, or model invocation the record is about; with `cnf` it binds that identity to the record-signing key. Supports non-person-entity identification (IA-9) and a component inventory entry (CM-8). | Identity is asserted by the issuing domain. Which permissions that identity holds in external systems is outside the record. | Table 3-2 CM-8, printed p. 40 | +| `model` (`model_id`, `version`, `weights_digest`, `aibom_uri`) | SI-7, SI-7(1), SI-7(15), SR-4, SR-4(3), CM-14 | `model.weights_digest` is a digest of the model artifact that ran, so a later integrity check (SI-7(1)) or an authenticity check against a signed manifest (SI-7(15), CM-14) has a value to compare. `model.aibom_uri` points at a bill of materials for SR-4 provenance. | The record commits to the digest; verifying that the digest matches an approved, signed artifact is the assessor's step. `aibom_uri` is a pointer, not attested content. | Table 2-2 SI-7, p. 37; Table 1-2 SR-4/SR-4(3), p. 30; §3.1.3 SBOM | | `runtime` (`platform`, `measurement`, `rim_uri`) | SI-7(9), SI-7(17) (conditional), SC-39, SA-19 | `runtime.measurement` is the measured-boot or workload composite digest; with verified attestation evidence and `appraisal.platform_measurement` (§3.1.5) it establishes which layers ran what. Supports boot integrity (SI-7(9)), process isolation (SC-39), and component authenticity (SA-19). | Only when attestation evidence is verified. A `software-only` record establishes none of these; a TEE name alone establishes nothing. Layers not listed as `established` in `appraisal.platform_measurement` are not established. SI-7(17) additionally needs verified evidence of runtime application self-protection mechanisms that detect and block exploitation; a TEE measurement alone does not establish that capability. | §2 "protect the integrity ... of AI systems" | | `policy` (`bundle_hash`, `enforcement_mode`, `version`) | AC-3, AC-6, CM-6, CM-7, SI-10 | `policy.bundle_hash` names the policy set bound to the execution; `policy.enforcement_mode` states whether it was `enforce`d, `advisory`, `silent`, or merely `declared`. Supports configuration-settings evidence (CM-6) and, for `enforce`, access-enforcement evidence (AC-3). | `declared` is not evidence that any rule was checked (schema text). `silent` means denies were allowed. The assessor must read the mode, not just the hash. | §3.1.3 model integrity checks | | `data_class` | AC-16, RA-2, MP-2 | The classification label the producer applied to inputs and outputs of the execution. Supports security-attribute (AC-16) and categorization (RA-2) evidence. | States the label applied, not which data was read, written, or egressed. | §3.1.1 data origin and reliability | @@ -43,7 +43,7 @@ Field names are exact TRACE v0.2 claim names from §3.1 and the §3.2 wire-forma The table marks per-claim limits. Three apply across the whole record and matter most to an authorization package. -**TRACE does not carry TEVV results.** The Tailoring Guide requires model test and evaluation results, acquisition source, training background, and cybersecurity T&E results in the authorization package (§3.1.3, §3.1.5). A Trust Record proves what model ran, under what policy, in what environment. It does not state whether that model was tested, what the result was, or whether an official accepted the risk. §2.4 of the spec makes output correctness a permanent scope boundary. A v0.2 record can *point* at such results through `references` with `rel` `condition-appraisal` or `authorized-intent`, but the referenced object's format and verification are outside v0.2. An assessor citing a Trust Record for SA-11, CA-2, or CA-6 is citing the pointer, not the result. +**TRACE does not carry TEVV results.** The Tailoring Guide recommends including model test and evaluation results, acquisition source, training background, and cybersecurity T&E results in the authorization package (§3.1.3, §3.1.5). A Trust Record proves what model ran, under what policy, in what environment. It does not state whether that model was tested, what the result was, or whether an official accepted the risk. §2.4 of the spec makes output correctness a permanent scope boundary. A v0.2 record can *point* at such results through `references` with `rel` `condition-appraisal` or `authorized-intent`, but the referenced object's format and verification are outside v0.2. An assessor citing a Trust Record for SA-11, CA-2, or CA-6 is citing the pointer, not the result. **TRACE does not implement a control.** Every row above is evidence that a condition held for one execution. Whether the control is implemented across the system boundary, for every execution, is a CA-7 continuous-monitoring question that one record cannot answer. A complete chain of records, each verified, with a trusted transparency log, is the shape of that answer; a single record is not. @@ -64,7 +64,7 @@ The parenthetical "inclusion proof verified" and the `appraisal.verifier` name a ## References - NIST SP 800-53 Rev 5, [*Security and Privacy Controls for Information Systems and Organizations*](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf), September 2020 (with updates). See SA-11(1), printed p. 277; SI-7(6), printed p. 346; and SI-7(17), printed p. 348, for the enhancement boundaries above. -- DoD CIO, *AI Cybersecurity Risk Management Tailoring Guide*, version 2, 14 July 2025. +- DoD CIO, [*AI Cybersecurity Risk Management Tailoring Guide*](https://dodcio.defense.gov/Portals/0/Documents/Library/AI-CybersecurityRMTailoringGuide.pdf), version 2, 14 July 2025. Citations were checked against the [DMI-hosted copy](https://www.dmi-ida.org/download-pdf/pdf/AI-CybersecurityRMTailoringGuide.pdf). The official host returned HTTP 403 during review on 18 October 2026; byte identity with that host was not verified. Page numbers above are printed page numbers. - NIST SP 800-37 Rev 2, *Risk Management Framework for Information Systems and Organizations*. - OMB M-22-18, *Enhancing the Security of the Software Supply Chain through Secure Software Development Practices*. - TRACE v0.2, `spec/trace-v0.2.md`, §3.1 through §3.3. From dc0e55582e71c562ea6a9f9c138fbd515d738487 Mon Sep 17 00:00:00 2001 From: Srinivasa Consultants <78673153+dinakarjs@users.noreply.github.com> Date: Tue, 20 Oct 2026 11:16:42 +0530 Subject: [PATCH 5/8] docs: spell out absent crosswalk references Signed-off-by: Srinivasa Consultants <78673153+dinakarjs@users.noreply.github.com> --- docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md index d1cd3420..3c36bb72 100644 --- a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md +++ b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md @@ -26,16 +26,16 @@ Field names are exact TRACE v0.2 claim names from §3.1 and the §3.2 wire-forma | `policy` (`bundle_hash`, `enforcement_mode`, `version`) | AC-3, AC-6, CM-6, CM-7, SI-10 | `policy.bundle_hash` names the policy set bound to the execution; `policy.enforcement_mode` states whether it was `enforce`d, `advisory`, `silent`, or merely `declared`. Supports configuration-settings evidence (CM-6) and, for `enforce`, access-enforcement evidence (AC-3). | `declared` is not evidence that any rule was checked (schema text). `silent` means denies were allowed. The assessor must read the mode, not just the hash. | §3.1.3 model integrity checks | | `data_class` | AC-16, RA-2, MP-2 | The classification label the producer applied to inputs and outputs of the execution. Supports security-attribute (AC-16) and categorization (RA-2) evidence. | States the label applied, not which data was read, written, or egressed. | §3.1.1 data origin and reliability | | `tool_transcript` (`hash`, `call_count`, `transcript_uri`) | AU-2, AU-3, AU-12, AC-6(9), SI-4 | `tool_transcript.hash` is a commitment to the instrumented MCP/A2A transcript and `tool_transcript.call_count` bounds observed call volume. Supports audit-event (AU-2, AU-12) and privileged-function logging (AC-6(9)) evidence at protocol boundaries. | A commitment, not a verbatim log. Calls inside the binary that never crossed an instrumented boundary are not captured. | §3.1.3 AU-6 auditing | -| `origin` (`kind`, `producer`) | AU-3(1), AU-10 | Names who assembled the record when it was not the executing runtime. Lets an assessor distinguish self-produced evidence from a `third-party-control-plane` or `log-import` assembly. | A non-`self` origin MUST carry `runtime.platform: "software-only"` (§3.1.1); the assessor should treat such records as operator-asserted. | n/a | +| `origin` (`kind`, `producer`) | AU-3(1), AU-10 | Names who assembled the record when it was not the executing runtime. Lets an assessor distinguish self-produced evidence from a `third-party-control-plane` or `log-import` assembly. | A non-`self` origin MUST carry `runtime.platform: "software-only"` (§3.1.1); the assessor should treat such records as operator-asserted. | No specific reference cited | | `references` (`rel`, `id`, `resolver`, `digest`) | CA-2, CA-6, SA-11 (as pointers only) | A `condition-appraisal` reference points at an independent check's finding (a test run); an `authorized-intent` reference points at an authorization decided before execution; an `approval-outcome` reference points at a human approval. These let a record be tied to TEVV results and authorization artifacts the package holds elsewhere. | A reference is a pointer, not evidence (§3.1.2 rule 3). The referenced object must be obtained and verified separately; TRACE v0.2 does not define its format. See "What TRACE does not evidence" below. | §3.1.3, §3.1.5 TEVV results in the package | -| `reproducibility` (`function`, `code_identity`, `input_closure`, `transcript_digest`) with `appraisal.re_execution` | SA-11, CA-2; SI-7(6) (conditional) | Where present and re-executed by a verifier with outcome `reproduced` (§3.1.4), establishes that the named deterministic coordination function over the pinned closure yields the recorded transcript. Supports independent re-performance evidence. | `not-attempted` is neither pass nor fail. Establishes nothing about model calls, which are inputs, or about side effects. Re-performance is not static code analysis (SA-11(1)). SI-7(6) additionally needs verified cryptographic protection of the pinned artifacts and closure to detect unauthorized changes; a reproduced transcript alone does not establish that mechanism. | n/a | +| `reproducibility` (`function`, `code_identity`, `input_closure`, `transcript_digest`) with `appraisal.re_execution` | SA-11, CA-2; SI-7(6) (conditional) | Where present and re-executed by a verifier with outcome `reproduced` (§3.1.4), establishes that the named deterministic coordination function over the pinned closure yields the recorded transcript. Supports independent re-performance evidence. | `not-attempted` is neither pass nor fail. Establishes nothing about model calls, which are inputs, or about side effects. Re-performance is not static code analysis (SA-11(1)). SI-7(6) additionally needs verified cryptographic protection of the pinned artifacts and closure to detect unauthorized changes; a reproduced transcript alone does not establish that mechanism. | No specific reference cited | | `build_provenance` (`slsa_level`, `builder`, `digest`, `provenance_depth`) | SA-10, SA-11, SA-15, SR-3, SR-4, CM-14 | SLSA provenance for the running code and model: who built it, from what, at what level. `appraisal.provenance_depth_verified` records how deep the verifier checked. Supports configuration-management (SA-10), development-process (SA-15), and supply-chain (SR-3, SR-4) evidence. | Depth claimed is not depth verified; read `appraisal.provenance_depth_verified`. Transitive dependencies are covered only at `transitive` depth. | §3.1.3 SBOM; §3.1.5 acquisition source | | `appraisal` (`status`, `verifier`, `method`, `provenance_depth_verified`, `platform_measurement`) | CA-2, CA-7, RA-5 | The verifier's EAR judgment (`affirming`, `warning`, `contraindicated`, `none`) with the named verifier. Supports assessment (CA-2) and continuous-monitoring (CA-7) evidence when the verifier is independent of the operator. | An appraisal by the operator's own verifier is self-assessment. `none` means no appraisal was performed. | §3.1.5 cybersecurity T&E results | | `transparency` | AU-9, AU-9(3), AU-11 | A SCITT receipt URI for an append-only log entry. When the verifier obtains and checks the inclusion proof against a log or checkpoint it trusts, supports tamper-evident audit retention (AU-9(3)) and retention evidence (AU-11). | In v0.2 the claim is a URI reference, not proof of inclusion. Without a verified inclusion proof it establishes only that the producer named a log. | Table 2-2 AU-9(3) | | `cnf` and the record signature (§3.2.1, §3.2.2) | AU-10, SC-12, SC-13, SC-17 | The record is signed over its RFC 8785 canonical form by the `cnf` key; schema validity alone confers no trust and unbound records are rejected. Supports non-repudiation (AU-10) and cryptographic-protection (SC-13) evidence. Hardware-held keys, when attestation is verified, support SC-12 key-management evidence. | Non-repudiation is as strong as the key's custody and the verifier's trust in it. Operator-held software keys bind the record to the operator, not to hardware. | DoDI 8500.01 cryptographic protections | -| `iat`, freshness window and clock-skew rules (§3.2.2) | AU-8, AU-8(1) | Issued-at time and the spec's default 24-hour freshness and 5-minute skew tolerance give the assessor a bounded time of issuance. | `iat` is the producer's clock. See [verifying after the freshness window](../verifying-after-the-freshness-window.md). | n/a | -| `TraceRevocation/1.0` statements (§3.2.3) | IA-5(1), SC-12(1), SC-17 | Log-ordered revocation of record-signing keys; a verifier reports the revocation-check outcome. Supports key-lifecycle evidence. | A missing revocation bundle is reported as unchecked, not as pass. | n/a | -| `delegation` (`parent_record_hash`, `credential_id`) (§3.1.3) | AC-2(7), AC-6, AU-3(1) | Lets a verifier walk an offline-verifiable delegation chain across agents and see which parent record and credential each hop acted under. Supports privileged-account and least-privilege evidence across hops. | Only hops that issued a record carrying `delegation` are in the chain. | n/a | +| `iat`, freshness window and clock-skew rules (§3.2.2) | AU-8, AU-8(1) | Issued-at time and the spec's default 24-hour freshness and 5-minute skew tolerance give the assessor a bounded time of issuance. | `iat` is the producer's clock. See [verifying after the freshness window](../verifying-after-the-freshness-window.md). | No specific reference cited | +| `TraceRevocation/1.0` statements (§3.2.3) | IA-5(1), SC-12(1), SC-17 | Log-ordered revocation of record-signing keys; a verifier reports the revocation-check outcome. Supports key-lifecycle evidence. | A missing revocation bundle is reported as unchecked, not as pass. | No specific reference cited | +| `delegation` (`parent_record_hash`, `credential_id`) (§3.1.3) | AC-2(7), AC-6, AU-3(1) | Lets a verifier walk an offline-verifiable delegation chain across agents and see which parent record and credential each hop acted under. Supports privileged-account and least-privilege evidence across hops. | Only hops that issued a record carrying `delegation` are in the chain. | No specific reference cited | --- From ae2bef0aaf0346149de0e84b83319a4070ac66e4 Mon Sep 17 00:00:00 2001 From: "W. Alexander Ousley" Date: Tue, 20 Oct 2026 16:03:18 +0800 Subject: [PATCH 6/8] docs(crosswalk): re-check DoD citations against the official host Section 3.1.5 begins and states the acquisition-source and T&E evidence on printed p. 20 of the official copy, not p. 21. Record that the table, section and page references were re-checked against the DoD CIO host; byte identity of the two copies is still not claimed. Signed-off-by: W. Alexander Ousley --- docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md index 3c36bb72..c88a7120 100644 --- a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md +++ b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md @@ -8,7 +8,7 @@ US federal and Department of Defense systems are authorized under the Risk Manag ## Purpose -The Tailoring Guide supports control selection and tailoring for AI systems. Relevant entries include integrity (Table 2-2, printed p. 37), provenance (Table 1-2, p. 30), audit protection (Table 2-2, p. 32), and authorization-package evidence (§3.1.3, p. 16; §3.1.5, p. 21). This page suggests bounded TRACE evidence mappings; the assessor determines applicability and adequacy. Its mappings do not establish control implementation or authorization. +The Tailoring Guide supports control selection and tailoring for AI systems. Relevant entries include integrity (Table 2-2, printed p. 37), provenance (Table 1-2, p. 30), audit protection (Table 2-2, p. 32), and authorization-package evidence (§3.1.3, p. 16; §3.1.5, p. 20). This page suggests bounded TRACE evidence mappings; the assessor determines applicability and adequacy. Its mappings do not establish control implementation or authorization. A Trust Record is evidence *for* a control, not an implementation *of* it. The assessor still judges whether the evidence is adequate for the system's impact level. Where a claim's assurance depends on verified attestation, the row says so: naming a TEE in `runtime.platform` does not itself establish hardware backing, and a `software-only` record (§3.1.1) carries software commitments without hardware evidence. See [trust levels](../trust-levels.md). @@ -64,7 +64,7 @@ The parenthetical "inclusion proof verified" and the `appraisal.verifier` name a ## References - NIST SP 800-53 Rev 5, [*Security and Privacy Controls for Information Systems and Organizations*](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf), September 2020 (with updates). See SA-11(1), printed p. 277; SI-7(6), printed p. 346; and SI-7(17), printed p. 348, for the enhancement boundaries above. -- DoD CIO, [*AI Cybersecurity Risk Management Tailoring Guide*](https://dodcio.defense.gov/Portals/0/Documents/Library/AI-CybersecurityRMTailoringGuide.pdf), version 2, 14 July 2025. Citations were checked against the [DMI-hosted copy](https://www.dmi-ida.org/download-pdf/pdf/AI-CybersecurityRMTailoringGuide.pdf). The official host returned HTTP 403 during review on 18 October 2026; byte identity with that host was not verified. Page numbers above are printed page numbers. +- DoD CIO, [*AI Cybersecurity Risk Management Tailoring Guide*](https://dodcio.defense.gov/Portals/0/Documents/Library/AI-CybersecurityRMTailoringGuide.pdf), version 2, 14 July 2025. Citations were checked against the [DMI-hosted copy](https://www.dmi-ida.org/download-pdf/pdf/AI-CybersecurityRMTailoringGuide.pdf) on 18 October 2026, and the table, section and page references were re-checked against the copy on the official DoD CIO host on 20 October 2026. Byte identity of the two copies was not verified. Page numbers above are printed page numbers. - NIST SP 800-37 Rev 2, *Risk Management Framework for Information Systems and Organizations*. - OMB M-22-18, *Enhancing the Security of the Software Supply Chain through Secure Software Development Practices*. - TRACE v0.2, `spec/trace-v0.2.md`, §3.1 through §3.3. From c1b7c150793961cb3dfe790807df355fc060e143 Mon Sep 17 00:00:00 2001 From: Srinivasa Consultants <78673153+dinakarjs@users.noreply.github.com> Date: Thu, 22 Oct 2026 19:21:05 +0530 Subject: [PATCH 7/8] docs(crosswalk): correct control mappings and evidence limits Address the three mapping corrections and five nonblocking evidence-limit observations from the current review of upstream #486. Signed-off-by: Srinivasa Consultants <78673153+dinakarjs@users.noreply.github.com> --- .../nist-sp800-53-dod-ai-tailoring.md | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) diff --git a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md index c88a7120..c2aec6ee 100644 --- a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md +++ b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md @@ -22,19 +22,19 @@ Field names are exact TRACE v0.2 claim names from §3.1 and the §3.2 wire-forma |---|---|---|---|---| | `subject` | IA-2, IA-9, CM-8 | A workload identity (SPIFFE SVID or DID URI) names the agent, tool, or model invocation the record is about; with `cnf` it binds that identity to the record-signing key. Supports non-person-entity identification (IA-9) and a component inventory entry (CM-8). | Identity is asserted by the issuing domain. Which permissions that identity holds in external systems is outside the record. | Table 3-2 CM-8, printed p. 40 | | `model` (`model_id`, `version`, `weights_digest`, `aibom_uri`) | SI-7, SI-7(1), SI-7(15), SR-4, SR-4(3), CM-14 | `model.weights_digest` is a digest of the model artifact that ran, so a later integrity check (SI-7(1)) or an authenticity check against a signed manifest (SI-7(15), CM-14) has a value to compare. `model.aibom_uri` points at a bill of materials for SR-4 provenance. | The record commits to the digest; verifying that the digest matches an approved, signed artifact is the assessor's step. `aibom_uri` is a pointer, not attested content. | Table 2-2 SI-7, p. 37; Table 1-2 SR-4/SR-4(3), p. 30; §3.1.3 SBOM | -| `runtime` (`platform`, `measurement`, `rim_uri`) | SI-7(9), SI-7(17) (conditional), SC-39, SA-19 | `runtime.measurement` is the measured-boot or workload composite digest; with verified attestation evidence and `appraisal.platform_measurement` (§3.1.5) it establishes which layers ran what. Supports boot integrity (SI-7(9)), process isolation (SC-39), and component authenticity (SA-19). | Only when attestation evidence is verified. A `software-only` record establishes none of these; a TEE name alone establishes nothing. Layers not listed as `established` in `appraisal.platform_measurement` are not established. SI-7(17) additionally needs verified evidence of runtime application self-protection mechanisms that detect and block exploitation; a TEE measurement alone does not establish that capability. | §2 "protect the integrity ... of AI systems" | -| `policy` (`bundle_hash`, `enforcement_mode`, `version`) | AC-3, AC-6, CM-6, CM-7, SI-10 | `policy.bundle_hash` names the policy set bound to the execution; `policy.enforcement_mode` states whether it was `enforce`d, `advisory`, `silent`, or merely `declared`. Supports configuration-settings evidence (CM-6) and, for `enforce`, access-enforcement evidence (AC-3). | `declared` is not evidence that any rule was checked (schema text). `silent` means denies were allowed. The assessor must read the mode, not just the hash. | §3.1.3 model integrity checks | -| `data_class` | AC-16, RA-2, MP-2 | The classification label the producer applied to inputs and outputs of the execution. Supports security-attribute (AC-16) and categorization (RA-2) evidence. | States the label applied, not which data was read, written, or egressed. | §3.1.1 data origin and reliability | +| `runtime` (`platform`, `measurement`, `rim_uri`) | SI-7(9), SI-7(17) (conditional), SC-39, SR-11 | `runtime.measurement` is the measured-boot or workload composite digest; with verified attestation evidence and `appraisal.platform_measurement` (§3.1.5) it establishes which layers ran what. Supports boot integrity (SI-7(9)), process isolation (SC-39), and component authenticity (SR-11). | Only when attestation evidence is verified. A `software-only` record establishes none of these; a TEE name alone establishes nothing. Layers not listed as `established` in `appraisal.platform_measurement` are not established. SI-7(17) additionally needs verified evidence of runtime application self-protection mechanisms that detect and block exploitation; a TEE measurement alone does not establish that capability. | §2 "protect the integrity ... of AI systems" | +| `policy` (`bundle_hash`, `enforcement_mode`, `version`) | AC-3, AC-6, CM-6, CM-7, SI-10 | `policy.bundle_hash` names the policy set bound to the execution; `policy.enforcement_mode` states whether it was `enforce`d, `advisory`, `silent`, or merely `declared`. Supports configuration-settings evidence (CM-6) and, for `enforce`, access-enforcement evidence (AC-3). | `declared` is not evidence that any rule was checked (schema text). `silent` means denies were allowed. The assessor must read the mode, not just the hash. | Table 3-2 AC-3/CM-6, printed pp. 39 to 40 | +| `data_class` | AC-16, RA-2 | The classification label the producer applied to inputs and outputs of the execution. Supports security-attribute (AC-16) and categorization (RA-2) evidence. | States the label applied, not which data was read, written, or egressed. | §3.1.1 data origin and reliability | | `tool_transcript` (`hash`, `call_count`, `transcript_uri`) | AU-2, AU-3, AU-12, AC-6(9), SI-4 | `tool_transcript.hash` is a commitment to the instrumented MCP/A2A transcript and `tool_transcript.call_count` bounds observed call volume. Supports audit-event (AU-2, AU-12) and privileged-function logging (AC-6(9)) evidence at protocol boundaries. | A commitment, not a verbatim log. Calls inside the binary that never crossed an instrumented boundary are not captured. | §3.1.3 AU-6 auditing | | `origin` (`kind`, `producer`) | AU-3(1), AU-10 | Names who assembled the record when it was not the executing runtime. Lets an assessor distinguish self-produced evidence from a `third-party-control-plane` or `log-import` assembly. | A non-`self` origin MUST carry `runtime.platform: "software-only"` (§3.1.1); the assessor should treat such records as operator-asserted. | No specific reference cited | | `references` (`rel`, `id`, `resolver`, `digest`) | CA-2, CA-6, SA-11 (as pointers only) | A `condition-appraisal` reference points at an independent check's finding (a test run); an `authorized-intent` reference points at an authorization decided before execution; an `approval-outcome` reference points at a human approval. These let a record be tied to TEVV results and authorization artifacts the package holds elsewhere. | A reference is a pointer, not evidence (§3.1.2 rule 3). The referenced object must be obtained and verified separately; TRACE v0.2 does not define its format. See "What TRACE does not evidence" below. | §3.1.3, §3.1.5 TEVV results in the package | | `reproducibility` (`function`, `code_identity`, `input_closure`, `transcript_digest`) with `appraisal.re_execution` | SA-11, CA-2; SI-7(6) (conditional) | Where present and re-executed by a verifier with outcome `reproduced` (§3.1.4), establishes that the named deterministic coordination function over the pinned closure yields the recorded transcript. Supports independent re-performance evidence. | `not-attempted` is neither pass nor fail. Establishes nothing about model calls, which are inputs, or about side effects. Re-performance is not static code analysis (SA-11(1)). SI-7(6) additionally needs verified cryptographic protection of the pinned artifacts and closure to detect unauthorized changes; a reproduced transcript alone does not establish that mechanism. | No specific reference cited | | `build_provenance` (`slsa_level`, `builder`, `digest`, `provenance_depth`) | SA-10, SA-11, SA-15, SR-3, SR-4, CM-14 | SLSA provenance for the running code and model: who built it, from what, at what level. `appraisal.provenance_depth_verified` records how deep the verifier checked. Supports configuration-management (SA-10), development-process (SA-15), and supply-chain (SR-3, SR-4) evidence. | Depth claimed is not depth verified; read `appraisal.provenance_depth_verified`. Transitive dependencies are covered only at `transitive` depth. | §3.1.3 SBOM; §3.1.5 acquisition source | | `appraisal` (`status`, `verifier`, `method`, `provenance_depth_verified`, `platform_measurement`) | CA-2, CA-7, RA-5 | The verifier's EAR judgment (`affirming`, `warning`, `contraindicated`, `none`) with the named verifier. Supports assessment (CA-2) and continuous-monitoring (CA-7) evidence when the verifier is independent of the operator. | An appraisal by the operator's own verifier is self-assessment. `none` means no appraisal was performed. | §3.1.5 cybersecurity T&E results | -| `transparency` | AU-9, AU-9(3), AU-11 | A SCITT receipt URI for an append-only log entry. When the verifier obtains and checks the inclusion proof against a log or checkpoint it trusts, supports tamper-evident audit retention (AU-9(3)) and retention evidence (AU-11). | In v0.2 the claim is a URI reference, not proof of inclusion. Without a verified inclusion proof it establishes only that the producer named a log. | Table 2-2 AU-9(3) | -| `cnf` and the record signature (§3.2.1, §3.2.2) | AU-10, SC-12, SC-13, SC-17 | The record is signed over its RFC 8785 canonical form by the `cnf` key; schema validity alone confers no trust and unbound records are rejected. Supports non-repudiation (AU-10) and cryptographic-protection (SC-13) evidence. Hardware-held keys, when attestation is verified, support SC-12 key-management evidence. | Non-repudiation is as strong as the key's custody and the verifier's trust in it. Operator-held software keys bind the record to the operator, not to hardware. | DoDI 8500.01 cryptographic protections | -| `iat`, freshness window and clock-skew rules (§3.2.2) | AU-8, AU-8(1) | Issued-at time and the spec's default 24-hour freshness and 5-minute skew tolerance give the assessor a bounded time of issuance. | `iat` is the producer's clock. See [verifying after the freshness window](../verifying-after-the-freshness-window.md). | No specific reference cited | -| `TraceRevocation/1.0` statements (§3.2.3) | IA-5(1), SC-12(1), SC-17 | Log-ordered revocation of record-signing keys; a verifier reports the revocation-check outcome. Supports key-lifecycle evidence. | A missing revocation bundle is reported as unchecked, not as pass. | No specific reference cited | +| `transparency` | AU-9, AU-9(3) | A SCITT receipt URI for an append-only log entry. When the verifier obtains and checks the inclusion proof against a log or checkpoint it trusts, supports tamper-evident audit protection (AU-9(3)). | In v0.2 the claim is a URI reference, not proof of inclusion. Without a verified inclusion proof it establishes only that the producer named a log. Inclusion at a checked checkpoint does not establish an audit retention period. | Table 2-2 AU-9(3) | +| `cnf` and the record signature (§3.2.1, §3.2.2) | AU-10, SC-12, SC-13, SC-17 | The record is signed over its RFC 8785 canonical form by the `cnf` key; schema validity alone confers no trust and unbound records are rejected. Supports non-repudiation (AU-10) and cryptographic-protection (SC-13) evidence. Hardware-held keys, when attestation is verified, support SC-12 key-management evidence. | Non-repudiation is as strong as the key's custody and the verifier's trust in it. Operator-held software keys bind the record to the operator, not to hardware. | Table 3-1, mitigation 3.1, printed p. 39: cryptographic protections consistent with DoDI 8500.01 | +| `iat`, freshness window and clock-skew rules (§3.2.2) | AU-8 | Issued-at time and the spec's default 24-hour freshness and 5-minute skew tolerance give the assessor a bounded time of issuance. | `iat` is the producer's clock; the record carries no evidence that it was synchronized with an authoritative time source (SC-45(1)). See [verifying after the freshness window](../verifying-after-the-freshness-window.md). | No specific reference cited | +| `TraceRevocation/1.0` statements (§3.2.3) | IA-5, IA-5(2) (conditional), SC-12, SC-17 (conditional) | Log-ordered revocation of record-signing keys; a verifier reports the revocation-check outcome. Supports key-lifecycle evidence. | A missing revocation bundle is reported as unchecked, not as pass. `IA-5(2)` and `SC-17` apply where the signing key is presented with an `x5c` chain (§3.2.1); a bare `cnf.jwk` does not put the record in that case. | No specific reference cited | | `delegation` (`parent_record_hash`, `credential_id`) (§3.1.3) | AC-2(7), AC-6, AU-3(1) | Lets a verifier walk an offline-verifiable delegation chain across agents and see which parent record and credential each hop acted under. Supports privileged-account and least-privilege evidence across hops. | Only hops that issued a record carrying `delegation` are in the chain. | No specific reference cited | --- @@ -57,13 +57,13 @@ For an authorization package or an assessment-results artifact: > Evidence: TRACE v0.2 Trust Record, `eat_profile` `tag:agentrust-io.com,2026:trace-v0.2`, record digest `sha256:…` (RFC 8785 canonical form, §3.1.3 preimage), `runtime.platform` ``, `appraisal.status` `` by ``, `transparency` `` (inclusion proof verified: yes/no). Cited for: SI-7, SR-4, AU-9(3), AU-10, CA-7. -The parenthetical "inclusion proof verified" and the `appraisal.verifier` name are what let a reviewer tell an operator-asserted record from an independently appraised one. +The parenthetical "inclusion proof verified" records a separately checked property. The `appraisal.verifier` name is authenticated as that verifier only when the verifier signs the record; on a producer-signed record the name remains the producer's claim. --- ## References -- NIST SP 800-53 Rev 5, [*Security and Privacy Controls for Information Systems and Organizations*](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf), September 2020 (with updates). See SA-11(1), printed p. 277; SI-7(6), printed p. 346; and SI-7(17), printed p. 348, for the enhancement boundaries above. +- NIST SP 800-53 Rev 5, [*Security and Privacy Controls for Information Systems and Organizations*](https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-53r5.pdf), September 2020 (with updates). See IA-5(2), printed p. 139; SA-11(1), printed p. 277; SI-7(6), printed p. 346; and SI-7(17), printed p. 348, for the enhancement boundaries above. - DoD CIO, [*AI Cybersecurity Risk Management Tailoring Guide*](https://dodcio.defense.gov/Portals/0/Documents/Library/AI-CybersecurityRMTailoringGuide.pdf), version 2, 14 July 2025. Citations were checked against the [DMI-hosted copy](https://www.dmi-ida.org/download-pdf/pdf/AI-CybersecurityRMTailoringGuide.pdf) on 18 October 2026, and the table, section and page references were re-checked against the copy on the official DoD CIO host on 20 October 2026. Byte identity of the two copies was not verified. Page numbers above are printed page numbers. - NIST SP 800-37 Rev 2, *Risk Management Framework for Information Systems and Organizations*. - OMB M-22-18, *Enhancing the Security of the Software Supply Chain through Secure Software Development Practices*. From 8f7434fc4852ba81e344b00065669d7dc7aa4d2f Mon Sep 17 00:00:00 2001 From: Srinivasa Consultants <78673153+dinakarjs@users.noreply.github.com> Date: Thu, 22 Oct 2026 19:24:58 +0530 Subject: [PATCH 8/8] docs(crosswalk): scope the conditional mapping to the PKI cache clause Signed-off-by: Srinivasa Consultants <78673153+dinakarjs@users.noreply.github.com> --- docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md index c2aec6ee..e808a295 100644 --- a/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md +++ b/docs/crosswalks/nist-sp800-53-dod-ai-tailoring.md @@ -34,7 +34,7 @@ Field names are exact TRACE v0.2 claim names from §3.1 and the §3.2 wire-forma | `transparency` | AU-9, AU-9(3) | A SCITT receipt URI for an append-only log entry. When the verifier obtains and checks the inclusion proof against a log or checkpoint it trusts, supports tamper-evident audit protection (AU-9(3)). | In v0.2 the claim is a URI reference, not proof of inclusion. Without a verified inclusion proof it establishes only that the producer named a log. Inclusion at a checked checkpoint does not establish an audit retention period. | Table 2-2 AU-9(3) | | `cnf` and the record signature (§3.2.1, §3.2.2) | AU-10, SC-12, SC-13, SC-17 | The record is signed over its RFC 8785 canonical form by the `cnf` key; schema validity alone confers no trust and unbound records are rejected. Supports non-repudiation (AU-10) and cryptographic-protection (SC-13) evidence. Hardware-held keys, when attestation is verified, support SC-12 key-management evidence. | Non-repudiation is as strong as the key's custody and the verifier's trust in it. Operator-held software keys bind the record to the operator, not to hardware. | Table 3-1, mitigation 3.1, printed p. 39: cryptographic protections consistent with DoDI 8500.01 | | `iat`, freshness window and clock-skew rules (§3.2.2) | AU-8 | Issued-at time and the spec's default 24-hour freshness and 5-minute skew tolerance give the assessor a bounded time of issuance. | `iat` is the producer's clock; the record carries no evidence that it was synchronized with an authoritative time source (SC-45(1)). See [verifying after the freshness window](../verifying-after-the-freshness-window.md). | No specific reference cited | -| `TraceRevocation/1.0` statements (§3.2.3) | IA-5, IA-5(2) (conditional), SC-12, SC-17 (conditional) | Log-ordered revocation of record-signing keys; a verifier reports the revocation-check outcome. Supports key-lifecycle evidence. | A missing revocation bundle is reported as unchecked, not as pass. `IA-5(2)` and `SC-17` apply where the signing key is presented with an `x5c` chain (§3.2.1); a bare `cnf.jwk` does not put the record in that case. | No specific reference cited | +| `TraceRevocation/1.0` statements (§3.2.3) | IA-5, IA-5(2) (conditional), SC-12, SC-17 (conditional) | Log-ordered revocation of record-signing keys; a verifier reports the revocation-check outcome. Supports key-lifecycle evidence. | A missing revocation bundle is reported as unchecked, not as pass. The revocation-cache mapping is to the PKI-specific IA-5(2)(b)(2); this and the SC-17 certificate context apply where the signing key is presented with an `x5c` chain (§3.2.1). A bare `cnf.jwk` does not establish that PKI context; IA-5(2)(a) separately covers public-key authentication. | No specific reference cited | | `delegation` (`parent_record_hash`, `credential_id`) (§3.1.3) | AC-2(7), AC-6, AU-3(1) | Lets a verifier walk an offline-verifiable delegation chain across agents and see which parent record and credential each hop acted under. Supports privileged-account and least-privilege evidence across hops. | Only hops that issued a record carrying `delegation` are in the chain. | No specific reference cited | ---