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). Declared scopes are not authorization. A relying party MUST NOT treat a declared scope as a permission or as evidence of behavior. In particular, an implementation MUST NOT map a declared scope to an OAuth scope or authorization_details value without a separate authorization decision. The order of the strings has no defined meaning. 5.3. Agent Configuration id-pe-mtacAgentConfiguration OBJECT IDENTIFIER ::= { id-pe TBD3 } AgentConfiguration ::= SEQUENCE SIZE (1..MAX) OF ConfigurationComponent ConfigurationComponent ::= SEQUENCE { role UTF8String (SIZE (1..MAX)), name [0] UTF8String (SIZE (1..MAX)) OPTIONAL, version [1] UTF8String (SIZE (1..MAX)) OPTIONAL, digest [2] ComponentDigest OPTIONAL, reference [3] IA5String (SIZE (1..MAX)) OPTIONAL, source ClaimSource, ... } ComponentDigest ::= SEQUENCE { algorithm AlgorithmIdentifier{DIGEST-ALGORITHM, {DigestAlgorithmSet}}, value OCTET STRING } ClaimSource ::= ENUMERATED { declared (0), issuerVerified (1), attested (2), ... } Burls Expires 22 April 2027 [Page 12] Internet-Draft MTAC October 2026 The Agent Configuration extension records the components declared for, or verified by the CA for, the agent instance: which model, which runtime, which configuration, and optionally which data sets. role names the kind of component. This document defines the following values. Any other value MUST be an absolute URI under the control of the party that defines it, so that independently defined roles do not collide. +=====================+====================================+ | role | meaning | +=====================+====================================+ | model | a model the agent instance invokes | +---------------------+------------------------------------+ | model-weights | the specific weights of a model, | | | normally identified by digest | +---------------------+------------------------------------+ | runtime | the inference or serving runtime | +---------------------+------------------------------------+ | agent-framework | the software that drives the agent | | | loop | +---------------------+------------------------------------+ | system-instructions | the standing instructions given to | | | the model | +---------------------+------------------------------------+ | toolset | the set of tools the agent | | | instance is configured to use | +---------------------+------------------------------------+ | dataset | a data set used to train, tune or | | | ground the agent instance | +---------------------+------------------------------------+ | policy | a policy document the agent | | | instance is configured with | +---------------------+------------------------------------+ Table 1 name and version are human-readable labels. They are informative and SHOULD NOT be the basis of an automated decision on their own. Burls Expires 22 April 2027 [Page 13] Internet-Draft MTAC October 2026 digest, when present, is a cryptographic digest of the component or of a description of it. This document does not define what is digested; that is identified by reference or by a deployment profile. Two parties can compare digests only if they agree on that input. The AlgorithmIdentifier parameters MUST be absent, and the length of value MUST equal the output length of the algorithm, so that each digest has one encoding. The algorithm MUST be one the relying party's policy accepts. The ASN.1 type admits the SHA-2 algorithms of [RFC5912] and is extensible; this document does not choose one. reference, when present, is a URI [RFC3986], following the rules of Section 7.4 of [RFC5280] for URIs in certificates, at which more information about the component can be found, for example an Entity Attestation Token claims set [RFC9711], a model card, or a bill of materials. The CA does not vouch for the content at that URI unless digest covers it. source grades how the CA came to record the component: * declared: the sponsor stated it and the CA recorded it without checking. * issuerVerified: the CA checked it against something under the CA's control or inspection, as described in its certificate policy, before issuance. * attested: the CA appraised remote attestation evidence [RFC9334] for the component before issuance, under a policy its certificate policy states. [I-D.novak-rats-tacra] describes one such issuance flow. A relying party MUST treat a component marked declared as a statement by the sponsor, not as evidence of what executed. A CA MUST NOT mark a component attested on the basis of a name or version string alone. A component marked attested or issuerVerified reflects the CA's appraisal at issuance only. It is not evidence of what ran at any later time, including a time of interest. A relying party that encounters a source value it does not recognize MUST treat the component as declared. This extension does not define a vocabulary for model properties. Deployments that need one SHOULD reference an existing claims format through reference and digest rather than extending this structure. [I-D.palanisamy-scitt-aac-runtime] defines a detailed vocabulary for model, runtime and decoding settings, and also grades each claim by source. Burls Expires 22 April 2027 [Page 14] Internet-Draft MTAC October 2026 5.3.1. Configuration epochs An issuer SHOULD issue a new certificate, with a new serial number, whenever any component in the Agent Configuration extension changes, and SHOULD set notAfter no later than the end of the period for which it expects the configuration to remain unchanged. Where the issuer follows this, the issuance log records when a certificate with a changed declared configuration was issued for an agent identifier. Combined with the certificate actually used at a time of interest (for example the one carried in a signed statement, Section 11), that lets an auditor determine which configuration was declared for that use. It does not show whether the agent instance's decisions were consistent across configurations. When a configuration changes, the earlier certificate may remain valid until it expires; an issuer that needs it to stop being accepted sooner must revoke it. 6. Audit Cosigner Role Section 5.3 of [I-D.ietf-plants-merkle-tree-certs] permits other documents to define cosigner roles. This section defines the audit cosigner role. 6.1. Statements and obligations Every MTC cosigner is already required to keep the subtrees it signs consistent with each other (Section 5.3.2 of [I-D.ietf-plants-merkle-tree-certs]). An audit cosigner obtains that assurance by checking consistency proofs, as a witness does in [TLOG-WITNESS]. An audit cosigner's subtree signatures make no additional statement about the subtree. An audit cosigner has one operational obligation, which it states in its published policy: it retains every checkpoint signature it produces with a non-zero timestamp, and makes them available to audit relying parties, for at least a stated audit retention period. An audit cosigner makes no statement about the content of any log entry. In particular it does not certify agent identifiers, sponsors, scopes or configurations. Those are the CA's statements alone. 6.2. Timestamped checkpoints An audit cosigner SHOULD sign timestamped checkpoints (non-zero timestamp, Section 5.3.1 of [I-D.ietf-plants-merkle-tree-certs]) at an interval stated in its published policy. Burls Expires 22 April 2027 [Page 15] Internet-Draft MTAC October 2026 A timestamped checkpoint from an audit cosigner serves two purposes for an auditor: * It is a high-water mark. An auditor that holds a timestamped checkpoint of size N can detect a later view of the log that is inconsistent with it. * It dates issuance. If an MTAC certificate's log entry is included in a tree that an audit cosigner signed with timestamp T, the entry existed no later than T, independently of any time the certificate itself states. That date rests on the audit cosigner's clock and honesty, since the timestamp is the cosigner's own statement of when it signed. 6.3. Independence An audit cosigner provides a property beyond the CA cosigner only to the extent that it is operated independently of the CA. An audit cosigner SHOULD be operated by a party administratively independent of the CA. A deployment in which the same party operates the CA and the audit cosigner obtains consistency checking without independence, and an audit relying party SHOULD be told which is the case. Each audit cosigner MUST use a cosigner ID distinct from every other cosigner role its operator performs, as Section 5.3 of [I-D.ietf-plants-merkle-tree-certs] requires. 6.4. Algorithms An audit cosigner MUST sign with a post-quantum signature algorithm, because its signatures are what an auditor relies on long after issuance. Where the cosigning protocol in use supports one, an audit cosigner SHOULD use a signature algorithm from a different family than the CA cosigner, for example SLH-DSA where the CA cosigner uses ML-DSA, so that a break of one signature family does not on its own permit forgery of a certificate an auditor accepts. Deployments should note that the cosignature protocol of [TLOG-WITNESS] does not currently define SLH-DSA, and that SLH-DSA signatures are considerably larger than ML-DSA signatures, which works against the size goals of MTC. Section 5.3.3 of [I-D.ietf-plants-merkle-tree-certs] requires a new cosigner ID for any change of key or algorithm, which fixes the algorithm for every signature under a given cosigner ID. Burls Expires 22 April 2027 [Page 16] Internet-Draft MTAC October 2026 6.5. Public corroboration An audit cosigner MAY additionally publish its timestamped checkpoints, or digests of them, to an independent public medium. A value published this way corroborates the checkpoint only. It says nothing about the content of any entry, and the availability and durability of the medium are outside the scope of this document. 7. Proof of Possession An MTAC certificate presented without proof of possession of the subject private key is a bearer presentation: anyone holding the certificate bytes can present it, and a copied certificate is indistinguishable from the original. This document does not define a possession protocol. A relying party that requires proof of possession SHOULD use an existing one in which the subject key signs over a fresh value, for example TLS client authentication with the certificate, or the workload proof mechanisms described in [I-D.ietf-wimse-workload-creds] and [I-D.ietf-wimse-wpt] when used with a WIT backed by the certificate (Section 10). Any such protocol used with an MTAC certificate MUST meet the following: * Freshness. The signed message MUST include either a challenge the relying party generated from a cryptographically secure random source, at least 16 octets long and used once, or a unique identifier that the relying party checks for replay within a bounded acceptance window. * Binding. The relying party MUST associate the result with the agent identifier taken from the verified certificate, not with any identifier the presenter supplies. * Signature. The relying party MUST verify the signature with the certificate's subject public key. [I-D.ietf-wimse-wpt] provides the second form of freshness, through its jti claim, and binds to a WIT rather than directly to a certificate. A successful possession check shows that the presenter controlled the certified private key at presentation. It does not show that the presenter is the agent instance named in the certificate. 8. Verification Burls Expires 22 April 2027 [Page 17] Internet-Draft MTAC October 2026 8.1. Online verification An online relying party performs X.509 path validation as Section 6.1 of [RFC5280] specifies, with the signature verification step replaced by the procedure of Section 7.2 of [I-D.ietf-plants-merkle-tree-certs], under its configuration (Section 7.1 of that document) and cosigner policy (Section 7.3). It then applies the following profile checks: 1. The certificate contains exactly one URI subjectAltName, and that URI conforms to Section 4.1 of [I-D.ietf-wimse-identifier]. 2. The issuing CA is authorized for the trust domain of that identifier (Section 4.2). 3. The Agent Sponsor extension is present, and any extension defined in Section 5 decodes as specified (Section 8.2). A relying party MUST reject a certificate in which such an extension is present but does not decode. Unknown values of an extensible field are not decoding failures. 4. Where the relying party requires it, proof of possession succeeds (Section 7). 8.2. Decoding and what may be relied on The signature verification of Section 7.2 of [I-D.ietf-plants-merkle-tree-certs] authenticates the TBSCertificate fields exactly as they are copied into the log entry. What a relying party then reads from the certificate must be those same authenticated bytes, and nothing else. Accordingly: * A relying party MUST parse the TBSCertificate, and the value of each extension defined in Section 5, with a conforming DER parser, and MUST reject a value that is not valid DER, including values with non-minimal lengths, trailing octets, or any other encoding a DER encoder would not produce for the same abstract value. Where a value contains no content the relying party does not recognize, re-encoding the decoded value with DER MUST reproduce the received octets exactly. A relying party that does not use a conforming DER parser MUST apply the additional checks of Section 12.6 of [I-D.ietf-plants-merkle-tree-certs]. Burls Expires 22 April 2027 [Page 18] Internet-Draft MTAC October 2026 * Every value a relying party reports, records or acts on, including the agent identifier and the contents of every extension in Section 5, MUST be taken from the decoded fields of the TBSCertificate whose signature verification succeeded. It MUST NOT be taken from any other bytes, such as an unverified copy of the certificate, a field supplied alongside it, or a search of the raw encoding. * A relying party MUST NOT compute or verify the entry hash over a re-encoding of only the fields it recognizes. Fields it does not recognize, including unknown additions within an extensible structure, are part of what was authenticated. A relying party MAY disregard their meaning, but when it reports the contents of an extension it MUST indicate that unrecognized content was present rather than presenting the extension as if that content were absent. 8.3. Audit verification This section defines how an audit relying party verifies an MTAC certificate after the fact. 8.3.1. Inputs An audit relying party needs: * The certificate, in standalone form (Section 6.3 of [I-D.ietf-plants-merkle-tree-certs]). A landmark-relative certificate cannot be verified without the landmark material that applied when it was issued, which an auditor may no longer be able to obtain. * An audit configuration: the CA ID, the log hash algorithm, the CA cosigner ID and public key, the IDs and public keys of the audit cosigners it accepts, and the trust domains the CA was authorized for, all as they were when the certificate was issued. These are the items of Section 7.1 of [I-D.ietf-plants-merkle-tree-certs], archived, plus the trust domain binding of Section 4.2. They MUST have been obtained by a means the auditor trusts. Keys taken from the material being audited provide no assurance. * A cosigner policy naming the CA cosigner, which certifies entries, and at least one audit cosigner, which adds consistency checking and dating. None of these cosigners other than the CA cosigner is an issuer. Burls Expires 22 April 2027 [Page 19] Internet-Draft MTAC October 2026 * Revocation information, together with the time at which each part of it was current: archived revoked ranges (Section 7.5 of [I-D.ietf-plants-merkle-tree-certs]) and any other revocation information the CA publishes, such as a CRL. * A time of interest. * Optionally, a timestamped checkpoint signed by an audit cosigner and a subtree consistency proof (Section 4.4 of [I-D.ietf-plants-merkle-tree-certs]) between the certificate's subtree and that checkpoint, to date issuance. A party that retains an MTAC certificate for later audit MUST retain its standalone form, even if it presents a landmark-relative form in protocols that prefer one (for example Section 8.2 of [I-D.ietf-plants-merkle-tree-certs] for TLS). It SHOULD also retain any CRL or OCSP response it obtains that lists the certificate, because a suspension that is later released can no longer be reconstructed. This document does not define a serialization that bundles these inputs. 8.3.2. Procedure 1. Verify the certificate's MTCProof as Section 7.2 of [I-D.ietf-plants-merkle-tree-certs] specifies, under the audit configuration and cosigner policy, using as its revoked ranges those of the audit configuration as they were at issuance (which include the bound on log numbers that Section 12.2.2 of that document relies on, but not later retirement of this certificate), and perform the other path validation checks of Section 6.1 of [RFC5280] except those on validity and revocation. Revocation is evaluated separately in step 4, because a relying party routinely revokes the serial numbers of expired certificates (Section 7.5 of [I-D.ietf-plants-merkle-tree-certs]), which would otherwise make every old certificate fail this step. If this step fails, the result is a failure and no further step applies. 2. Apply profile checks 1 to 3 of the online procedure, and the rules of Section 8.2. 3. Evaluate the validity period against the time of interest and, separately, against the time of verification. Burls Expires 22 April 2027 [Page 20] Internet-Draft MTAC October 2026 4. Evaluate revocation. Report whether the serial number falls in an archived revoked range, and whether other revocation information lists it with a date and reason. A revoked range carries no reason or date, so it cannot distinguish routine retirement of expired serial numbers from revocation for cause; report such a match as "in a revoked range, reason unknown". Record the time at which each piece of revocation information was current. 5. If a timestamped checkpoint and consistency proof are supplied, check that the checkpoint is for the certificate's issuance log and covers the subtree [0, N) for its stated size N, verify its signature under the audit cosigner's key, verify the consistency proof, and record the checkpoint timestamp as the time by which the entry existed. 6. Extract the agent identifier and the contents of each extension in Section 5, including each component's source value. 8.3.3. Results An audit relying party MUST report the outcome of each step separately and in a machine-readable form. It MUST NOT collapse them into a single "valid" result, because they answer different questions: Burls Expires 22 April 2027 [Page 21] Internet-Draft MTAC October 2026 +=================================================+==========+ | Question | Answered | | | by | +=================================================+==========+ | Did this CA issue and log this certificate, | step 1 | | with these contents? | | +-------------------------------------------------+----------+ | Was the time of interest within the | step 3 | | certificate's validity period? | | +-------------------------------------------------+----------+ | Is the certificate within its validity period | step 3 | | now? | | +-------------------------------------------------+----------+ | Does the certificate meet the profile of | step 2 | | Section 4 and decode as Section 8.2 requires? | | +-------------------------------------------------+----------+ | Is the serial number in a revoked range or | step 4 | | listed as revoked, with what date and reason if | | | known, and how current was that information? | | +-------------------------------------------------+----------+ | By what time is the certificate known to have | step 5 | | existed? | | +-------------------------------------------------+----------+ | What did the certificate declare, and how was | step 6 | | each configuration claim graded? | | +-------------------------------------------------+----------+ Table 2 A certificate whose validity period has ended still passes step 1. That result means the certificate was issued and logged with the stated contents. It does not mean the certificate was valid at any particular time, and an implementation MUST NOT present it as current validity. The result of step 1 depends on the CA cosigner and audit cosigners named in the audit configuration. An implementation SHOULD report which cosigners' signatures were verified. 8.3.4. Offline operation Every step of the procedure is local computation over the inputs. An auditor or relying party that operates without network access, for example in an isolated environment, needs the inputs to have been provisioned before it was disconnected. Burls Expires 22 April 2027 [Page 22] Internet-Draft MTAC October 2026 Revocation is the input most affected. A verifier without fresh revocation information cannot know about revocations made since its information was current. A deployment that verifies offline MUST state its policy, either to fail when revocation information is older than a stated bound or to accept with a stated bound, and a verifier MUST report the time at which the revocation information it used was current. 9. Revocation and Suspension This section states what this profile provides for ending an agent's identity, and what it does not. An MTAC certificate stops being accepted by a relying party through one of these mechanisms: * Expiry. The validity period ends. Issuers SHOULD keep validity short (Section 4.4), because expiry is the one mechanism that works for every relying party, including those that are offline. It is also the bound on the delay for a relying party that applies no other mechanism: such a party continues to accept an unwanted certificate until notAfter. * CRL and OCSP. Existing mechanisms apply to Merkle Tree Certificates unchanged (Section 12.7 of [I-D.ietf-plants-merkle-tree-certs]). They carry a revocation time and a reason. * Revoked serial number ranges. A relying party's configuration includes revoked ranges (Section 7.5 of [I-D.ietf-plants-merkle-tree-certs]), which it can extend from out-of-band information. Serial numbers are assigned in log order, so a range can disable a run of certificates or a whole log. A range carries no reason and no date. MTC defines no way for a CA to publish ranges; a deployment needs to supply one. How quickly each takes effect depends on how often the relying party obtains the information. An MTAC CA SHOULD publish a revocation policy stating which mechanisms it operates, how often it publishes, and the worst-case delay between a decision to revoke and publication. A relying party that needs prompt effect MUST obtain revocation information more often than the delay it can accept, or rely on short validity. Reasons. When a CA revokes through a CRL or OCSP it SHOULD use the reason codes of [RFC5280] with these meanings in this profile: Burls Expires 22 April 2027 [Page 23] Internet-Draft MTAC October 2026 * keyCompromise: the agent's key may be exposed. invalidityDate is set to the earliest time the CA believes this to be so. * affiliationChanged: the sponsor no longer stands as the recorded party, for example because the sponsor ended the mandate or ceased to exist. * superseded: a replacement certificate has been issued, including for a changed configuration (Section 5.3.1). * cessationOfOperation: the agent instance has been retired. * certificateHold: suspension, which is reversible. In a complete CRL the entry is omitted from later lists; in a delta CRL it is removed with removeFromCRL (Section 5.3.1 of [RFC5280]); an OCSP responder reports the certificate as good again. Revoking or suspending a certificate ends only the identity it carried. It does not withdraw any authority the sponsor granted to the agent elsewhere, and it does not undo anything the agent did. This document defines no status protocol of its own. An audit relying party can see only the revocation information it holds (Section 8.3). In particular, a suspension that was later released leaves no trace in later complete CRLs, and the interval between a key compromise and its revocation is visible only if invalidityDate was set and the relevant CRL was archived. 10. Relationship to Workload Identity This section is informative. [I-D.ietf-wimse-aims] treats AI agents as workloads, requires each to have exactly one workload identifier, and names the Workload Identity Token (WIT) and the Workload Identity Certificate (WIC) of [I-D.ietf-wimse-workload-creds] as credential formats, noting that the choice depends on the deployment's trust model. An MTAC certificate is a WIC: an X.509 certificate with the workload identifier in exactly one URI subject alternative name. It is one way to issue a WIC, adding issuance transparency, audit cosigners and the agent extensions. It does not replace the WIT. A deployment that uses WITs can back them with an MTAC certificate. An identity server that issues a WIT for an agent instance holding an MTAC certificate can set the WIT sub to the certificate's agent identifier, set cnf.jwk to the certificate's subject public key (for an ML-DSA key, in the form [RFC9964] defines), and set the WIT expiry no later than the certificate's notAfter. A relying party can then Burls Expires 22 April 2027 [Page 24] Internet-Draft MTAC October 2026 check that the WIT and the certificate name the same identifier and key. The WIT's own signature algorithm is chosen independently, so a deployment that needs post-quantum protection end to end needs a post-quantum WIT signature as well. Interoperability is a further constraint: [I-D.ietf-wimse-workload-creds] requires general purpose implementations to support ES256, not ML-DSA, so a general purpose WIT verifier need not accept an ML-DSA key in cnf.jwk. An MTAC certificate could be presented as a subject_token or actor_token in OAuth Token Exchange [RFC8693] or as input to a Transaction Token service [I-D.ietf-oauth-transaction-tokens]. Defining the token type for that is left to a future version. [I-D.ni-wimse-ai-agent-identity] describes binding an AI agent to an accountable owner. The Agent Sponsor extension (Section 5.1) is one way to carry that binding in a certificate. 11. Relationship to Transparency Services for Agent Actions This section is informative. Records of agent actions are a separate layer from identity. Several documents define such records as signed statements registered in a transparency service following [RFC9943], for example [I-D.mih-scitt-agent-action-capsule], [I-D.emirdag-scitt-ai-agent-execution] and [I-D.noa-scitt-ai-agent-receipt]. They generally leave open how a verifier relates the signing key to an agent identifier. An MTAC certificate supplies the CA's binding between the signing key and an agent identifier, without new registrations. It does not show which software produced a given signature. * The agent instance signs the statement with its certified private key. The signature shows that the statement was signed with the certified key. It is not a fresh proof of possession in the sense of Section 7. * The protected header carries the MTAC certificate in x5chain, or identifies it with x5t and carries it in x5chain in the unprotected header, as [RFC9360] defines and [RFC9943], Section 5.1.1.1, permits for X.509 signed statements. Because the same MTC certificate can carry different MTCProof values (Section 12.6 of [I-D.ietf-plants-merkle-tree-certs]), statements cannot be correlated reliably by x5t; correlating them by CA ID and serial number, or by agent identifier, avoids this. Burls Expires 22 April 2027 [Page 25] Internet-Draft MTAC October 2026 * The CWT claims header carries iss equal to the certificate's agent identifier, which satisfies the requirement of [RFC9943], Section 6, that iss be a URI when x5chain is used. sub identifies the artifact the statement is about, and iat is the signing time. A verifier then verifies the statement's signature with the certificate's subject key, checks that iss equals the agent identifier, checks the transparency service receipt as [RFC9942] specifies, and verifies the certificate as in Section 8.3. The time of interest is the registration time, where the transparency service states one in a signed claim of the Receipt (for example iat; [RFC9942], Section 7.2, describes optional time claims in Receipts). That time rests on the transparency service's clock and honesty. The statement's own iat is set by the key holder, who can set it to any value, so it is only a claim; a verifier reports any difference from the registration time beyond a stated tolerance. Where no signed registration time is available, a verifier reports that it has no time of interest it can rely on, rather than falling back to the statement's iat. Registration can use the interface defined in [I-D.ietf-scitt-scrapi]. Section 5.1.1.1 of [RFC9943] requires a transparency service that accepts X.509 signed statements to build and validate a certification path from the issuer's certificate to a trust anchor it has registered. A transparency service can therefore accept statements identified this way only if it can verify Merkle Tree Certificates and has the MTAC CA registered as a trust anchor, which [RFC9943] also requires to be made transparent by registering it as a signed statement. The audit cosigners' public keys can be registered the same way. Records need not be SCITT statements. [I-D.gilda-audit-agent-audit-record], for example, defines an audit record for agent authorization decisions with an agent.id that carries a WIMSE identifier and an agent.credentialDigest that is the digest of the credential the identifier was read from. For an agent holding an MTAC certificate, agent.id can be the certificate's agent identifier, and the credential digest can be computed over the DER encoding of the TBSCertificate, which is not malleable, rather than over the whole certificate, whose MTCProof is (Section 12.6 of [I-D.ietf-plants-merkle-tree-certs]). The hash algorithm is the one that record format specifies. A reader of such a record can then retrieve the certificate, verify it as in Section 8.3, and see which party the CA recorded as accountable for the agent and what was declared for it. Burls Expires 22 April 2027 [Page 26] Internet-Draft MTAC October 2026 An MTC proof is not a COSE Receipt. An MTCProof proves inclusion in a subtree under the signatures of cosigners, while a Receipt [RFC9942] proves inclusion in a tree under the transparency service's own signature. In particular, [RFC9942] requires at least one inclusion path element, so the empty path of a one-entry tree cannot be carried as a Receipt. 12. Publication of Issuer Information This section is informative. A relying party needs the configuration of Section 7.1 of [I-D.ietf-plants-merkle-tree-certs] for each MTAC CA it accepts: the CA ID, the log hash algorithm, the CA cosigner and audit cosigner keys, the cosigner policy, and revocation information. This profile adds one more item, the trust domains the CA is authorized for (Section 4.2). Much of this information is also carried by the CA certificate structure of Section 5.5 of [I-D.ietf-plants-merkle-tree-certs], which a registry can publish directly. A national, sectoral or organizational registry can list MTAC CAs, publishing that configuration together with the CA's certificate policy and revocation policy, so that relying parties obtain it from a place they already trust and an auditor can later retrieve the configuration as it stood at a past time. Such a registry decides which CAs it lists and on what basis. Any legal or regulatory status of a CA derives from its listing, not from an MTAC certificate. The format and operation of a registry are outside the scope of this document. 13. Post-Quantum and Long-Term Considerations [I-D.uppalapati-wimse-pq-agent-identity] states requirements PQ-R1 to PQ-R7 for post-quantum agent identity and observes that the previous version of this document addressed issuance only. This section states how this profile relates to each requirement. It does not claim conformance to that document, which is itself an individual draft. PQ-R1 (algorithm agility): Nothing in this profile fixes an algorithm. The subject key's algorithm is explicit in the subjectPublicKeyInfo. Cosigner algorithms are identified only by reference: the MTCProof carries cosigner IDs, and the algorithm for each comes from the relying party's configuration (Section 5.3.3 of [I-D.ietf-plants-merkle-tree-certs]). The MTCProof therefore does not meet PQ-R1's requirement for an explicit algorithm identifier in the credential. Relying parties Burls Expires 22 April 2027 [Page 27] Internet-Draft MTAC October 2026 MUST be able to accept cosigners with different algorithms concurrently. A deployment that wants hybrid protection for subject keys can use composite signatures [I-D.ietf-lamps-pq-composite-sigs]. PQ-R2 (post-quantum issuance for retained credentials): MTAC certificates are intended to be retained for later audit (Section 8.3.1). Their authenticity rests on cosigner signatures. Section 6 requires audit cosigners to sign with a post-quantum algorithm. A deployment that needs post-quantum protection for the whole path MUST also use a post-quantum CA cosigner. PQ-R3 (non-separable delegation binding): An MTAC certificate is a single credential, not a delegation chain. Where it is an input to a chain, the chain mechanism is responsible for this requirement. PQ-R4 (trust anchor precedence): The keys a relying party is configured with are the CA cosigner key and the audit cosigner keys. A deployment that issues MTAC certificates under post- quantum cosigners from the start never has a classical cosigner key to retire. Any change of cosigner algorithm requires a new cosigner ID, so relying parties stop accepting an old key by removing it from their configuration. This profile does not state a migration order or a cut-off date, which PQ-R4 asks a specification to state. PQ-R5 (downgrade resistance): A relying party's cosigner configuration (Section 7.1 of [I-D.ietf-plants-merkle-tree-certs]) fixes which keys and algorithms it accepts. A relying party MUST NOT derive acceptable algorithms from the certificate. PQ-R6 (chain strength visibility): A standalone MTAC certificate carries its own binding to the cosigner keys its relying parties are configured with: the inclusion proof and the cosignatures. The standalone certificate carries that binding, so it is retained with the certificate. PQ-R7 (audit record longevity): The audit cosigners' timestamped checkpoints and their retention obligation (Section 6) provide post-quantum anchoring of the certificate, where the audit cosigner has signed a timestamped checkpoint covering it, dated by the checkpoint, and witnessed independently when the audit cosigner is independent of the CA. Family diversity between the CA cosigner and an audit cosigner does not meet PQ-R7's recommendation of two separate protections that share neither a hash function nor an authority, because both cosigners sign the same SHA-256 subtree hash within one structure. This profile does Burls Expires 22 April 2027 [Page 28] Internet-Draft MTAC October 2026 not define renewal of protection over time, and it does not address the retention of action records, which is the responsibility of whatever system holds them. 13.1. CNSA 2.0 MTAC certificates cannot conform to the Commercial National Security Algorithm Suite 2.0 profile for certificates [I-D.jenkins-cnsa2-pkix-profile]. That profile requires the signature on every certificate to be made with ML-DSA-87, whereas the signature of an MTC certificate is an MTCProof identified by id-alg- mtcProof. It also requires SHA-384 or SHA-512 for other hashing, and a critical keyUsage extension, an extended key usage extension and an authority key identifier in end-entity certificates. ML-DSA-87 can be used for subject keys and cosigners, since this profile fixes none of those algorithms, but conformance would need a CNSA profile that admits MTC proofs; choosing a SHA-384 log hash would not be enough. SLH-DSA, the example of a different signature family given in Section 6, is not a CNSA 2.0 algorithm. The hash-based algorithms CNSA 2.0 does list, LMS and XMSS, are stateful, and no cosignature protocol currently defines them. 14. Implementation Status This section is to be removed before publication as an RFC, per [RFC7942]. There is no implementation of this version of the profile. The author's existing software implements the standalone format of the previous version [I-D.burls-mtac], in which the name "MTAC" referred to that format, and is not a conforming implementation of this version or a reference for its requirements. A Python library for verifying that format is published under the Apache-2.0 license as aegis-verifier; its current release is 0.1.4, of 2026-10-14. The issuing and verifying tool is not publicly available at the time of writing. An MTAC deployment is expected to reuse MTC CA, log and cosigner software rather than reimplement it. The author intends to publish a reference implementation of this profile under an open source license, and welcomes independent implementations. Interoperability between at least two independent implementations, using the vectors in Appendix C, is a precondition the author applies before asking for further progress of this document. Burls Expires 22 April 2027 [Page 29] Internet-Draft MTAC October 2026 15. Security Considerations 15.1. Identity is not safety An MTAC certificate identifies an agent instance and records what was declared about it. An agent with a valid certificate can still be induced to misuse its access. Nothing in this document reduces that risk, and a deployment that treats an MTAC certificate as a control on behavior is relying on something this document does not provide. 15.2. Bearer presentation Without proof of possession (Section 7), presentation of an MTAC certificate is bearer presentation. Relying parties that need to know the presenter controls the certified key MUST require proof of possession explicitly. 15.3. Authenticated bytes A verifier that authenticates one encoding of a certificate but reads its claims from another, for example by hashing a re-encoding of the fields it recognizes, or by searching raw octets for a value, can be made to accept content that was never certified while the signatures still verify. Section 8.2 requires strict DER decoding and requires every reported or acted-on value to come from the authenticated fields. 15.4. Dereferencing, free text and size The mandate and reference fields contain URIs. A relying party MUST NOT dereference them automatically, because doing so lets a certificate request cause network access from the relying party, and the resource can change after issuance. Free text fields (name, version, capacity, declared scopes) can contain characters, including bidirectional controls, that make displayed text differ from what was recorded; relying parties SHOULD display such text with controls neutralized and SHOULD NOT use it in access decisions. Because an MTC log entry has a size limit (Section 5.2.1 of [I-D.ietf-plants-merkle-tree-certs]) and the log is append-only, CAs SHOULD bound the size and number of the strings and components they accept. 15.5. Sponsor claims A CA that does not establish that a requester is entitled to name a sponsor can be used to create a certificate that appears to be sponsored by a party that never agreed to it. The certificate policy of the CA is what a relying party relies on here. Burls Expires 22 April 2027 [Page 30] Internet-Draft MTAC October 2026 15.6. Declared claims Declared scopes and components marked declared are statements by the sponsor that the CA did not check (Section 5.2, Section 5.3). Treating them as evidence of behavior or of what executed is an error. 15.7. Configured cosigner keys A relying party's configuration names the CA cosigner key, which certifies entries, and any audit cosigner keys, which add consistency checking and dating. A verifier that takes any of these keys from the material it is verifying gains no assurance, because an adversary who supplies a substituted key can supply matching signatures. Audit relying parties need archived keys obtained by a trusted means. 15.8. Trust domain authorization A relying party that skips the trust domain check of Section 4.2 gives every CA it accepts authority over every trust domain. 15.9. Cosigner independence An audit cosigner operated by the same party as the CA does not protect against that party. Audit relying parties SHOULD know which cosigners are independent of the CA and SHOULD require at least one that is. 15.10. Revocation and offline verification A verifier without fresh revocation information can accept a certificate that has since been revoked; see Section 8.3.4. 15.11. Key use across protocols If an agent instance uses its certified key in more than one protocol, for example TLS and COSE, the separation between those uses rests on each protocol's own domain separation. Deployments MAY issue separate certificates for separate key uses. 15.12. Key custody The value of an MTAC certificate depends on the protection of the CA cosigner, audit cosigner and agent keys. This document does not specify key protection. Deployments SHOULD protect CA and cosigner private keys in hardware security modules or equivalent. Burls Expires 22 April 2027 [Page 31] Internet-Draft MTAC October 2026 16. Privacy Considerations MTC issuance logs are intended to be observable by monitors. An MTAC issuance log therefore reveals the agent identifiers, sponsors, declared scopes and configuration components of every agent instance a CA certifies, and when each changed. Deployments SHOULD consider this before including sponsor names, configuration details or data set identifiers. A sponsor named as a natural person, for example by an email address, puts personal data into an append-only log that is designed to be monitored and from which entries cannot be removed, which can conflict with rights of erasure; issuers SHOULD name organizations instead. Issuers SHOULD NOT include personal data of a third party who has not agreed to it in the capacity or mandate fields, in agent identifier paths or in register codes. The mandate URI and the references in the Agent Configuration extension can also disclose the existence and location of internal documents. A deployment can limit what it reveals by using digests rather than names in the Agent Configuration extension, by omitting optional extensions, or by operating logs that are visible only to a limited set of monitors, at the cost of reducing what those outside that set can audit. The privacy considerations of [I-D.ietf-plants-merkle-tree-certs] also apply. 17. IANA Considerations IANA is requested to make the following assignments in the "SMI Security for PKIX Certificate Extension" registry (1.3.6.1.5.5.7.1): +=========+==============================+===============+ | Decimal | Description | References | +=========+==============================+===============+ | TBD1 | id-pe-mtacAgentSponsor | this document | +---------+------------------------------+---------------+ | TBD2 | id-pe-mtacDeclaredScopes | this document | +---------+------------------------------+---------------+ | TBD3 | id-pe-mtacAgentConfiguration | this document | +---------+------------------------------+---------------+ Table 3 IANA is requested to make the following assignment in the "SMI Security for PKIX Module Identifier" registry (1.3.6.1.5.5.7.0): Burls Expires 22 April 2027 [Page 32] Internet-Draft MTAC October 2026 +=========+==================+===============+ | Decimal | Description | References | +=========+==================+===============+ | TBD0 | id-mod-mtac-2026 | this document | +---------+------------------+---------------+ Table 4 This document requests no MTC log entry type or log entry extension type. 18. References 18.1. Normative References [I-D.ietf-plants-merkle-tree-certs] Benjamin, D., O'Brien, D., Westerbaan, B., Valenta, L., and F. Valsorda, "Merkle Tree Certificates", Work in Progress, Internet-Draft, draft-ietf-plants-merkle-tree- certs-07, 7 October 2026, . [I-D.ietf-wimse-identifier] Rosomakho, Y. and J. A. Salowey, "Workload Identifier", Work in Progress, Internet-Draft, draft-ietf-wimse- identifier-03, 6 July 2026, . [I-D.ietf-wimse-workload-creds] Campbell, B., Salowey, J. A., Schwenkschuster, A., Sheffer, Y., and Y. Rosomakho, "WIMSE Workload Credentials", Work in Progress, Internet-Draft, draft- ietf-wimse-workload-creds-02, 2 July 2026, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . Burls Expires 22 April 2027 [Page 33] Internet-Draft MTAC October 2026 [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, . [RFC5912] Hoffman, P. and J. Schaad, "New ASN.1 Modules for the Public Key Infrastructure Using X.509 (PKIX)", RFC 5912, DOI 10.17487/RFC5912, June 2010, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC9881] Massimo, J., Kampanakis, P., Turner, S., and B. E. Westerbaan, "Internet X.509 Public Key Infrastructure -- Algorithm Identifiers for the Module-Lattice-Based Digital Signature Algorithm (ML-DSA)", RFC 9881, DOI 10.17487/RFC9881, October 2025, . 18.2. Informative References [FIPS204] National Institute of Standards and Technology, "Module- Lattice-Based Digital Signature Standard", FIPS 204, DOI 10.6028/NIST.FIPS.204, 13 August 2024, . [I-D.burls-mtac] Burls, R., "Merkle Tree Agent Certificates (MTAC): Batch- Issued Post-Quantum Identity Credentials for AI Agents", Work in Progress, Internet-Draft, draft-burls-mtac-00, 21 July 2026, . [I-D.coetzee-oauth-spt-txn-tokens] Coetzee, R. J., "Transaction-Bound Authorization Tokens for Software and AI Agents (SPT-Txn)", Work in Progress, Internet-Draft, draft-coetzee-oauth-spt-txn-tokens-03, 19 July 2026, . Burls Expires 22 April 2027 [Page 34] Internet-Draft MTAC October 2026 [I-D.elkins-plants-enterprise-mtc-deployment] Elkins, N. and M. ackermann, "Enterprise Deployment Considerations for Standalone Merkle Tree Certificates", Work in Progress, Internet-Draft, draft-elkins-plants- enterprise-mtc-deployment-00, 17 October 2026, . [I-D.emirdag-scitt-ai-agent-execution] Emirdag, P. and D. Feichtinger, "AI Agent Execution Profile of SCITT", Work in Progress, Internet-Draft, draft-emirdag-scitt-ai-agent-execution-01, 12 October 2026, . [I-D.fane-opena2a-aip] Fane, A., "OpenA2A Agent Identity Protocol (AIP)", Work in Progress, Internet-Draft, draft-fane-opena2a-aip-04, 6 October 2026, . [I-D.gilda-audit-agent-audit-record] Gilda, S., "An Audit Record Format for AI Agent Authorization Decisions", Work in Progress, Internet- Draft, draft-gilda-audit-agent-audit-record-00, 16 October 2026, . [I-D.gray-plants-mtc-deploy-use-cases] Gray, J., Klaußner, J., T, L., and G. Mallaya, "Merkle Tree Certificates Deployment Use Cases", Work in Progress, Internet-Draft, draft-gray-plants-mtc-deploy-use-cases-01, 2 September 2026, . [I-D.ietf-lamps-pq-composite-sigs] Ounsworth, M., Gray, J., Pala, M., Klaußner, J., and S. Fluhrer, "Composite Module-Lattice-Based Digital Signature Algorithm (ML-DSA) for use in X.509 Public Key Infrastructure", Work in Progress, Internet-Draft, draft- ietf-lamps-pq-composite-sigs-19, 21 April 2026, . Burls Expires 22 April 2027 [Page 35] Internet-Draft MTAC October 2026 [I-D.ietf-oauth-transaction-tokens] Tulshibagwale, A., Fletcher, G., and P. Kasselman, "Transaction Tokens", Work in Progress, Internet-Draft, draft-ietf-oauth-transaction-tokens-11, 30 July 2026, . [I-D.ietf-scitt-scrapi] Birkholz, H., Geater, J., and A. Delignat-Lavaud, "Supply Chain Integrity, Transparency, and Trust (SCITT) Reference APIs", Work in Progress, Internet-Draft, draft-ietf-scitt- scrapi-11, 26 June 2026, . [I-D.ietf-stir-certificate-transparency] Wendt, C., Śliwa, R., Fenichel, A., and V. A. Gaikwad, "STI Certificate Transparency", Work in Progress, Internet-Draft, draft-ietf-stir-certificate-transparency- 04, 17 August 2026, . [I-D.ietf-wimse-aims] Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Identity Management System", Work in Progress, Internet-Draft, draft-ietf- wimse-aims-00, 15 September 2026, . [I-D.ietf-wimse-arch] Salowey, J. A., Rosomakho, Y., and H. Tschofenig, "Workload Identity in a Multi System Environment (WIMSE) Architecture", Work in Progress, Internet-Draft, draft- ietf-wimse-arch-08, 6 July 2026, . [I-D.ietf-wimse-wpt] Campbell, B. and A. Schwenkschuster, "WIMSE Workload Proof Token", Work in Progress, Internet-Draft, draft-ietf- wimse-wpt-02, 27 August 2026, . Burls Expires 22 April 2027 [Page 36] Internet-Draft MTAC October 2026 [I-D.izmaylov-agent-permission-receipts] Izmaylov, P., "Signed Permissions and Action Receipts for Automated Agents", Work in Progress, Internet-Draft, draft-izmaylov-agent-permission-receipts-00, 7 October 2026, . [I-D.jenkins-cnsa2-pkix-profile] Jenkins, M. J., "Commercial National Security Algorithm (CNSA) Suite 2.0 Profile for Certificates and Certificate Revocation Lists", Work in Progress, Internet-Draft, draft-jenkins-cnsa2-pkix-profile-05, 5 July 2026, . [I-D.kuehlewind-audit-architecture] Kühlewind, M. and H. Birkholz, "An Architecture for Auditing Agent Delegation and Interactions", Work in Progress, Internet-Draft, draft-kuehlewind-audit- architecture-01, 7 September 2026, . [I-D.maintainer-1f916-agent-record] Maintainer, 1., "The Agent Record: Transparent, Witness- Countersigned Event Logs for AI Agent Identity, History, and Memory", Work in Progress, Internet-Draft, draft- maintainer-1f916-agent-record-01, 12 August 2026, . [I-D.mih-scitt-agent-action-capsule] Mih, S., "An Agent Action Capsule Profile for SCITT", Work in Progress, Internet-Draft, draft-mih-scitt-agent-action- capsule-05, 26 September 2026, . [I-D.ni-wimse-ai-agent-identity] Yuan, N., Liu, P. C., and M. Richardson, "WIMSE Applicability for AI Agents", Work in Progress, Internet- Draft, draft-ni-wimse-ai-agent-identity-03, 30 September 2026, . [I-D.noa-scitt-ai-agent-receipt] Toraman, T., "A SCITT Profile for AI-Agent Action Receipts", Work in Progress, Internet-Draft, draft-noa- Burls Expires 22 April 2027 [Page 37] Internet-Draft MTAC October 2026 scitt-ai-agent-receipt-01, 14 August 2026, . [I-D.novak-rats-tacra] Novak, M., Richardson, M., and H. Birkholz, "Trustworthy Acquisition of Credentials via Remote Attestation", Work in Progress, Internet-Draft, draft-novak-rats-tacra-01, 11 September 2026, . [I-D.palanisamy-scitt-aac-runtime] Palanisamy, G. and S. Mih, "The model_attestation Block for Agent Action Capsules: Model, Runtime, and Hardware Claims", Work in Progress, Internet-Draft, draft- palanisamy-scitt-aac-runtime-00, 2 October 2026, . [I-D.sharif-apki-agent-pki] Sharif, R., "Agent Public Key Infrastructure (APKI): Certificate-Based Identity and Trust for Autonomous AI Agents", Work in Progress, Internet-Draft, draft-sharif- apki-agent-pki-01, 27 August 2026, . [I-D.sharif-x509-agent-identity-profile] Sharif, R., "X.509 Certificate Profile for Autonomous AI Agent Identity", Work in Progress, Internet-Draft, draft- sharif-x509-agent-identity-profile-04, 2 October 2026, . [I-D.uppalapati-wimse-pq-agent-identity] Uppalapati, V. K., "Post-Quantum Requirements for Software and AI Agent Identity", Work in Progress, Internet-Draft, draft-uppalapati-wimse-pq-agent-identity-00, 28 September 2026, . [RFC5937] Ashmore, S. and C. Wallace, "Using Trust Anchor Constraints during Certification Path Processing", RFC 5937, DOI 10.17487/RFC5937, August 2010, . Burls Expires 22 April 2027 [Page 38] Internet-Draft MTAC October 2026 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running Code: The Implementation Status Section", BCP 205, RFC 7942, DOI 10.17487/RFC7942, July 2016, . [RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J., and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693, DOI 10.17487/RFC8693, January 2020, . [RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, . [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, . [RFC9360] Schaad, J., "CBOR Object Signing and Encryption (COSE): Header Parameters for Carrying and Referencing X.509 Certificates", RFC 9360, DOI 10.17487/RFC9360, February 2023, . [RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C. Wallace, "The Entity Attestation Token (EAT)", RFC 9711, DOI 10.17487/RFC9711, April 2025, . [RFC9942] Steele, O., Birkholz, H., Delignat-Lavaud, A., and C. Fournet, "CBOR Object Signing and Encryption (COSE) Receipts", RFC 9942, DOI 10.17487/RFC9942, June 2026, . [RFC9943] Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, . [RFC9964] Prorock, M. and O. Steele, "ML-DSA for JSON Object Signing and Encryption (JOSE) and CBOR Object Signing and Encryption (COSE)", RFC 9964, DOI 10.17487/RFC9964, May 2026, . [TLOG-WITNESS] C2SP, "Transparency Log Witness Protocol", October 2026, . Burls Expires 22 April 2027 [Page 39] Internet-Draft MTAC October 2026 Appendix A. ASN.1 Module This module uses the ASN.1 conventions and imports the modules of [RFC5912]. MTAC-2026 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-mtac-2026(TBD0) } DEFINITIONS IMPLICIT TAGS ::= BEGIN IMPORTS EXTENSION FROM PKIX-CommonTypes-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkixCommon-02(57) } AlgorithmIdentifier{}, DIGEST-ALGORITHM FROM AlgorithmInformation-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-algorithmInformation-02(58) } mda-sha256, mda-sha384, mda-sha512 FROM PKIX1-PSS-OAEP-Algorithms-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-rsa-pkalgs-02(54) } id-pe FROM PKIX1Explicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-explicit-02(51) } GeneralNames FROM PKIX1Implicit-2009 { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7) id-mod(0) id-mod-pkix1-implicit-02(59) } ; MTACExtensions EXTENSION ::= { ext-mtacAgentSponsor | ext-mtacDeclaredScopes | ext-mtacAgentConfiguration, Burls Expires 22 April 2027 [Page 40] Internet-Draft MTAC October 2026 ... } -- Agent Sponsor ext-mtacAgentSponsor EXTENSION ::= { SYNTAX AgentSponsor IDENTIFIED BY id-pe-mtacAgentSponsor CRITICALITY { FALSE } } 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, ... } -- Declared Scopes ext-mtacDeclaredScopes EXTENSION ::= { SYNTAX DeclaredScopes IDENTIFIED BY id-pe-mtacDeclaredScopes CRITICALITY { FALSE } } id-pe-mtacDeclaredScopes OBJECT IDENTIFIER ::= { id-pe TBD2 } DeclaredScopes ::= SEQUENCE SIZE (1..MAX) OF UTF8String (SIZE (1..MAX)) -- Agent Configuration ext-mtacAgentConfiguration EXTENSION ::= { SYNTAX AgentConfiguration IDENTIFIED BY id-pe-mtacAgentConfiguration CRITICALITY { FALSE } } id-pe-mtacAgentConfiguration OBJECT IDENTIFIER ::= { id-pe TBD3 } AgentConfiguration ::= SEQUENCE SIZE (1..MAX) OF ConfigurationComponent ConfigurationComponent ::= SEQUENCE { role UTF8String (SIZE (1..MAX)), name [0] UTF8String (SIZE (1..MAX)) OPTIONAL, version [1] UTF8String (SIZE (1..MAX)) OPTIONAL, digest [2] ComponentDigest OPTIONAL, reference [3] IA5String (SIZE (1..MAX)) OPTIONAL, source ClaimSource, Burls Expires 22 April 2027 [Page 41] Internet-Draft MTAC October 2026 ... } ComponentDigest ::= SEQUENCE { algorithm AlgorithmIdentifier{DIGEST-ALGORITHM, {DigestAlgorithmSet}}, value OCTET STRING } DigestAlgorithmSet DIGEST-ALGORITHM ::= { mda-sha256 | mda-sha384 | mda-sha512, ... } ClaimSource ::= ENUMERATED { declared (0), issuerVerified (1), attested (2), ... } END Appendix B. Examples This appendix is informative. Each example gives an extension value, in ASN.1 value notation, and its DER encoding in hexadecimal. The encodings were produced from the module in Appendix A and checked with a second, independent DER parser. The object identifiers for the extensions themselves are not yet assigned, so only the extension values (the contents of extnValue) are shown. B.1. Agent Sponsor { sponsor { uniformResourceIdentifier : "urn:example:org:EX:business-register:00000000" }, capacity "authorised signatory", mandate "https://mandates.example/m/0001" } 3068302f862d75726e3a6578616d706c653a6f72673a45583a627573696e6573 732d72656769737465723a30303030303030308014617574686f726973656420 7369676e61746f7279811f68747470733a2f2f6d616e64617465732e6578616d 706c652f6d2f30303031 B.2. Declared Scopes { "repository:read", "ci:run" } 30190c0f7265706f7369746f72793a726561640c0663693a72756e Burls Expires 22 April 2027 [Page 42] Internet-Draft MTAC October 2026 B.3. Agent Configuration Each component carries a SHA-256 digest. For reproducibility, the digests in this example are computed over short ASCII strings standing in for real inputs: "example-model weights v1" (24 octets) for the model and "example-runtime 2.4.1 evidence" (30 octets) for the runtime. A real deployment would digest the component, or the evidence, in a form its deployment profile defines. The runtime component is marked attested; its reference locates the attestation evidence the CA appraised, and its digest covers that evidence, so a relying party can check that what it retrieves is what the CA appraised. { { role "model", name "example-model", version "2026-09", digest { algorithm { algorithm id-sha256 }, value '81D5A8E7BA7EC798C3E0B85A90644581 607E770A5FC033EE95988BC0F5E603BD'H }, source declared }, { role "runtime", name "example-runtime", version "2.4.1", digest { algorithm { algorithm id-sha256 }, value '2A7F4808842ACDF0BC73041939A1EC76 75E11CB016AD5DC4CCE267F1711F670E'H }, reference "https://ca.example/evidence/rt-2.4.1", source attested } } 3081d230530c056d6f64656c800d6578616d706c652d6d6f64656c8107 323032362d3039a22f300b0609608648016503040201042081d5a8e7ba 7ec798c3e0b85a90644581607e770a5fc033ee95988bc0f5e603bd0a01 00307b0c0772756e74696d65800f6578616d706c652d72756e74696d65 8105322e342e31a22f300b060960864801650304020104202a7f480884 2acdf0bc73041939a1ec7675e11cb016ad5dc4cce267f1711f670e8324 68747470733a2f2f63612e6578616d706c652f65766964656e63652f72 742d322e342e310a0102 Appendix C. Test Vector This appendix is informative. It gives a complete log entry for a synthetic agent, the hash of that entry, and a worked inclusion proof in a four-entry log, so that an implementer can check an encoder, a decoder and a Merkle tree implementation against known values. Nothing in it is signed. The values were produced by a script written from this document and [I-D.ietf-plants-merkle-tree-certs], cross-checked with an independent DER parser and independent SHA-256 implementations, and by a separately written implementation of the subtree inclusion proof evaluation of Section 4.3.2 of that document. The three extension object identifiers are placeholders in the Burls Expires 22 April 2027 [Page 43] Internet-Draft MTAC October 2026 documentation arc 1.3.6.1.4.1.32473.2.1, .2 and .3 (sponsor, declared scopes, agent configuration), standing in for the values IANA assigns. The CA ID is the trust anchor ID 32473.1, so the issuer name is a single relative distinguished name of type id-rdna- trustAnchorID with value 0d0481fd5901. C.1. The agent +===============+==============================================+ | Field | Value | +===============+==============================================+ | agent | wimse://x-road.example/EX/BUSINESS/00000000/ | | identifier | reporting-agent (the path structure is | | | illustrative; this document defines none) | +---------------+----------------------------------------------+ | subject | empty; subjectAltName critical | +---------------+----------------------------------------------+ | subject key | ML-DSA-65; the 1952 octets of the public key | | | are 0, 1, 2, ..., 255, 0, 1, ... (octet i is | | | i mod 256) | +---------------+----------------------------------------------+ | validity | 2026-10-19 00:00:00 UTC to 2026-10-26 | | | 00:00:00 UTC | +---------------+----------------------------------------------+ | sponsor | the value of the Agent Sponsor example in | | | Appendix B | +---------------+----------------------------------------------+ | declared | repository:read, ci:run | | scopes | | +---------------+----------------------------------------------+ | configuration | one component, role model, name example- | | | model, version 2026-09, digest SHA-256 of | | | the ASCII string "example-model weights v1", | | | source declared | +---------------+----------------------------------------------+ Table 5 The SHA-256 hash of the DER encoding of the SubjectPublicKeyInfo (1974 octets) is: 8378eefb86a7ae09491f838f772409c07dbf1d47b95a37d75582a86ac1742155 C.2. The TBSCertificateLogEntry The DER encoding (463 octets) is: Burls Expires 22 April 2027 [Page 44] Internet-Draft MTAC October 2026 308201cba00302010230143112301006082b060105050719030d0481fd590130 1e170d3236313031393030303030305a170d3236313032363030303030305a30 00300b060960864801650304031204208378eefb86a7ae09491f838f772409c0 7dbf1d47b95a37d75582a86ac1742155a382015b3082015730490603551d1101 01ff043f303d863b77696d73653a2f2f782d726f61642e6578616d706c652f45 582f425553494e4553532f30303030303030302f7265706f7274696e672d6167 656e743078060a2b0601040181fd590201046a3068302f862d75726e3a657861 6d706c653a6f72673a45583a627573696e6573732d72656769737465723a3030 3030303030308014617574686f7269736564207369676e61746f7279811f6874 7470733a2f2f6d616e64617465732e6578616d706c652f6d2f30303031302906 0a2b0601040181fd590202041b30190c0f7265706f7369746f72793a72656164 0c0663693a72756e3065060a2b0601040181fd5902030457305530530c056d6f 64656c800d6578616d706c652d6d6f64656c8107323032362d3039a22f300b06 09608648016503040201042081d5a8e7ba7ec798c3e0b85a90644581607e770a 5fc033ee95988bc0f5e603bd0a0100 C.3. The log entry and its hash The MTCLogEntry (Section 5.2.1 of [I-D.ietf-plants-merkle-tree-certs]) has an empty extensions vector, encoded as the two octets 0000, then the type tbs_cert_entry, encoded as the two octets 0001, then tbs_cert_entry_data, which is the TBSCertificateLogEntry above without its outer SEQUENCE tag and length octets (the 459 content octets). Its length is 463 octets and it begins 00000001a003020102. The entry hash is the SHA-256 hash of the octet 0x00 followed by the entry: 468ab8db011397a80e1ddb90c453b13c9e1fe45b298abe31cae78acfd24df328 C.4. A four-entry log The agent entry is at index 2 of a log whose other entries are of type null_entry or carry only entry extensions. Their entries and entry hashes are: index 0: entry 00000000 hash 8855508aade16ec573d21e6a485dfd0a 7624085c1a14b5ecdd6485de0c6839a4 index 1: entry 0006fffe000276310000 hash 898ea43418e3bcff15bf71a8749e8281 95e2859e8f08fd0640dd7a203f725364 index 2: the agent entry hash 468ab8db011397a80e1ddb90c453b13c 9e1fe45b298abe31cae78acfd24df328 index 3: entry 000bfffd000101fffe000276320000 hash 817e15fbba33ce5f1a4967a13e575c23 74dd11d177c252cddeecd61ddc0add41 Burls Expires 22 April 2027 [Page 45] Internet-Draft MTAC October 2026 The hash of the subtree [0, 4), computed with the tree construction of Section 2.1.1 of [RFC9162] as Section 4.1 of [I-D.ietf-plants-merkle-tree-certs] specifies, is: fa661a3b95b11960dc96f238eb796310332bc025d7252e82ba322e41305fe0cf The subtree inclusion proof for the agent entry (index 2) in [0, 4) consists of the hash of entry 3, then the hash of the node over entries 0 and 1: 817e15fbba33ce5f1a4967a13e575c2374dd11d177c252cddeecd61ddc0add41 69b3db98de9c17f68b3afc75f3c46408e6a5430ee120de47cccc60a992457f04 Concatenated, as they appear in MTCProof.inclusion_proof, they form 64 octets. C.5. Certificate serial number and the signed message If the log has log number 1, the serial number of the certificate for the agent entry is (1 << 48) | 2 = 281474976710658 (0x1000000000002), DER 020701000000000002. A cosigner with cosigner ID 32473.3 signing this subtree for the issuance log with ID 32473.1.0.1 signs the following CosignedSubtree (Section 5.3.1 of [I-D.ietf-plants-merkle-tree-certs]), 120 octets, with timestamp zero, start 0 and end 4: 737562747265652f76310a00176f69642f312e332e362e312e342e312e333234 37332e3300000000000000001b6f69642f312e332e362e312e342e312e333234 37332e312e302e3100000000000000000000000000000004fa661a3b95b11960 dc96f238eb796310332bc025d7252e82ba322e41305fe0cf Appendix D. Mapping from the Previous Version This appendix is informative. It maps each element of the standalone format in [I-D.burls-mtac] to its counterpart in this profile. +=====================+========================================+ | Previous version | This version | +=====================+========================================+ | schema_version | X.509 version v3 | +---------------------+----------------------------------------+ | agent_id | the URI subjectAltName, constrained to | | | a workload identifier (Section 4.2) | +---------------------+----------------------------------------+ | sponsor_id | Agent Sponsor extension (Section 5.1) | +---------------------+----------------------------------------+ | authorized_scopes | Declared Scopes extension | Burls Expires 22 April 2027 [Page 46] Internet-Draft MTAC October 2026 | (capability tokens) | (Section 5.2), renamed so it does not | | | read as authorization | +---------------------+----------------------------------------+ | authorized_scopes | removed; the holder key is the | | holder token | subjectPublicKeyInfo, whose hash MTC | | aegis:holder: | already logs | +---------------------+----------------------------------------+ | not_before, | validity, with audit semantics in | | not_after | Section 8.3.3 | +---------------------+----------------------------------------+ | CBOR leaf and leaf | TBSCertificateLogEntry and MTC entry | | hash ([RFC9162] | hash (same tree construction) | | tree) | | +---------------------+----------------------------------------+ | AEGIS-STH-v1 signed | CA cosigner subtree signature (MTC | | tree head | Sections 5.3.1 and 5.4) | +---------------------+----------------------------------------+ | inclusion proof | MTCProof subtree inclusion proof | | array(3) | | +---------------------+----------------------------------------+ | AEGIS-WITNESS-v1 | audit cosigner subtree signature | | witness note | (Section 6) | +---------------------+----------------------------------------+ | AEGIS-HWM-v1 high- | audit cosigner timestamped checkpoint | | water mark | | +---------------------+----------------------------------------+ | AEGIS-HOLDER-v1 | any possession protocol meeting | | challenge-response | Section 7 | +---------------------+----------------------------------------+ | public ledger | optional audit cosigner publication | | corroboration | | +---------------------+----------------------------------------+ | batch-scoped | MTC revoked ranges (MTC Section 7.5) | | revocation | | | (roadmap) | | +---------------------+----------------------------------------+ | no model or | Agent Configuration extension | | configuration | (Section 5.3) | | information | | +---------------------+----------------------------------------+ Table 6 Appendix E. Related Work This appendix is informative. Burls Expires 22 April 2027 [Page 47] Internet-Draft MTAC October 2026 Merkle Tree Certificates [I-D.ietf-plants-merkle-tree-certs] provide the mechanism this document profiles. [I-D.gray-plants-mtc-deploy-use-cases] discusses MTC outside the web PKI, and [I-D.ietf-stir-certificate-transparency] is an example of a non-web X.509 identity ecosystem adopting transparency as a profile rather than a new mechanism. [I-D.ietf-wimse-aims] is the IETF working group document on AI agent identity management. This profile is intended to fit its credential layer (Section 10). [I-D.uppalapati-wimse-pq-agent-identity] states post-quantum requirements that Section 13 addresses. [I-D.elkins-plants-enterprise-mtc-deployment] describes the components an enterprise needs to serve standalone Merkle Tree Certificates, which are the form this profile requires. [I-D.sharif-x509-agent-identity-profile] also profiles X.509 for AI agent identity, with a non-critical extension carrying capabilities, a trust level, delegation constraints, an owner organization and a kill switch endpoint, and a SPIFFE URI subject alternative name. The differences are that this profile uses Merkle Tree Certificate issuance and logging, defines an audit cosigner role and an audit verification procedure, grades configuration claims by source, and gives its fields no authorization or enforcement meaning, where that profile's capabilities and kill switch are intended to be enforced by relying parties. Its owner organization corresponds to the Agent Sponsor extension here. Other individual drafts define agent credentials with their own formats: [I-D.sharif-apki-agent-pki] defines an X.509 agent PKI with Certificate Transparency style logging of each certificate, [I-D.fane-opena2a-aip] defines hybrid classical and ML-DSA agent credentials with per-event logging, and [I-D.maintainer-1f916-agent-record] defines witness-countersigned per-agent event logs. This profile differs from these in reusing MTC rather than defining a format. Individual drafts also define records of agent actions or authorizations: [I-D.mih-scitt-agent-action-capsule], [I-D.emirdag-scitt-ai-agent-execution], [I-D.noa-scitt-ai-agent-receipt], [I-D.izmaylov-agent-permission-receipts] and [I-D.coetzee-oauth-spt-txn-tokens]. [I-D.kuehlewind-audit-architecture] describes an architecture for auditing agent delegation and interactions. These address what an agent did or was permitted to do. This profile addresses only which agent it was, and Section 11 describes how the two connect. Burls Expires 22 April 2027 [Page 48] Internet-Draft MTAC October 2026 [I-D.palanisamy-scitt-aac-runtime] defines a vocabulary for the model, runtime and decoding settings behind an agent action, with each claim graded by source. The Agent Configuration extension adopts the grading idea and defers to such vocabularies for detail. Changes from draft-burls-mtac-00 This section is to be removed before publication. * Restructured as a profile of [I-D.ietf-plants-merkle-tree-certs]. Removed the standalone leaf, signed tree head, inclusion proof, witness note, high-water mark and holder commitment formats, and their test vectors. Removed the claim that batch issuance distinguishes this work. * Named the AI agent by a workload identifier in a URI subjectAltName, so that an MTAC certificate is also a WIMSE Workload Identity Certificate. * Replaced sponsor_id and authorized_scopes with the Agent Sponsor and Declared Scopes extensions. Added the Agent Configuration extension with source grading and configuration epochs. * Replaced the witness with an audit cosigner role under MTC Section 5.3, requiring post-quantum signatures and recommending a different signature family from the CA. * Added the audit verification procedure, with separate, machine- readable results, an explicit statement that an expired certificate still shows issuance but not current validity, and offline revocation policy. * Replaced the bespoke possession mechanism with requirements on any possession protocol. * Added relationships to WIMSE workload credentials and to transparency-service records of agent actions, including a binding through x5chain. * Removed the statement that the previous inclusion proof could be carried as a COSE Receipt proof, which was wrong for single-entry trees. * Added a section relating the profile to PQ-R1 to PQ-R7 of [I-D.uppalapati-wimse-pq-agent-identity] and stated non- conformance to CNSA 2.0. Burls Expires 22 April 2027 [Page 49] Internet-Draft MTAC October 2026 * Made the Agent Sponsor extension mandatory and added optional capacity and mandate-reference fields, stated that an agent is not a legal person, required the CA to establish that the requester may name the sponsor, and added a Revocation and Suspension section and an informative section on publication of issuer information. * Required strict DER decoding of the profile's extensions, and required that every value a relying party reports or acts on come from the authenticated TBSCertificate fields. * Required CAs to bind trust domains and relying parties to check that binding, and required at least one audit cosignature in every certificate. * Added a test vector (Appendix C). Removed the description of the author's software from Implementation Status except for what a reader needs to avoid confusion with the previous format. * Updated the implementation status, related work and references, including the closest prior X.509 agent profile. Replaced the reference to draft-klrc-aiagent-auth with its successor [I-D.ietf-wimse-aims]. RFC 9162 is no longer cited as a normative reference. Acknowledgments This profile builds on the work of the authors of Merkle Tree Certificates and of the IETF working groups for platform-independent transparency of certificates and for workload identity. A question on the PLANTS mailing list about why agent identity could not use X.509 and Merkle Tree Certificates directly prompted this revision. Author's Address Reuben Burls Aelethion OU Email: rgburls@gmail.com Burls Expires 22 April 2027 [Page 50]