Individual Submission

founder@phalanxaisec.com

General This document defines a trust model for agent-to-agent (A2A) interactions in multi-agent AI systems. It specifies how agents obtain verifiable identities via CA-signed templates, how spawn chains are cryptographically established and validated, how dynamic policies are governed under a dual-signature model, and how cross-organizational agent interactions are explicitly authorized. The model applies existing PKI primitives (X.509, CRL, CSR) and established identity patterns (OAuth 2.0, On-Behalf-Of) to the problem of agent provenance. This document does not address agent-to-resource access control, human-in-the-loop orchestration, or agent behavior, as those concerns belong to the resource enforcement layer and the orchestration layer respectively.

Introduction Multi-agent AI systems introduce identity and authorization gaps that existing standards do not fully address. When Agent A spawns Agent B, and Agent B calls a resource, no current standard defines how the resource verifies that Agent B was legitimately spawned, that its scope has not been escalated, or that its origin template is trusted. This document proposes a trust model based on:

• Agent templates as first-class, CA-signed identity artifacts.
• Verifiable spawn chains where each agent's provenance is cryptographically traceable to a registered template.
• Two-lane governance separating static identity (cert-based) from dynamic policy (OPA-gated).
• Fail-closed enforcement at every verification step.

The model reuses proven PKI primitives and applies them to a new surface -- agent identity -- rather than inventing new cryptographic mechanisms.

Conventions Used in This Document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Terminology

Agent:

An ephemeral, autonomous process that performs tasks on behalf of a user or another agent.

Agent Template:

A CA-signed artifact defining an agent's identity, allowed scopes, spawn rules, and policy reference.

Template Registry:

The authoritative store of approved, signed agent templates for an organization.

Template Registry CA:

The Certificate Authority that signs agent templates -- the root of trust for the agent ecosystem.

Spawn:

The act of an agent instantiating a child agent from an approved template.

Spawn Chain:

The ordered, cryptographically verifiable sequence of agents from the root orchestrator to the current agent.

Policy Authority:

The entity responsible for countersigning dynamic policy changes after automated gate validation.

CRL:

Certificate Revocation List -- the list of revoked template and agent certificates maintained by the CA.

CSR:

Certificate Signing Request -- the template author's request to the CA for a signed template certificate.

Cross-Org Grant:

An explicit, signed authorization allowing agents from one organization to spawn from a template owned by another.

Problem Statement Multi-agent orchestration creates identity and authorization gaps:

spawns --> Agent B --> calls --> Resource ]]>

• Which identity does the Resource see?
• How does authorization propagate across the chain without escalating?
• If Agent B is compromised, can it impersonate Agent A?
• Who owns the audit trail across the full chain?
• How does the Resource prove Agent B was authorized to be spawned?

No current standard (W3C, IETF, or vendor) fully addresses agent provenance in multi-hop chains.

Existing Patterns and Gaps

On-Behalf-Of (OBO) Microsoft Entra ID OBO provides user-to-service delegation:

Agent A (token A) --> Agent A requests token for Agent B on behalf of user --> Entra validates the chain --> Issues scoped delegated token ]]>

Key insight: a trusted third party validates the delegation chain. Agents do not self-assert trust. OBO breaks down for agent-to-agent because agents are ephemeral, agent spawning is dynamic, and no registry exists for agent templates.

OAuth 2.0 Token Exchange (RFC 8693) defines scope constraint across delegation hops -- downstream tokens MUST be a subset of upstream grants. This document adopts that principle for agent scope inheritance.

Agent Identity Agent identity MUST be established using X.509 certificate chains . This reuses the same trust model used by TLS and existing workload identity systems.

Certificate Profile Certificates used for agent identity MUST conform to . In addition, a relying party validating an agent certificate MUST enforce all of the following, and MUST refuse the certificate if any is not satisfied:

• An agent certificate MUST carry the basicConstraints extension asserting cA = FALSE. A certificate that omits basicConstraints MUST be refused; the extension's absence MUST NOT be treated as equivalent to cA = FALSE.
• A Template Registry CA certificate MUST carry basicConstraints asserting cA = TRUE, marked critical, and MUST assert keyCertSign in its keyUsage extension.
• Certificates MUST be signed using SHA-256 or a stronger digest. Certificates signed with SHA-1 or MD5 MUST be refused irrespective of key size.
• Public keys MUST provide at least a 112-bit security level as defined in -- RSA 2048 or NIST P-256 or stronger. A relying party MUST refuse a certificate whose key falls below this level.

