Independent Submission C. Hood Internet-Draft Nomotic, Inc. Intended status: Informational 26 May 2026 Expires: 27 November 2026 AGTP Agent Certificate Extension draft-hood-agtp-agent-cert-01 Abstract The Agent Transfer Protocol (AGTP) base specification defines agent identity headers (Agent-ID, Principal-ID, Authority-Scope) that are self-asserted: present on every request and mandatory for logging, but not cryptographically verified at the transport layer. This document specifies the AGTP Agent Certificate Extension: an optional mechanism that binds Agent-ID, Principal-ID, and Authority-Scope to an X.509 v3 certificate presented during TLS mutual authentication. The extension enables infrastructure components including Scope- Enforcement Points (SEPs), load balancers, and governance gateways to verify agent identity and enforce authority scope without application-layer access, at O(1) cost per request header check. The extension also defines session-level revocation propagation via AGTP NOTIFY broadcast and a Certificate Transparency Log for tamper- evident governance metadata. Note: Certain mechanisms described in this document may be subject to pending patent applications by the author. The licensor is prepared to grant a royalty-free license to implementers consistent with the IETF's IPR framework. See the IPR Notice and Section 7. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 27 November 2026. Hood Expires 27 November 2026 [Page 1] Internet-Draft AGTP-CERT May 2026 Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Identity Gap in Base AGTP . . . . . . . . . . . . . . 3 1.2. The Agent Certificate Extension . . . . . . . . . . . . . 3 1.3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. AGTP Agent Certificate Schema . . . . . . . . . . . . . . . . 4 3.1. Certificate Structure . . . . . . . . . . . . . . . . . . 4 3.1.1. Standard Subject Fields . . . . . . . . . . . . . . . 5 3.1.2. Agent-Governance X.509 v3 Extensions . . . . . . . . 5 4. Certificate Issuance Protocol . . . . . . . . . . . . . . . . 7 4.1. Eligibility . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. Issuance Steps . . . . . . . . . . . . . . . . . . . . . 7 4.3. Certificate Validity . . . . . . . . . . . . . . . . . . 8 5. TLS Integration . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Mutual Authentication . . . . . . . . . . . . . . . . . . 8 5.2. Scope Enforcement at SEPs . . . . . . . . . . . . . . . . 9 6. Revocation and Session Propagation . . . . . . . . . . . . . 9 6.1. Revocation Events . . . . . . . . . . . . . . . . . . . . 9 6.2. Session-Level Revocation Propagation . . . . . . . . . . 10 6.3. Session Manager Responsibilities . . . . . . . . . . . . 11 7. AGTP Certificate Transparency Log . . . . . . . . . . . . . . 11 7.1. Purpose . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Log Structure . . . . . . . . . . . . . . . . . . . . . . 11 7.3. Privacy Considerations . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 8.1. Certificate Pinning . . . . . . . . . . . . . . . . . . . 12 8.2. Scope Commitment Forgery . . . . . . . . . . . . . . . . 12 8.3. Cross-Certificate Confusion . . . . . . . . . . . . . . . 13 8.4. IPR Notice . . . . . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 9.1. X.509 Extension OID Registrations . . . . . . . . . . . . 13 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 10.1. Normative References . . . . . . . . . . . . . . . . . . 14 10.2. Informative References . . . . . . . . . . . . . . . . . 15 Appendix A. Relationship to Agent Genesis . . . . . . . . . . . 16 Hood Expires 27 November 2026 [Page 2] Internet-Draft AGTP-CERT May 2026 Appendix B. Changes from v00 . . . . . . . . . . . . . . . . . . 17 B.1. Substantive Changes . . . . . . . . . . . . . . . . . . . 17 B.2. Wire Format Compatibility . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 1. Introduction 1.1. The Identity Gap in Base AGTP The AGTP base specification requires every request to carry Agent-ID, Principal-ID, and Authority-Scope headers. These headers are self- asserted: an AGTP client declares its identity and scope, and the server logs the declaration. In the base spec, there is no transport-layer mechanism to verify that the declared Agent-ID corresponds to a registered agent, that the Principal-ID is accurate, or that the Authority-Scope does not exceed what was granted. This is a deliberate design choice in the core spec: self-asserted identity with mandatory logging provides a useful baseline and enables broad adoption. For many deployments, anomaly detection and audit trails over self-asserted headers are sufficient. For higher-stakes deployments -- financial transactions, healthcare operations, legal actions, multi-organization agent federations -- the self-assertion model is insufficient. Infrastructure needs to verify agent identity and enforce scope at the transport layer without parsing application payloads. 1.2. The Agent Certificate Extension The AGTP Agent Certificate Extension provides cryptographic identity binding at the transport layer. An AGTP Agent Certificate is an X.509 v3 certificate with agent-governance-specific extensions. It is presented during TLS mutual authentication, enabling the server and any AGTP-aware infrastructure component to verify the agent's identity and authority scope from the certificate alone, without inspecting the request headers or body. This document specifies: * The AGTP Agent Certificate schema and X.509 v3 extension fields * The certificate issuance and renewal protocol * The authority scope commitment mechanism for O(1) per-request scope enforcement * Session-level revocation propagation via AGTP NOTIFY Hood Expires 27 November 2026 [Page 3] Internet-Draft AGTP-CERT May 2026 * The AGTP Certificate Transparency Log (AGTP-CTL) 1.3. Scope This extension is OPTIONAL. Core AGTP implementations that do not implement this extension remain fully compliant with [AGTP]. The extension is required only for Trust Tier 1 agent identity verification and for SEP-enforced scope constraint without application-layer access. 2. Terminology 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals. AGTP Agent Certificate: An X.509 v3 certificate carrying agent- governance-specific extensions, presented during TLS mutual authentication to establish cryptographic agent identity and authority scope at the transport layer. Scope-Enforcement Point (SEP): An AGTP-aware infrastructure component that enforces Authority-Scope constraints on AGTP requests. With the Agent Certificate Extension, SEPs verify scope from the certificate at O(1) cost per request without application- layer access. Authority-Scope Commitment: A cryptographic binding of the agent's declared Authority-Scope tokens to the Agent Certificate, enabling SEPs to verify scope token membership after a single session- establishment signature verification. AGTP Certificate Transparency Log (AGTP-CTL): A Merkle-tree-based append-only log of issued AGTP Agent Certificates, providing tamper-evident public accountability for certificate issuance and revocation. 3. AGTP Agent Certificate Schema 3.1. Certificate Structure The AGTP Agent Certificate is an X.509 v3 certificate per [RFC5280] with the following subject fields and extensions: Hood Expires 27 November 2026 [Page 4] Internet-Draft AGTP-CERT May 2026 3.1.1. Standard Subject Fields +====================+==========+============================+ | Field | Required | Value | +====================+==========+============================+ | CN (Common Name) | *MUST* | Human-readable agent label | +--------------------+----------+----------------------------+ | O (Organization) | *MUST* | Organization name (maps to | | | | principal_org) | +--------------------+----------+----------------------------+ | OU (Organizational | *MAY* | Governance zone identifier | | Unit) | | | +--------------------+----------+----------------------------+ | emailAddress | *SHOULD* | Contact email of the | | | | responsible principal | +--------------------+----------+----------------------------+ Table 1: AGTP Agent Certificate Subject Fields 3.1.2. Agent-Governance X.509 v3 Extensions The following extensions are defined for AGTP Agent Certificates. OIDs for these extensions are specified in Section 8 (IANA Considerations). *subject-agent-id* (CRITICAL) The canonical AGTP Agent-ID bound to this certificate. The canonical Agent-ID is the 256-bit SHA-256 hash of the canonical-form Agent Genesis document, per [AGTP]. Format: 64 lowercase hexadecimal characters. A relying party that parses an AGTP Agent Certificate *MUST* treat the value carried in this extension as the authoritative Agent-ID for the agent. The certificate's public key is independent of the canonical Agent-ID: the same Agent Genesis (and therefore the same canonical Agent-ID) *MAY* back successive certificates issued with different key pairs across renewal cycles. The TLS layer *MUST NOT* require that the public key hash equal the value carried in subject-agent- id; the equality held only in earlier drafts that derived Agent-ID from the cert public key, and that derivation has been retired in favor of the Genesis-hash derivation specified in [AGTP]. Defense against substitution attacks (in which a CA-signed certificate is presented with a forged subject binding) is performed at the application layer: a relying party that cares about Agent Genesis binding *MUST* retrieve the Agent Genesis for the asserted Agent-ID (via DISCOVER /genesis on the agent's home server, or from a local registry copy), recompute sha256(canonical_form(Agent_Genesis_without_ signature)), and Hood Expires 27 November 2026 [Page 5] Internet-Draft AGTP-CERT May 2026 confirm the result equals the value in subject-agent-id. The relying party *MUST* additionally verify the Agent Genesis signature against the recognized issuer key for the agent's governance platform. SEPs and other transport-layer enforcers *MAY* defer this check to application-layer components but *MUST* ensure the check is performed before treating the asserted Agent- ID as authoritative for governance-sensitive decisions. A certificate whose Agent Genesis binding cannot be verified *MUST* be treated as transport-only: usable for TLS authentication but carrying no authoritative governance identity. *principal-id* (CRITICAL) The identifier of the human or organizational principal accountable for this agent's actions. Carried on the wire as part of the Owner-ID identifier chain; see [AGTP]. Format: UTF-8 string, maximum 256 characters. This field identifies the agent's _owner_ — the principal recorded on the Agent Genesis as accountable for the agent's existence. It is distinct from the acting_principal_id field on extended Attribution-Records per [AGTP-IDENTIFIERS], which identifies the principal on whose behalf the agent acts for a _specific request_, typically lifted from an external OAuth or OIDC credential per the composition section in [AGTP]. The two principals are independent: the owner is permanent and certificate-bound; the acting principal is per-request and credential-bound. A request *MAY* carry both, neither, or one without the other; their semantics do not interact. *authority-scope-commitment* (CRITICAL) The agent's committed Authority-Scope as a canonical token list. The extension value is the lexicographically sorted, comma-separated, UTF-8-encoded list of Authority-Scope tokens the agent is authorized to assert. The integrity of the committed token list is provided by the certificate's enclosing CA signature; no separate signature is carried in the extension. A SEP enforces Authority-Scope at line rate by parsing the extension value once per session and checking each request's Authority-Scope header tokens against the parsed set (Section 5.2). Format: UTF-8 string of comma- separated tokens, each token matching the Authority-Scope token grammar defined in [AGTP]. *governance-zone* (NON-CRITICAL) The governance zone identifier in which the agent is registered. SEPs *MAY* enforce that the request's AGTP-Zone-ID header matches this value; a mismatch results in a 457 Zone Violation per Section 5.2. Format: UTF-8 string following the zone: prefix convention. *trust-tier* (NON-CRITICAL) The agent's Trust Tier (1, 2, or 3) as Hood Expires 27 November 2026 [Page 6] Internet-Draft AGTP-CERT May 2026 defined in [AGTP]. Format: INTEGER. *archetype* (NON-CRITICAL) The agent's behavioral archetype as defined in [AGTP]. Format: UTF-8 string; one of: assistant, analyst, executor, orchestrator, monitor. *activation-certificate-id* (NON-CRITICAL) Cross-layer reference to the Agent Genesis lifecycle event that activated this certificate. Enables audit reconstruction from a transport certificate back to the Agent Genesis activation record without introducing a cryptographic dependency that would force certificate re-issuance whenever the Agent Genesis lifecycle state is updated. Format: 64 lowercase hexadecimal characters. *agtp-ctl-sct* (NON-CRITICAL) Signed Certificate Timestamp from the AGTP Certificate Transparency Log, proving the certificate was submitted to the AGTP-CTL before delivery. Format: SCT structure per [RFC6962] Section 3.2. Implementations that issue certificates carrying this extension *MUST* populate the value with a syntactically valid SCT structure; cryptographic verification of the SCT against an operating AGTP-CTL is deferred to a future revision of this document. Until that revision, relying parties *MAY* parse the extension for record-keeping purposes but *MUST NOT* treat its presence or absence as authoritative for trust decisions. 4. Certificate Issuance Protocol 4.1. Eligibility Certificate Signing Requests (CSRs) for AGTP Agent Certificates *MUST* only be accepted for agents in Active lifecycle state in the AGTP registry. A governance platform *MUST* verify the agent's lifecycle state at CSR submission time and *MUST* reject CSRs for agents in Suspended, Revoked, or Deprecated state. 4.2. Issuance Steps 1. The governance platform generates a key pair for the agent (or accepts a CSR with an agent-generated key pair). 2. The governance platform populates the certificate subject fields and all AGTP-specific extensions from the agent's Agent Genesis and registry record. 3. The governance platform verifies that the proposed authority- scope- commitment does not exceed the scope granted in the agent's Agent Genesis. If it does, the CSR *MUST* be rejected. Hood Expires 27 November 2026 [Page 7] Internet-Draft AGTP-CERT May 2026 4. The governance platform signs the certificate using its issuing CA key per [RFC5280]. 5. If an AGTP Certificate Transparency Log is operating, the governance platform submits the certificate to the AGTP-CTL and obtains a Signed Certificate Timestamp (SCT). Until AGTP-CTL is operating, this step is omitted and the agtp-ctl-sct extension is not populated. 6. When an SCT is obtained, it is embedded in the agtp-ctl-sct extension and the certificate is delivered to the agent. Otherwise the certificate is delivered without the agtp-ctl- sct extension. 7. The governance platform publishes the new certificate to the agent's registry record, triggering a registry state update. 4.3. Certificate Validity AGTP Agent Certificates *SHOULD* have a validity period of no more than 90 days. Short validity periods limit the exposure window of a compromised certificate and reduce reliance on revocation mechanisms. Renewal *SHOULD* begin at 80% of the validity period. Certificate renewal carries forward the predecessor's subject-agent- id and activation-certificate-id unchanged. The renewed certificate receives a new serial number, new validity period, and a new SCT. 5. TLS Integration 5.1. Mutual Authentication AGTP connections using the Agent Certificate Extension *MUST* use TLS 1.3 mutual authentication. The agent presents its AGTP Agent Certificate as the client certificate during the TLS handshake. The server verifies the client certificate chain against the issuing CA trust anchors. Following successful handshake: 1. The server extracts the subject-agent-id extension value and verifies it matches the Agent-ID header on the first request. 2. The server extracts the principal-id extension value and verifies it matches the Principal-ID header on the first request. 3. The server extracts the authority-scope-commitment extension value and uses it to verify Authority-Scope header tokens on each request. Hood Expires 27 November 2026 [Page 8] Internet-Draft AGTP-CERT May 2026 Any mismatch between certificate extension values and AGTP header values *MUST* cause the server to return 401 Unauthorized and *MUST* be logged. 5.2. Scope Enforcement at SEPs A SEP operating with the Agent Certificate Extension verifies Authority-Scope and (optionally) governance zone at O(1) cost per request: 1. At session establishment, the SEP extracts the authority-scope- commitment from the client certificate and parses the comma- separated token list once. The SEP also extracts the governance- zone extension if present and zone enforcement is configured. (One-time per session.) 2. On each request, the SEP checks whether the Authority-Scope header tokens are a subset of the parsed commitment token set. (O(1) per request after session setup.) 3. If any header token is not in the commitment token set, the SEP returns *455 Scope Violation* without forwarding the request to the application layer. 4. If governance-zone enforcement is configured and the request's AGTP-Zone-ID header does not match the value carried in the certificate's governance-zone extension, the SEP returns *457 Zone Violation* without forwarding the request. This enables governance enforcement at line rate without application- layer parsing. A certificate that lacks the AGTP-specific extensions is a valid TLS client certificate but carries no SEP-enforceable governance metadata. SEP enforcement of authority-scope-commitment and governance-zone is purely additive: in the absence of those extensions, scope and zone are enforced through application-layer checks against the agent's Agent Identity Document per [AGTP]. Deployments *MAY* mix certificates with and without AGTP extensions; the SEP layer treats each session by what its certificate carries. 6. Revocation and Session Propagation 6.1. Revocation Events An AGTP Agent Certificate *MUST* be revoked when any of the following occur: Hood Expires 27 November 2026 [Page 9] Internet-Draft AGTP-CERT May 2026 * The agent's lifecycle state transitions to Revoked or Deprecated * The Agent Genesis is invalidated * The agent's authority-scope-commitment requires modification * The principal requests revocation * A trust violation is detected 6.2. Session-Level Revocation Propagation Standard certificate revocation (CRL, OCSP) operates on polling cycles, leaving a window during which revoked certificates may still be used. For agent systems, this window is unacceptable for high- stakes operations. AGTP Agent Certificate revocation *MUST* be propagated to active sessions via AGTP NOTIFY broadcast: 1. The governance platform issues a revocation event to the AGTP- CTL. 2. The governance platform broadcasts an AGTP NOTIFY to all infrastructure components holding active sessions for the revoked certificate's subject-agent-id: { "method": "NOTIFY", "parameters": { "recipient": "infrastructure:broadcast", "content": { "event_type": "certificate_revoked", "subject_agent_id": "[agent-id]", "certificate_serial": "[serial]", "revocation_reason": "[reason]", "effective_at": "2026-04-01T00:00:00Z" }, "urgency": "critical" } } 1. Infrastructure components receiving this NOTIFY *MUST* immediately terminate all active sessions for the identified subject-agent-id. Session termination *MUST* occur before the next request is processed on the affected session. Hood Expires 27 November 2026 [Page 10] Internet-Draft AGTP-CERT May 2026 2. The target revocation-to-termination latency is 30 seconds. This is materially shorter than standard CRL or OCSP cache-based models. 6.3. Session Manager Responsibilities AGTP Session Managers in deployments using the Agent Certificate Extension *MUST* maintain a per-certificate-serial active session registry. On receiving a revocation NOTIFY, the Session Manager *MUST* terminate all sessions associated with the revoked serial before processing the next request on any affected session. 7. AGTP Certificate Transparency Log 7.1. Purpose The AGTP Certificate Transparency Log (AGTP-CTL) is an append-only, Merkle-tree-based log of all issued AGTP Agent Certificates. It provides tamper-evident public accountability for certificate issuance and revocation, enabling: * Fleet-level analytics: population-wide trust score distributions, archetype frequencies, governance zone composition * Anomaly detection: detection of certificates issued outside normal governance flows * Audit reconstruction: verifiable history of certificate issuance and revocation for compliance 7.2. Log Structure The AGTP-CTL follows the Certificate Transparency log structure defined in [RFC6962], adapted for agent governance metadata. Each leaf entry contains: * Certificate serial number * subject-agent-id * principal-id * governance-zone * trust-tier * archetype Hood Expires 27 November 2026 [Page 11] Internet-Draft AGTP-CERT May 2026 * activation-certificate-id * Issuance timestamp * Revocation status (updated on revocation) * Merkle leaf hash The leaf hash covers all governance metadata fields. Any modification to a log entry is detectable by any party with access to the log. 7.3. Privacy Considerations The principal-id field in the AGTP-CTL leaf entries *MAY* be pseudonymized to protect individual principal identity while maintaining audit integrity. Pseudonymous principal IDs *MUST* be resolvable by authorized parties (regulators, compliance auditors) via a trusted resolution service. The pseudonymization mapping *MUST* be maintained separately from the _*RECOMMENDED_ public log. 8. Security Considerations 8.1. Certificate Pinning Deployments with strict security requirements *MAY* implement certificate pinning for known agents, rejecting connections from agents whose certificate serial or key does not match a pre- registered value. Certificate pinning interacts with renewal; pinned agents *MUST* update pins on each certificate renewal before the old certificate expires. 8.2. Scope Commitment Forgery The authority-scope-commitment extension carries the agent's committed Authority-Scope token list. Integrity of the commitment relies on the certificate's enclosing CA signature: tampering with the extension value invalidates the certificate signature and causes the certificate to be refused by any conforming verifier. Hood Expires 27 November 2026 [Page 12] Internet-Draft AGTP-CERT May 2026 An attacker who compromises the issuing CA key can forge scope commitments by issuing fraudulent certificates with arbitrary extension values. Issuing-key compromise *MUST* trigger immediate revocation of all certificates issued by that key and issuance of replacement certificates from a new key pair. Issuing keys *SHOULD* be stored in hardware security modules. The AGTP Certificate Transparency Log (Section 7), once operating, provides an additional detection surface for unauthorized issuance: a forged certificate that does not appear in the log is detectable by any party that performs log-inclusion checks. 8.3. Cross-Certificate Confusion An agent MAY hold multiple certificates simultaneously. Renewal overlap is one cause; key rotation under a stable Agent Genesis is another. Because the canonical Agent-ID is bound to the Agent Genesis rather than to any specific cert key pair, successive certificates for the same agent *MUST* carry the same value in subject-agent-id and *MAY* carry different public keys. Infrastructure *MUST* use the subject-agent-id extension value as the authoritative agent identifier, not the certificate subject CN, and *MUST NOT* treat key differences across certificates for the same Agent-ID as evidence of an identity mismatch. 8.4. IPR Notice Certain mechanisms described in this document may be subject to pending patent applications by the author, specifically: the authority-scope-commitment mechanism and the session-level revocation propagation architecture. The licensor (Chris Hood / Nomotic, Inc.) is prepared to grant a royalty-free license to implementers for any patent claims covering these mechanisms, consistent with the IETF's IPR framework. 9. IANA Considerations 9.1. X.509 Extension OID Registrations This document requests registration of the following Object Identifiers in an appropriate OID arc for IETF use. Specific OID assignments are subject to IANA allocation. Until IANA allocation is complete, implementations *MUST* use provisional OIDs under the ITU-T UUID arc, derived deterministically by UUIDv5 ([RFC4122]) under a fixed AGTP namespace UUID and the extension's canonical short name. The resulting integer-encoded UUID is appended to the arc prefix 2.25 to form the provisional OID (2.25.{uuid_int}). The derivation is reproducible across Hood Expires 27 November 2026 [Page 13] Internet-Draft AGTP-CERT May 2026 implementations from the extension short name alone, allowing independent implementations to interoperate without a central allocation step. When IANA allocates standards-tree OIDs, those values replace the provisional UUID-derived OIDs in a future revision of this document; relying parties *SHOULD* accept both the provisional and the IANA-allocated OIDs through a transition window declared in that revision. +============================+==========================+==========+ | Extension | OID (provisional / IANA) | Critical | +============================+==========================+==========+ | subject-agent-id | UUIDv5-derived (TBD | Yes | | | allocation) | | +----------------------------+--------------------------+----------+ | principal-id | UUIDv5-derived (TBD | Yes | | | allocation) | | +----------------------------+--------------------------+----------+ | authority-scope-commitment | UUIDv5-derived (TBD | Yes | | | allocation) | | +----------------------------+--------------------------+----------+ | governance-zone | UUIDv5-derived (TBD | No | | | allocation) | | +----------------------------+--------------------------+----------+ | trust-tier | UUIDv5-derived (TBD | No | | | allocation) | | +----------------------------+--------------------------+----------+ | archetype | UUIDv5-derived (TBD | No | | | allocation) | | +----------------------------+--------------------------+----------+ | activation-certificate-id | UUIDv5-derived (TBD | No | | | allocation) | | +----------------------------+--------------------------+----------+ | agtp-ctl-sct | UUIDv5-derived (TBD | No | | | allocation) | | +----------------------------+--------------------------+----------+ Table 2: AGTP Agent Certificate X.509 Extension OIDs 10. References 10.1. Normative References [AGTP] Hood, C., "Agent Transfer Protocol (AGTP)", Work in Progress, Internet-Draft, draft-hood-independent-agtp-08, 2026, . Hood Expires 27 November 2026 [Page 14] Internet-Draft AGTP-CERT May 2026 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally Unique IDentifier (UUID) URN Namespace", RFC 4122, DOI 10.17487/RFC4122, July 2005, . [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., Housley, R., and W. Polk, "Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8555] Barnes, R., Hoffman-Andrews, J., McCarney, D., and J. Kasten, "Automatic Certificate Management Environment (ACME)", RFC 8555, DOI 10.17487/RFC8555, March 2019, . 10.2. Informative References [AGTP-API] Hood, C., "AGTP-API: Verbs, Paths, Endpoints, and Synthesis", Work in Progress, Internet-Draft, draft-hood- agtp-api-01, 2026, . [AGTP-IDENTIFIERS] Hood, C., "AGTP Identifier Stack and Attribution-Record", Work in Progress, Internet-Draft, draft-hood-agtp- identifiers-01, 2026, . [RFC6749] Hardt, D., Ed., "The OAuth 2.0 Authorization Framework", RFC 6749, DOI 10.17487/RFC6749, October 2012, . [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, . Hood Expires 27 November 2026 [Page 15] Internet-Draft AGTP-CERT May 2026 [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, DOI 10.17487/RFC9334, January 2023, . Appendix A. Relationship to Agent Genesis The AGTP Agent Certificate and the Agent Genesis (defined in [AGTP]) are complementary but distinct: +=================+====================+===========================+ | Property | Agent Genesis | Agent Certificate | +=================+====================+===========================+ | Layer | Governance / | Transport / TLS | | | registry | | +-----------------+--------------------+---------------------------+ | Format | JSON document | X.509 v3 | +-----------------+--------------------+---------------------------+ | Issued by | Governance | Governance platform CA | | | platform | | +-----------------+--------------------+---------------------------+ | Lifetime | Permanent | 90 days (renewable) | | | (archived on | | | | revoke) | | +-----------------+--------------------+---------------------------+ | Carries | Full identity + | Transport identity + | | | archetype + scope | scope commitment | +-----------------+--------------------+---------------------------+ | Purpose | Genesis record, | TLS mutual auth, SEP | | | registry anchor | enforcement | +-----------------+--------------------+---------------------------+ | Identifier | Canonical Agent-ID | subject-agent-id | | | (256-bit SHA-256 | extension carries the | | | of canonical Agent | canonical Agent-ID | | | Genesis) | | +-----------------+--------------------+---------------------------+ | Cross-reference | (originating | activation-certificate-id | | to lifecycle | issuance event in | extension | | event | AGTP-LOG) | | +-----------------+--------------------+---------------------------+ Table 3 The subject-agent-id extension carries the canonical Agent-ID (256-bit SHA-256 hash of the canonical Agent Genesis), creating a direct binding between the transport certificate and the governance identity. The activation-certificate-id extension carries a reference to the lifecycle event that activated this certificate, Hood Expires 27 November 2026 [Page 16] Internet-Draft AGTP-CERT May 2026 allowing audit reconstruction back to the activation record without introducing a cryptographic dependency that would force certificate re-issuance whenever the Agent Genesis lifecycle state is updated. Appendix B. Changes from v00 Version 01 is a drift-cleanup revision. The certificate schema, issuance protocol, and revocation propagation mechanisms are unchanged. Clarifications align spec wording with deployed implementation behavior; one normative item (authority-scope- commitment representation) tracks the implementation as the working interpretation and is open to revision. B.1. Substantive Changes The following substantive changes were made: 1. *authority-scope-commitment representation.* The extension value is now defined as the lexicographically sorted, comma-separated, UTF-8-encoded list of Authority-Scope tokens. Integrity is provided by the certificate's enclosing CA signature, not by a separate Ed25519 signature carried in the extension. The earlier detached-signature framing is withdrawn. SEP enforcement parses the token list once per session and checks request tokens by set membership; the operational contract is unchanged for relying parties, only the encoding of the commitment value is changed. 2. *subject-agent-id decoupled from certificate public key; substitution defense moved to application layer.* Earlier drafts implied that the canonical Agent-ID could be derived from the certificate public key and that the TLS layer must refuse certificates whose subject-agent-id disagreed with that derivation. Under the current Agent Genesis taxonomy, the canonical Agent-ID is sha256(canonical_form(Agent_Genesis_without_signature)) and is independent of any specific cert key pair. The subject-agent-id extension is authoritative when present; the cert public key is independent and renewable. The substitution-attack defense is performed at the application layer by retrieving the Agent Genesis (via DISCOVER /genesis per [AGTP-API] or a local registry copy), recomputing the canonical hash, and verifying the Agent Genesis signature against the recognized issuer key. The Cross- Certificate Confusion security consideration is updated accordingly: successive certificates for the same agent *MUST* carry the same subject-agent-id and *MAY* carry different public keys. Hood Expires 27 November 2026 [Page 17] Internet-Draft AGTP-CERT May 2026 3. *Birth Certificate terminology retired.* All references to the Agent Birth Certificate have been replaced by Agent Genesis, matching the locked taxonomy in [AGTP] (Agent Genesis is the permanent signed governance-layer origin document; the canonical Agent-ID is its 256-bit SHA-256 hash; the Agent Certificate is the X.509 v3 transport credential bound to that Agent-ID). The Relationship to Birth Certificate appendix is renamed and rewritten as Relationship to Agent Genesis. 4. *SEP status codes updated to v07 numbering.* Scope Enforcement at SEPs now returns *455 Scope Violation* (previously 451) and adds *457 Zone Violation* for certificates carrying the governance- zone extension when the request's AGTP-Zone-ID header disagrees with the certificate. The status code renumbering propagates the v06 → v07 change in [AGTP]. 5. *SEP enforcement made additive.* A new paragraph in Section 5.2 makes explicit that a certificate without AGTP-specific extensions is a valid TLS client certificate and is enforced through application-layer checks against the Agent Identity Document. Deployments may mix certificates with and without AGTP extensions. 6. *activation-certificate-id semantics clarified.* The field is now defined as a cross-layer reference to the Agent Genesis lifecycle event that activated this certificate, rather than to a certificate_hash field that no longer exists under the locked taxonomy. The relying-party contract is unchanged: a 64-hex value suitable for cross-layer audit reconstruction. 7. *agtp-ctl-sct cryptographic verification deferred.* The extension may be carried and parsed for record-keeping purposes, but verification against an operating AGTP-CTL is deferred to a future revision. The Issuance Protocol is updated to make AGTP- CTL submission and SCT embedding conditional on AGTP-CTL availability. 8. *Provisional OID strategy introduced.* OIDs for the eight extensions are derived deterministically as UUIDv5 values under a fixed AGTP namespace and the extension's canonical short name, placed under the ITU-T UUID arc 2.25.{uuid_int}. This permits independent implementations to interoperate without a central allocation step. The provisional OIDs will be replaced by IANA- allocated standards-tree OIDs in a future revision. 9. *Normative reference to [AGTP] updated to v08.* Section references that pointed at v02 / v06 section numbers (Section 6.2, Section 6.7, Section 6.7.3, Section 8.7) are Hood Expires 27 November 2026 [Page 18] Internet-Draft AGTP-CERT May 2026 removed; cross-references now name the companion document and the concept rather than a specific section number, since section structure in [AGTP] continues to evolve. RFC 4122 added to normative references to support the OID derivation. B.2. Wire Format Compatibility The change to authority-scope-commitment (item 1) is the only wire- format-visible change in this revision. Verifiers that previously expected an Ed25519 signature in the extension value will not parse certificates carrying the sorted-token-list form. v00 issuers and verifiers cannot interoperate with v01 issuers and verifiers without an update. Because no production certificates were issued under the v00 commitment encoding, this revision treats the change as a clarification rather than a breaking transition. All other changes are editorial or specify operational behavior that v00 left unspecified. Author's Address Chris Hood Nomotic, Inc. Email: chris@nomotic.ai URI: https://nomotic.ai Hood Expires 27 November 2026 [Page 19]