Network Working Group R. Burls Internet-Draft Aelethion OU Intended status: Standards Track 19 October 2026 Expires: 22 April 2027 Merkle Tree Agent Certificates (MTAC): A Merkle Tree Certificates Profile for AI Agent Identity draft-burls-mtac-01 Abstract This document profiles Merkle Tree Certificates (MTC) for the identity of AI agents. An MTAC certificate is an MTC whose subject is one AI agent instance, named by a workload identifier in a URI subject alternative name, so that it is also a Workload Identity Certificate. It carries a mandatory non-critical extension naming the sponsor the CA recorded as accountable for the agent, and two optional ones: scopes declared for the agent at issuance, and the model and configuration components the agent is issued for, each graded by how the CA came to record it. The document also defines an audit cosigner role and a procedure by which an auditor, possibly without network access and possibly long after issuance, can establish that a certificate was issued and logged and what it declared. An MTAC certificate identifies an agent. It does not authorize the agent to do anything, and it does not record what the agent did. Records of agent actions can be expressed as signed statements in a transparency service that refer to an MTAC certificate as the acting party. 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." Burls Expires 22 April 2027 [Page 1] Internet-Draft MTAC October 2026 This Internet-Draft will expire on 22 April 2027. 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. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Problem . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Approach . . . . . . . . . . . . . . . . . . . . . . . . 4 1.3. Relationship to the previous version . . . . . . . . . . 5 1.4. What this document does not specify . . . . . . . . . . . 5 2. Conventions and Definitions . . . . . . . . . . . . . . . . . 6 3. Architecture Overview . . . . . . . . . . . . . . . . . . . . 7 4. Certificate Profile . . . . . . . . . . . . . . . . . . . . . 8 4.1. Version . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.2. Subject and agent identifier . . . . . . . . . . . . . . 8 4.3. Subject public key . . . . . . . . . . . . . . . . . . . 9 4.4. Validity . . . . . . . . . . . . . . . . . . . . . . . . 9 4.5. Profile extensions . . . . . . . . . . . . . . . . . . . 9 4.6. Issuance requirements . . . . . . . . . . . . . . . . . . 10 5. Agent Extensions . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Agent Sponsor . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Declared Scopes . . . . . . . . . . . . . . . . . . . . . 11 5.3. Agent Configuration . . . . . . . . . . . . . . . . . . . 12 5.3.1. Configuration epochs . . . . . . . . . . . . . . . . 15 6. Audit Cosigner Role . . . . . . . . . . . . . . . . . . . . . 15 6.1. Statements and obligations . . . . . . . . . . . . . . . 15 6.2. Timestamped checkpoints . . . . . . . . . . . . . . . . . 15 6.3. Independence . . . . . . . . . . . . . . . . . . . . . . 16 6.4. Algorithms . . . . . . . . . . . . . . . . . . . . . . . 16 6.5. Public corroboration . . . . . . . . . . . . . . . . . . 17 7. Proof of Possession . . . . . . . . . . . . . . . . . . . . . 17 8. Verification . . . . . . . . . . . . . . . . . . . . . . . . 17 8.1. Online verification . . . . . . . . . . . . . . . . . . . 18 8.2. Decoding and what may be relied on . . . . . . . . . . . 18 8.3. Audit verification . . . . . . . . . . . . . . . . . . . 19 Burls Expires 22 April 2027 [Page 2] Internet-Draft MTAC October 2026 8.3.1. Inputs . . . . . . . . . . . . . . . . . . . . . . . 19 8.3.2. Procedure . . . . . . . . . . . . . . . . . . . . . . 20 8.3.3. Results . . . . . . . . . . . . . . . . . . . . . . . 21 8.3.4. Offline operation . . . . . . . . . . . . . . . . . . 22 9. Revocation and Suspension . . . . . . . . . . . . . . . . . . 23 10. Relationship to Workload Identity . . . . . . . . . . . . . . 24 11. Relationship to Transparency Services for Agent Actions . . . 25 12. Publication of Issuer Information . . . . . . . . . . . . . . 27 13. Post-Quantum and Long-Term Considerations . . . . . . . . . . 27 13.1. CNSA 2.0 . . . . . . . . . . . . . . . . . . . . . . . . 29 14. Implementation Status . . . . . . . . . . . . . . . . . . . . 29 15. Security Considerations . . . . . . . . . . . . . . . . . . . 30 15.1. Identity is not safety . . . . . . . . . . . . . . . . . 30 15.2. Bearer presentation . . . . . . . . . . . . . . . . . . 30 15.3. Authenticated bytes . . . . . . . . . . . . . . . . . . 30 15.4. Dereferencing, free text and size . . . . . . . . . . . 30 15.5. Sponsor claims . . . . . . . . . . . . . . . . . . . . . 30 15.6. Declared claims . . . . . . . . . . . . . . . . . . . . 31 15.7. Configured cosigner keys . . . . . . . . . . . . . . . . 31 15.8. Trust domain authorization . . . . . . . . . . . . . . . 31 15.9. Cosigner independence . . . . . . . . . . . . . . . . . 31 15.10. Revocation and offline verification . . . . . . . . . . 31 15.11. Key use across protocols . . . . . . . . . . . . . . . . 31 15.12. Key custody . . . . . . . . . . . . . . . . . . . . . . 31 16. Privacy Considerations . . . . . . . . . . . . . . . . . . . 32 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 32 18. References . . . . . . . . . . . . . . . . . . . . . . . . . 33 18.1. Normative References . . . . . . . . . . . . . . . . . . 33 18.2. Informative References . . . . . . . . . . . . . . . . . 34 Appendix A. ASN.1 Module . . . . . . . . . . . . . . . . . . . . 40 Appendix B. Examples . . . . . . . . . . . . . . . . . . . . . . 42 B.1. Agent Sponsor . . . . . . . . . . . . . . . . . . . . . . 42 B.2. Declared Scopes . . . . . . . . . . . . . . . . . . . . . 42 B.3. Agent Configuration . . . . . . . . . . . . . . . . . . . 43 Appendix C. Test Vector . . . . . . . . . . . . . . . . . . . . 43 C.1. The agent . . . . . . . . . . . . . . . . . . . . . . . . 44 C.2. The TBSCertificateLogEntry . . . . . . . . . . . . . . . 44 C.3. The log entry and its hash . . . . . . . . . . . . . . . 45 C.4. A four-entry log . . . . . . . . . . . . . . . . . . . . 45 C.5. Certificate serial number and the signed message . . . . 46 Appendix D. Mapping from the Previous Version . . . . . . . . . 46 Appendix E. Related Work . . . . . . . . . . . . . . . . . . . . 47 Changes from draft-burls-mtac-00 . . . . . . . . . . . . . . . . 49 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 50 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 50 1. Introduction Burls Expires 22 April 2027 [Page 3] Internet-Draft MTAC October 2026 1.1. Problem AI agents increasingly act across organizational boundaries, on behalf of people and of other agents. In this document "agent" means an AI agent as defined in Section 2. After an agent has acted, a relying party, auditor or investigator often needs to determine three things: which agent instance acted, which organization a CA recorded as accountable for it, and what model and configuration were declared for it at the time. They may need to determine this without network access to the issuer, and over a period longer than classical signatures are expected to resist a cryptographically relevant quantum computer. An identity credential does not make an agent safe. An agent whose identity and permissions are all valid can still be induced to misuse access it legitimately holds. Preventing that needs controls on what an agent can reach and do, enforced outside the model, which this document does not specify. It addresses the narrower question those controls leave open: which identifier and declared configuration a CA bound to a key, and when. 1.2. Approach Merkle Tree Certificates [I-D.ietf-plants-merkle-tree-certs] (MTC) define X.509 certificates whose authenticity comes from inclusion in a CA-operated issuance log, cosigned by the CA and optionally by other cosigners, rather than from a per-certificate signature. MTC states that "X.509 extensions apply to Merkle Tree Certificates without any modifications" and that other documents may define cosigner roles. This document uses both extension points and defines no new log, tree, proof or signature format. This document specifies: * a profile of the certificate contents for an AI agent subject, in which the subject is named by a workload identifier [I-D.ietf-wimse-identifier] (Section 4); * three certificate extensions describing the agent (Section 5); * an audit cosigner role (Section 6); * an audit verification procedure for a relying party that verifies a certificate after the fact and possibly offline (Section 8.3); * how an MTAC certificate relates to workload identity credentials (Section 10) and to transparency-service records of agent actions (Section 11). Burls Expires 22 April 2027 [Page 4] Internet-Draft MTAC October 2026 Because an MTAC certificate is an X.509 certificate with exactly one URI subject alternative name carrying a workload identifier, it is also a Workload Identity Certificate as described in [I-D.ietf-wimse-workload-creds]. 1.3. Relationship to the previous version The previous version of this document [I-D.burls-mtac] specified a standalone credential format: a CBOR leaf, a bespoke signed tree head, a bespoke witness note and a bespoke holder commitment. Its stated distinguishing property, issuance by batch, is also the design of MTC, which applies it to any X.509 subject. This version therefore replaces the standalone format with a profile of MTC. Appendix D maps each element of the previous format to its counterpart here. 1.4. What this document does not specify A relying party MUST NOT infer any of the following from a successful verification under this document. * Authorization. Declared scopes (Section 5.2) are recorded at issuance as the requesting party stated them. They are not permissions. This document defines no mechanism by which they constrain an agent, and a relying party MUST NOT treat a declared scope as evidence that the agent operated within it. * Behavior. Verification establishes that a certificate was issued and logged, and what it declared. It does not establish what the agent subsequently did. * Action records. No format for records of agent actions is defined; Section 11 describes how such records can refer to an MTAC certificate. * Runtime attestation. A configuration claim marked as declared (Section 5.3) is a statement made at issuance. It is not evidence that the declared model or configuration was the one that executed. * Authority of the sponsor. The sponsor, capacity and mandate fields (Section 5.1) record what the CA was told and, under its policy, checked. They are not evidence that the sponsor has authority over the agent, that the requester could bind the sponsor, or that the sponsor has any legal duty for the agent. Those are matters for law and for the parties' arrangements. Burls Expires 22 April 2027 [Page 5] Internet-Draft MTAC October 2026 * Presenter identity. Holding the certificate bytes says nothing about the presenter. A proof of possession (Section 7) shows control of the certified key, not that the presenter is the agent named in the certificate. 2. Conventions and Definitions 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, as shown here. This document uses the terms CA, CA ID, issuance log, log entry, cosigner, cosigner ID, subtree, checkpoint, standalone certificate, landmark-relative certificate, MTCProof, TBSCertificateLogEntry and relying party as used in [I-D.ietf-plants-merkle-tree-certs]. AI agent: A workload that iteratively interacts with a large language model or comparable model to decide its actions, following the usage in [I-D.ietf-wimse-aims]. In this document "agent" on its own is shorthand for "AI agent". It never means the node-local credential provisioning component that [I-D.ietf-wimse-arch] also calls an agent. Agent instance: One deployed AI agent, identified by one agent identifier (Section 4.2). Its key and declared configuration can change over time; each change is reflected in a new certificate. MTAC certificate: A Merkle Tree Certificate that conforms to Section 4. Sponsor: The organization or person that requested issuance of an MTAC certificate and that the issuing CA records as accountable for the agent instance. Declared: Stated by the party requesting issuance and recorded by the CA without independent verification. Audit cosigner: A cosigner acting in the role defined in Section 6. Audit: In this document, technical verification carried out after the fact, with the inputs of Section 8.3.1. It does not mean professional assurance or an audit in an accounting or regulatory sense. Audit relying party: A relying party that verifies an MTAC Burls Expires 22 April 2027 [Page 6] Internet-Draft MTAC October 2026 certificate for the purpose of establishing, after the fact, that it was issued and logged and what it declared, using the procedure in Section 8.3. Time of interest: The instant an audit relying party is asking about, for example the time an action attributed to the agent instance took place. 3. Architecture Overview An MTAC deployment has the following parts, each of which is an MTC role unless noted: * An MTC CA with one or more issuance logs, operating a CA cosigner. * One or more audit cosigners (Section 6), which this document defines as an MTC cosigner role. * Agent instances, each holding the private key for its certificate. * Online relying parties, which verify a presented certificate as any MTC relying party does and, where they require it, a proof of possession. * Audit relying parties, which verify a retained certificate after the fact. * Optionally, a transparency service in which signed statements about agent actions are registered (Section 11). This is not part of the profile. The flow is as follows. A sponsor requests a certificate for an agent instance, supplying the agent's public key, its workload identifier and the values for the extensions in Section 5. The CA validates what its policy requires, adds a TBSCertificateLogEntry to its issuance log and, following Section 6.3 of [I-D.ietf-plants-merkle-tree-certs], obtains cosignatures from its CA cosigner and from at least one audit cosigner (Section 4.6). The agent instance receives a standalone certificate. Online relying parties verify it when the agent presents it. An auditor who later holds the certificate, the cosigner keys and the material listed in Section 8.3.1 can verify it without contacting the CA. This document does not change how MTC CAs operate their logs, how cosigners sign, or how certificates are constructed. Burls Expires 22 April 2027 [Page 7] Internet-Draft MTAC October 2026 4. Certificate Profile An MTAC certificate MUST be a Merkle Tree Certificate as specified in [I-D.ietf-plants-merkle-tree-certs], Section 6, whose log entry has type tbs_cert_entry. This document defines no new MTCLogEntryType and no MTCLogEntryExtensionType. The following requirements apply to the TBSCertificateLogEntry and therefore, by Section 6.2 of [I-D.ietf-plants-merkle-tree-certs], to the certificate. 4.1. Version The version MUST be v3, because the profile uses extensions. 4.2. Subject and agent identifier The agent identifier MUST be a workload identifier as defined in Section 4.1 of [I-D.ietf-wimse-identifier]: an absolute URI whose authority component is the trust domain, with no query, fragment, user information or port component. The certificate MUST contain a subjectAltName extension [RFC5280] with exactly one GeneralName of type uniformResourceIdentifier, and that GeneralName is the agent identifier. The certificate MAY contain subjectAltName entries of other types. With these rules the certificate meets the subject naming requirements for a Workload Identity Certificate in Section 6.1 of [I-D.ietf-wimse-workload-creds]. The subject field SHOULD be an empty sequence. When it is empty, the subjectAltName extension MUST be marked critical, as Section 4.2.1.6 of [RFC5280] requires. Relying parties MUST compare agent identifiers as complete URIs, as Section 4.3 of [I-D.ietf-wimse-identifier] requires. An agent identifier names one agent instance. An issuer MUST NOT use the same agent identifier for two agent instances. Several certificates for the same identifier can be valid at once, for example during renewal and key rotation as Section 10.4 of [I-D.ietf-plants-merkle-tree-certs] recommends, or briefly after a configuration change (Section 5.3.1). A relying party therefore MUST determine the key and the declared configuration from the certificate actually presented or referenced, and not from the identifier alone. A CA MUST NOT issue an MTAC certificate for an agent identifier in a trust domain it is not authorized for under its certificate policy. Relying parties MUST bind each trust domain to the CA IDs authorized to issue for it, as Section 3 of [I-D.ietf-wimse-workload-creds] Burls Expires 22 April 2027 [Page 8] Internet-Draft MTAC October 2026 requires of consumers, and MUST reject a certificate whose issuing CA is not authorized for the identifier's trust domain. A relying party MAY enforce the binding by supplying the authorized trust domains as initial-permitted-subtrees (Section 6.1.1 of [RFC5280]) or as trust anchor constraints [RFC5937]. Name constraints placed in an MTC CA certificate are not processed when that certificate is used as a trust anchor. 4.3. Subject public key The subjectPublicKeyInfo carries the agent instance's public key. This document does not restrict its algorithm. Deployments that require post-quantum protection for the agent's own signatures SHOULD use ML-DSA [FIPS204] as specified for X.509 in [RFC9881]. Recommendations for long-lived records are in Section 13. The keyUsage extension, if present, MUST include digitalSignature and MUST NOT include keyCertSign. The basicConstraints extension, if present, MUST NOT assert cA. 4.4. Validity notBefore and notAfter have their [RFC5280] meaning: the period during which the CA vouches for the binding. Issuers SHOULD keep validity short, in line with the guidance in [I-D.ietf-wimse-aims] that agent credentials be short-lived. Because each issuance run costs each cosigner a small constant number of signatures however many certificates it covers (Section 6.3 of [I-D.ietf-plants-merkle-tree-certs]), short validity does not multiply signing cost. It does increase log size and monitoring load (Section 10.1 of that document). An audit relying party evaluates validity against a time of interest, not only against the time of verification. Section 8.3.3 defines how the two are reported. 4.5. Profile extensions An MTAC certificate MUST contain the Agent Sponsor extension and MAY contain the other extensions defined in Section 5. Each of them MUST be marked non-critical. A relying party that does not recognize them is not affected by ignoring them, because none of them grants anything. Burls Expires 22 April 2027 [Page 9] Internet-Draft MTAC October 2026 4.6. Issuance requirements An MTAC CA MUST make the standalone form of every MTAC certificate available to the subject, even when it also issues a landmark- relative form, and MUST include in every standalone MTAC certificate a subtree signature from at least one audit cosigner (Section 6) in addition to its CA cosigner signature. Without one, the certificate cannot pass audit verification (Section 8.3). The material that dates issuance (Section 6.2) is a timestamped checkpoint and a subtree consistency proof, and MTC permits CAs and mirrors to stop serving old entries (Section 10.3 of [I-D.ietf-plants-merkle-tree-certs]). An MTAC CA SHOULD therefore deliver to the subject, as soon as an audit cosigner has signed a timestamped checkpoint covering the certificate, that checkpoint signature and the subtree consistency proof between the certificate's subtree and that checkpoint. Because a CA usually requests a checkpoint cosignature before collecting subtree cosignatures (Section 6.3 of [I-D.ietf-plants-merkle-tree-certs]), such a checkpoint normally exists at issuance. Any party that retains an MTAC certificate for later audit is responsible for retaining this material with it. 5. Agent Extensions The ASN.1 module for these extensions is in Appendix A. Object identifiers are to be assigned by IANA (Section 17). 5.1. Agent Sponsor id-pe-mtacAgentSponsor OBJECT IDENTIFIER ::= { id-pe TBD1 } AgentSponsor ::= SEQUENCE { sponsor GeneralNames, capacity [0] UTF8String (SIZE (1..MAX)) OPTIONAL, mandate [1] IA5String (SIZE (1..MAX)) OPTIONAL, ... } The Agent Sponsor extension names the sponsor: the party that requested the certificate and that the CA records as accountable for the agent instance. It is the one extension every MTAC certificate MUST contain. A relying party that implements this profile recognizes an MTAC certificate by the presence of this extension, and a party that does not implement it treats the certificate as an ordinary Merkle Tree Certificate. Burls Expires 22 April 2027 [Page 10] Internet-Draft MTAC October 2026 sponsor is one or more GeneralNames that all identify the same sponsor, for example one organization by register code and by directory name. It MUST NOT name different parties. A deployment can name the sponsor with whatever identifier its context already uses, for example a directoryName for an organization registered in a legal entity register, a uniformResourceIdentifier, or an rfc822Name. A URI that names an organization by a register code, using a scheme the deployment defines or adopts, is RECOMMENDED where such a register exists, because it is stable and language neutral. This document defines no such scheme. capacity, when present, is text naming the office or role in which the sponsor acts for this agent, for example "authorised signatory". It is declared, not verified, unless the CA's certificate policy states otherwise. mandate, when present, is a URI [RFC3986] that points to an external authorization under which the sponsor acts or acted, for example a signed power of attorney or an entry in a mandate register. MTAC does not store, fetch or evaluate the mandate, and a relying party MUST NOT treat the presence of this field as evidence that any authority exists or that the mandate is valid, current or covers this agent. The URI is recorded in a log that many parties can read: it MUST NOT contain a credential, token, or any value that grants access, and a relying party MUST NOT dereference it automatically. An agent is not a legal person under this document, and nothing in an MTAC certificate gives an agent legal capacity. The sponsor can be a natural person or a legal person; the extension records which one the CA recorded as accountable. Whether and how the law holds that party responsible for the agent is outside this document. The CA MUST validate the sponsor's identity, and SHOULD establish that the requester is entitled to name that sponsor, to the level its certificate policy states before including this extension. This document does not define such a level. A relying party learns from this extension only that the CA, under its own policy, recorded this sponsor as accountable. The names in this extension are not subject to name constraints, which apply only to subject names and subject alternative names. They are not subject alternative names and are not matched as such. Issuers SHOULD name an organization rather than a natural person; see Section 16. 5.2. Declared Scopes Burls Expires 22 April 2027 [Page 11] Internet-Draft MTAC October 2026 id-pe-mtacDeclaredScopes OBJECT IDENTIFIER ::= { id-pe TBD2 } DeclaredScopes ::= SEQUENCE SIZE (1..MAX) OF UTF8String (SIZE (1..MAX)) The Declared Scopes extension records, as text, the operation classes the sponsor declared for the agent instance at issuance. This document defines no vocabulary for the strings; deployments agree on one among themselves. They are intended for an auditor, who can later compare the operation classes the sponsor declared with what the sponsor and agent actually did, using records outside this document. A declaration can go stale; a changed declaration is a new certificate (Section 5.3.1).