An agent certificate asserting cA = TRUE is a certificate entitled to issue further certificates. Such an agent can create children without presenting a request to the Template Registry CA, which removes both checks required by from the spawn path entirely. No signature is invalid in that scenario and no chain fails to verify; the containment described in is simply never consulted. This is the reason the constraint is stated normatively here rather than left to the general RFC 5280 profile. These requirements are necessary and not sufficient. A certificate satisfying all of them establishes identity only; it carries no authorization. See .

Certificate Signing Request Flow

Certificate Chain Structure

Template Registry CA PermittedOperations: read only AllowedScopes: read:data (MUST be subset of parent) TTL: 15min (SHOULD be shorter than parent) ]]>

Template Structure

Static Fields The following fields MUST be present in every agent template certificate and MUST NOT be modified without full re-certification:

Field	Required	Description
Subject	REQUIRED	Unique template identifier
Issuer	REQUIRED	Template Registry CA
Owner	REQUIRED	Verified identity of template owner
OrgID	REQUIRED	CA-validated organization identifier
PermittedOperations	REQUIRED	Operations this agent may perform
AllowedScopes	REQUIRED	Maximum scopes this agent may hold
CanSpawn	REQUIRED	Whitelist of permitted child templates
MaxChildren	REQUIRED	Maximum concurrent child agents
PolicyRef	REQUIRED	Pointer to dynamic policy store
TTL	REQUIRED	Maximum agent lifetime

Dynamic Policy Bounds Dynamic policies MUST be bounded by the static template fields. A dynamic policy MUST NOT grant scopes beyond AllowedScopes. A dynamic policy MUST NOT add spawn targets beyond CanSpawn. A relying party MUST evaluate these bounds itself, on every validation, against the static fields of the template certificate naming the subject the policy governs. This evaluation MUST be independent of signature validity, and a policy exceeding the bounds MUST be refused before it is applied, however many valid signatures it carries. The signatures required by and the bounds required here answer different questions. The signatures establish who authorized a change. They do not, and cannot, establish that the change was within the ceiling the template set, because the ceiling is stated in a certificate that no signature over the policy covers. An implementation that treats a valid dual signature as sufficient authority to apply a policy has removed the only mechanism bounding what a policy may grant. Refusal under this section is a distinct condition from a signature failure, and implementations SHOULD report it distinctly: the document is authentic and its content is not permitted. Reporting it as a signature failure misdirects the operator to the wrong lane of .

Spawn Chain Validation

Two-Check Spawn Rule Every spawn MUST pass two independent checks. Either check failing MUST result in spawn denial with no fallback. Check 1 -- Static (CanSpawn in certificate): The requested child template MUST appear in the spawning agent's CanSpawn list. Check 2 -- Dynamic (Registry live lookup): The requested child template MUST be currently registered, CA-signed, not self-signed, owned by an authorized party, and not present in the current CRL. Rationale: CanSpawn alone is insufficient because the certificate may be stale and a template may have been revoked since issuance. Registry lookup alone is insufficient because any party could forge a request claiming any template. Both checks MUST pass.

Spawn Validation Sequence

DENY, audit log YES --> continue 2. Registry check -- registered, CA-signed, not revoked? NO --> DENY, audit log YES --> continue 3. Scope check -- requested scope subset of parent scopes? NO --> DENY, audit log YES --> continue 4. MaxChildren check -- current children < MaxChildren? NO --> DENY, audit log YES --> spawn approved 5. Child certificate issued with: - parent identity embedded (delegation chain) - scope equal to requested scope (not exceeding parent) - spawn timestamp and nonce (replay prevention) - audit log entry written ]]>

Scope Constraint A child agent's AllowedScopes MUST be a subset of the parent agent's AllowedScopes: every scope granted to the child MUST also be held by the parent. A child MUST NOT be granted any scope the parent does not itself hold; scope escalation across agent hops is explicitly prohibited. Equality is permitted -- a child MAY be granted the same scope set as its parent, or fewer. Example:

Audit Requirements Every spawn event MUST be logged with: spawning agent identity, child template identity, requested scope, granted scope, timestamp, outcome (ALLOWED or DENIED), and reason if denied.

Dynamic Policy Governance

