]> Kestura UG (haftungsbeschraenkt)

info@kestura.com

General Independent Submission policy-as-code compliance attestation OPA governance Organizations increasingly enforce regulatory and security requirements using policy-as-code (PaC) engines integrated into continuous integration and delivery (CI/CD) pipelines. The evidence these engines produce, that is, the record of which policies were evaluated, against what inputs, and with what outcome, is typically emitted in vendor-specific, non-portable formats. This impairs auditability, cross-tool aggregation, and independent verification. This document analyzes the problem and describes an interoperable, machine-readable attestation format for PaC compliance evidence. It is informational and does not define an IETF standard, nor does it establish a new IANA registry.

Introduction Policy-as-code (PaC) expresses organizational, security, and regulatory rules as machine-evaluable code rather than prose. Engines such as those using the Rego language evaluate these policies against structured inputs at decision points in CI/CD pipelines, admission controllers, and runtime gateways. A single deployment may evaluate thousands of policy decisions per day. Each decision produces evidence: the policy that was evaluated, the input it was evaluated against, the resulting decision, and contextual metadata such as time and evaluator identity. Auditors, downstream tools, and independent verifiers increasingly need to consume this evidence. Today it is emitted in formats that differ across engines and vendors, which prevents portable audit trails and cross-tool correlation. This document analyzes the interoperability gap and describes a common attestation structure for representing PaC compliance evidence. The goal is to enable evidence to be exchanged, aggregated, and verified across otherwise incompatible tools.

Terminology

Policy decision:

The outcome of evaluating one policy against one input.

Attestation:

A signed or verifiable statement binding a policy decision to its evidentiary context.

Evidence:

The data supporting a policy decision, including the policy identity and a digest of the input.

Verifier:

A party that consumes attestations to confirm a decision occurred as claimed.

Policy Decision Point (PDP) / Policy Enforcement Point (PEP):

The components that, respectively, evaluate policy and enforce its outcome.

Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

Problem Statement The absence of a common evidence format produces three concrete problems. First, audit trails are locked to the tool that produced them. An organization that changes PaC engines cannot easily correlate historical evidence with new evidence. Second, evidence cannot be aggregated across heterogeneous tools. A large environment may run several engines at different enforcement points; without a shared format, a unified compliance view requires bespoke adapters for each. Third, independent verification is difficult. A third party, such as an external auditor, cannot readily confirm that a decision occurred as claimed when the evidence format is proprietary and undocumented.

Survey of Existing Approaches Several adjacent formats inform this work without directly solving the problem. Decision logs emitted by PaC engines capture per-decision data but are engine-specific. Software supply-chain attestation frameworks bind statements to subjects and provide a useful structural analogy. Software bill-of-materials and vulnerability-exchange documents demonstrate the value of portable, machine-readable evidence in the supply-chain domain. This document draws on these patterns while focusing specifically on PaC compliance decisions.

Attestation Model An attestation binds a policy decision to its evidentiary context. It contains, at minimum: a subject identifying what the decision concerns; a policy identity, including a version or content digest; a digest of the evaluated input, rather than the input itself, to avoid exposing sensitive data; the decision outcome; a timestamp; and the identity of the evaluating component. The use of digests, rather than raw inputs, allows evidence to be shared and verified without disclosing potentially sensitive evaluation data.

Serialization Considerations Attestations can be represented using widely deployed structured-data encodings. This document describes the model in terms of existing media types and does not define a new one. Implementations SHOULD prefer encodings that support deterministic serialization to enable reproducible digests and signatures.

Mapping to Regulatory Frameworks The attestation model is framework-neutral but maps naturally to concrete regimes. For example, a control requirement can be expressed as one or more policies, and each evaluation produces an attestation demonstrating that the control was checked. This provides an auditable link between a regulatory obligation and the automated evidence of its enforcement.

Verification and Aggregation A verifier consumes attestations to confirm that a claimed decision occurred. Because attestations are self-describing and reference policy and input by digest, they can be aggregated across tools into a single compliance view and independently checked without access to the original evaluation environment.

In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This document describes the procedures used by the IESG for handling documents submitted for RFC publication from the Independent Submission and IRTF streams. This document updates procedures described in RFC 2026 and RFC 3710. This memo documents an Internet Best Current Practice.

Security Considerations Attestations assert that a policy decision occurred; their value depends on integrity and authenticity. Implementations SHOULD protect attestations against tampering and SHOULD support verification of the evaluator's identity. Because attestations reference inputs by digest, they avoid disclosing potentially sensitive evaluation data. This document describes a data model and introduces no new protocol behavior; it presents no new operational risk to the Internet.

IANA Considerations This document requests no IANA actions.

Privacy Considerations Evaluation inputs may contain sensitive information. For this reason the attestation model references inputs by digest rather than embedding them. Implementations SHOULD avoid placing sensitive data in attestation fields that are intended for wide distribution.

Acknowledgements The author thanks the reviewers who contributed to this document.