Two-Lane Model Template certificate (static): WHO the agent is and WHO it can spawn. Changes require full re-certification. Dynamic policy (fast lane): WHAT the agent can do within the bounds of the template certificate. Changes require dual signature (). Dynamic policies MUST NOT exceed the bounds defined in the static template certificate.

Ownership Template ownership MUST be established at certificate signing time and embedded in the Owner and OrgID fields. Only the verified owner of the organization that signed the template MAY submit policy changes.

Dual Signature Requirement Every policy change MUST be signed by two independent parties:

1. Owner -- proves the right to change the policy.
2. Policy Authority -- proves the policy passed automated validation gates.

Neither signature alone is sufficient. Both MUST be present and valid for a policy to be accepted.

Dynamic Policy Document Structure A dynamic policy document MUST contain the following fields. This is the complete set; a document containing any other field MUST be refused, since an unrecognized field is either meaningless or an attempt to convey authority the profile does not define. Dynamic Policy Document Fields

Field	Required	Description
Subject	REQUIRED	Identifier of the agent this policy governs; MUST match the Subject of the template certificate
Owner	REQUIRED	Submitting owner; MUST match Owner in the template certificate
OrgID	REQUIRED	Submitting organization; MUST match OrgID in the template certificate
Scopes	REQUIRED	Scopes granted by this policy; bounded by AllowedScopes
SpawnTargets	OPTIONAL	Spawn targets granted by this policy; bounded by CanSpawn. Absent means none are granted
Version	REQUIRED	Monotonically increasing integer, scoped to Subject
IssuedAt	REQUIRED	Timestamp of issuance, RFC 3339
NotAfter	OPTIONAL	Expiry of this policy; MUST NOT exceed the template TTL

Version is scoped to the Subject, not global. A relying party MUST refuse a policy whose Version is not strictly greater than the Version of the policy currently in force for that Subject.

Canonicalization Signatures and hashes defined by this document are computed over bytes, so the mapping from a policy document to those bytes MUST be deterministic and identical across implementations. Wherever this document requires a canonical form -- of a policy document, of any field subset thereof, or of an audit log entry -- that canonical form MUST be the JSON Canonicalization Scheme (JCS) serialization defined in . A single canonical form is specified for all of them deliberately: an implementation carrying two serializations will eventually apply the wrong one, and the resulting failure presents as a signature or integrity error with no indication that serialization was the cause. JCS is specified rather than described here because a bespoke serialization would require this document to define property ordering, string escaping, and number formatting correctly and completely, and any error in that definition surfaces to implementers as a signature failure that appears to be a cryptographic fault. Serializations that differ only in whitespace, key order, or the escaping of non-ASCII characters produce different bytes and therefore different signatures; implementers MUST NOT assume a language's default JSON encoder produces the canonical form, as most do not.

Signature and Hash Coverage Both signatures required by MUST be computed over the canonical form () of the complete set of fields defined in . No field in that table is excluded from either signature. In particular, Version MUST be inside the signed preimage. Version exists to prevent replay, and it cannot serve that purpose while it remains modifiable without invalidating a signature: an attacker holding no key can otherwise take a superseded but validly signed policy, increment its Version, and present it as current. Both signatures verify, the content hash matches, and the version reads as current. The same reasoning applies to Subject: a signature that does not bind the policy to the agent it governs permits a policy issued for one agent to be presented for another. The content hash required by MUST be SHA-256, or a stronger digest, computed over the same canonical form and the same field set as the signatures. The hash field itself is stored alongside the policy document and MUST NOT be included in its own preimage. The signatures and the content hash are stored with the policy document but are not part of it. A relying party MUST NOT accept a document in which they appear as policy fields.

Policy Change Sequence

rejected, audit logged 2. Automated gate (OPA): - scope within AllowedScopes? - spawn targets within CanSpawn? - no conflicts with active policies? ANY FAIL --> rejected 3. Dual signature applied: Owner signs, Policy Authority countersigns 4. Policy stored with dual signature, version, timestamp, and content hash 5. Agent validates at runtime: - both signatures valid? - version current? (replay prevention) - hash matches? (tamper detection) - policy within template certificate bounds? ANY FAIL --> DENY, audit logged ]]>

Threat Coverage

Scenario	Single Sig Gap	Dual Sig Fix
Rogue Policy Authority	Pushes bad policy	Owner key missing
Rogue owner	Bypasses OPA gates	PA won't countersign
Compromised owner key	Attacker modifies	OPA gates enforced
Compromised Policy Auth	Pushes bad policy	Owner key missing

Template Versioning

Full Re-Verification Required A new template version MUST undergo full re-verification from scratch. Trust MUST NOT be inherited from a previous version. Rationale: inheriting trust from v1 would allow a compromised v1 certificate to bootstrap trust for v2.

Versioning Principle Everything on the old template chain continues to work unchanged as long as the certificate is valid. New connections and functionality are opt-in -- only available after the new template chain is fully verified and explicitly adopted.

Non-Inheritance Rules The following MUST NOT be inherited from a previous version:

• Trust chain
• Cross-organizational grants
• CanSpawn list
• Dynamic policies

Template Lifecycle

ACTIVE:

Template is trusted. New spawns accepted.

DISABLED:

No new spawns. Existing agents run to TTL expiry. Reversible.

DELETED:

Certificate revoked, CRL updated, registry entry removed. Irreversible. Audit log preserved.

Disable SHOULD precede delete. Implementations SHOULD enforce a mandatory waiting period between DISABLED and DELETED.

Cross-Organizational Grant Re-Issuance Cross-organizational grants MUST be explicitly re-issued for each new template version. Grants MUST NOT automatically roll over on version upgrade.

Cross-Organizational Agent Interaction

Explicit Grant Requirement Cross-organizational agent spawning MUST be explicitly authorized by the resource-owning organization. No implicit trust exists between organizations.

Grant Structure A cross-organizational grant MUST contain:

Field	Description
Grantor	Resource-owning organization
Grantee	Requesting organization
Template	Specific template identifier
AllowedScopes	MUST be subset of template scopes
TTL	Grant validity period
MaxSpawns	Maximum concurrent agents permitted
Signature	Dual signature (grantor owner + Policy Authority)

Trust Anchor Options

Federated CA:

Both organizations trust a shared root CA.

Explicit CA trust:

Org-B explicitly trusts Org-A's CA.

Third-party CA:

Both organizations use a public CA.

Unilateral Revocation The granting organization MAY revoke a cross-organizational grant without the cooperation of the receiving organization. Upon revocation, all agents spawned under the affected grant MUST be treated as untrusted on next validation.

Federated Audit Each organization MUST maintain its own independent audit trail. Audit records MUST NOT depend on the other organization's systems.

Revocation

Template Revocation Template revocation MUST be performed by recording the template certificate as revoked in the CA's revocation state -- an X.509 CRL, an OCSP responder, or an equivalent revocation registry consulted on every validation. All agent certificates derived from a revoked template MUST be treated as untrusted on the next revocation check.

Individual Agent Revocation Individual agents MAY be revoked by explicit certificate revocation or by removal of authorization relationships at the resource layer.

Automation Requirement Routine revocation (TTL expiry, task completion) MUST be fully automated. Human involvement SHOULD be reserved for incident response and high-impact decisions.

Failure Model

Fail Closed Any verification step that cannot be completed MUST result in DENY. This includes:

• CA unreachable
• Registry unreachable
• CRL unreachable
• Certificate expired or revoked
• Scope escalation attempt
• Policy invalid or unsigned
• Dual signature missing or invalid

Implementations MUST NOT provide a degraded mode that allows partial spawning or execution when verification infrastructure is unavailable.

Conformance Requirements

Field Placement Implementations MUST place every field in the location specified by this document. Variable element placement is NOT permitted.

CSR Validation Non-conforming CSRs MUST be rejected by the CA. A non-conforming template MUST NOT be signed.

Test Vectors Implementations MUST provide test vectors -- concrete examples of valid and invalid template chains -- for conformance validation.

Conformance Certification Implementations claiming conformance with this document MUST pass conformance certification before shipping.

Reference Implementation A reference implementation SHOULD be made available including:

• Template Registry CA
• Spawn chain validation
• SDK with certificate chain validation, registry lookup, and CRL check handling
• Template linter for pre-submission CSR validation

Three independent implementations exist at the time of writing. Each states the revision it was written and verified against, and continues to state that revision until someone re-reads the newer text and re-runs the vectors. An implementation pinned to an earlier revision remains a correct implementation of that revision; a version string is a conformance claim rather than a label, and advancing one without re-verifying asserts conformance nobody has tested. Known Implementations

Implementation	Revision	Notes
a2a-trust-playground	-02	Browser implementation, no installation or backend. Validates a chain against every check in this document and reports the clause governing each refusal. Source: https://github.com/tonyt68/a2a-trust-playground
ietf-a2a-trust-poc	-00	Registry CA, spawn validation and policy governance services. Source: https://github.com/tonyt68/ietf-a2a-trust-poc
hack-my-own-code	-00	Adversarial implementation that attacks its own conformance. Source: https://github.com/tonyt68/hack-my-own-code

The changes in this revision were surfaced by building the first of these against the -01 text and attacking it, rather than by review of the text alone. Implementers are encouraged to report what the document does not say clearly enough, which is a different and more useful signal than agreement with it.

IANA Considerations This document has no IANA actions.

Security Considerations

Scope Escalation Implementations MUST enforce at every hop that child agent scopes are a subset of parent scopes: child scopes are contained within parent scopes, and no scope may be introduced that the parent does not already hold. Failure to enforce this allows privilege escalation across the agent chain.

Replay Attacks Spawn requests MUST include a timestamp and nonce. Implementations MUST reject spawn requests where the timestamp exceeds a defined freshness window or the nonce has been seen previously.

Compromised Templates A compromised template certificate MUST be revoked immediately. A single CRL update invalidates all downstream agent certificates derived from that template.

Single Point of Compromise The dual signature requirement () ensures no single compromised party can push unauthorized policy changes. CA compromise requires full ecosystem re-issuance.

Cross-Organizational Trust Cross-organizational grants MUST be explicitly issued. Implicit trust between organizations is prohibited.

PKI Does Not Enforce Authorization Because agent identity is carried in X.509 certificates and the chain is verified on every validation, it is natural to assume the certificate chain also constrains what an agent may do. It does not, and an implementation built on that assumption is unprotected while appearing rigorous. X.509 carries no representation of the scopes defined by this document. AllowedScopes, CanSpawn and MaxChildren are conveyed in the template, and no certificate path validation algorithm inspects them. A conformant X.509 validator presented with an agent certificate whose associated template claims scopes far beyond those its parent holds will report success, because the certificate is genuinely valid and correctly issued. The over-scoping is not a defect the validator is looking for. The nameConstraints extension does not close this gap. It constrains the namespace within which a CA may issue, not the authority a subject may claim once issued. Likewise certificatePolicies expresses which policies a chain supports, not whether a child exceeded its parent, and policy processing is disabled by default in common implementations. Consequently and are load-bearing implementation logic. They are not restatements of a property the certificate chain already guarantees, and an implementation that omits them because "the chain verifies" has no containment at all. Certificate validity establishes identity. Authorization is evaluated separately, every time.

Audit Integrity Audit logs MUST be tamper-evident. Logs MUST NOT be deletable by agents or orchestrators. Audit log infrastructure SHOULD be outside the control of the agent ecosystem itself. Each entry's hash MUST be computed as SHA-256, or a stronger digest, over the canonical form () of the entry's fields including the previous entry's hash, and excluding the entry's own hash field. As with policy documents, an unspecified preimage is not a detail: two implementations hashing different field sets each read the other's chain as broken, and a chain that cannot be verified across implementations provides no evidence to anyone but its author.

References Normative References Informative References SPIFFE Project OpenFGA Project HashiCorp

Changes since draft-tonyai-a2a-trust-01 All changes in this revision were surfaced by building a second, independent implementation of the -01 text and attacking it. Changes are described below by their effect on a conformant implementation rather than by intent: where an implementation conforming to -01 must change to remain conformant, this is stated plainly, because an implementer reading this appendix is deciding whether re-verification is required. Four changes below are breaking. Two implementations exist at the time of writing, both under the author's control; the cost of these changes is at its minimum now and rises permanently once a third-party implementation ships. Security fix -- breaking.

• Section 9.6 (Signature and Hash Coverage) is new, and requires that Version and Subject be inside the signed preimage. In -01 the policy version was listed in Section 9.4 as a value stored alongside the signature, and the text never required the signature to cover it. Both existing implementations read it that way and neither signed the version, which defeats the replay prevention that Section 9.4 assigns to that field: an attacker holding no key can take a superseded but validly signed policy, increment the version, and have it accepted -- both signatures verify, the content hash matches, and the version reads as current. Implementations MUST re-sign existing policies under the new coverage. Signatures produced under -01 do not verify under -02.

Interoperability -- breaking.

• Section 9.5 (Canonicalization) is new, and normatively specifies JCS (RFC 8785) as the serialization for all signatures and hashes. -01 contained no canonicalization text of any kind, which made Section 9.3 impossible to implement interoperably: a signature is over bytes, and nothing in -01 said how those bytes are produced. The only way to implement -01's dual signature was to read an existing implementation's source. JCS differs from what both current implementations do, so both must change and all existing signatures and test vectors are invalidated. An existing implementation is not conformant to -02 by default.
• Section 9.4 (Dynamic Policy Document Structure) is new. -01 required the dynamic policy to be signed, hashed, stored and integrity-checked without ever defining what it contains, leaving each implementer to invent a field set. Different invented sets produce different signatures and different hashes for the same policy, and each implementation reads the other's documents as tampered with. Implementations whose field set differs from the table in Section 9.4 must change.

New normative requirements -- additive.

• Section 6.3 (Certificate Profile) is new. -01 mandated X.509 and specified no profile: no key strength, no digest floor, and no basicConstraints requirement. Three certificates that verify under a conformant X.509 validator were accepted as agent identities by an implementation conforming to -01 -- one asserting cA = TRUE, one signed with SHA-1, and one carrying no basicConstraints at all. The first is also a containment failure: an agent whose certificate permits it to issue certificates can create children without presenting a request to the CA, which removes both checks in Section 8.1 from the spawn path without invalidating any signature. Implementations already issuing cA = FALSE, SHA-256, RSA-2048 leaves satisfy this section unchanged, but MUST add the corresponding checks on validation.
• Section 7.2 now states who enforces the dynamic policy bounds, when, and with what result. -01 stated the rule and named no enforcement point, so an implementation that never checked it and one that checked it before signature verification both read as conformant while returning different results for the same document. The bounds MUST now be evaluated independently of signature validity and refused before the policy is applied.

Rename -- breaking.

• The Section 7.1 static field KeyUsage is renamed PermittedOperations. The field carries the operations an agent may perform -- spawn, delegate, read -- and is unrelated to the X.509 keyUsage extension, whose values are digitalSignature, keyCertSign and the rest of the RFC 5280 set. The collision was latent while this document never referred to the X.509 extension; Section 6.3 now does, normatively, so a single document used one name for two unrelated things. RFC 5280 owns the name keyUsage, so the template field is the one that moves. The new name is the description this document already gave the field. Implementations MUST rename the corresponding metadata field; the value space is unchanged.

Removal -- breaking for any implementation reading the field.

• The ScopeInherit field is removed from the Section 7.1 static field table. It was REQUIRED in -00 and -01 with no defined value space, and the value both existing implementations populate it with, "strict-subset", contradicts Section 8.3 as clarified in -01, which explicitly permits equality. Neither implementation reads the value, so the field conveyed no capability; Section 8.3 already determines inheritance completely. An implementation that enforced the field literally would deny a child legitimately holding its parent's full scope set, which is the misreading -01 was published to prevent.

Non-normative.

• Section 16.7 (PKI Does Not Enforce Authorization) is new. It states that certificate validity establishes identity and not authorization, that neither nameConstraints nor certificatePolicies closes that gap, and that Sections 7.2 and 8.3 are therefore load-bearing implementation logic rather than restatements of a guarantee the chain already provides. No behaviour changes; the omission was judged the most likely to cause an implementer to build something that verifies correctly and contains nothing.

Changes since draft-tonyai-a2a-trust-00 Clarified two areas identified as ambiguous during development of a reference implementation:

• Section 8.3/16.1 scope-subset language now explicitly permits equality between a child's requested scope and its parent's granted scope; only escalation (a superset) is prohibited. The prior wording could be misread as requiring a strict/proper subset, which would wrongly deny a child that legitimately needs the same scope as its parent.
• Section 12.1 revocation-check language now explicitly accepts an X.509 CRL, an OCSP responder, or an equivalent revocation registry, rather than implying a CRL specifically. The normative requirement is that revocation state is consulted on every validation, not the specific mechanism used to represent it.

Neither change alters the normative requirements themselves; both make explicit what the -00 text intended. Both were surfaced by building and red-teaming a conformance reference implementation against the -00 text.