Merkle Tree Agent Certificates (MTAC): A Merkle Tree Certificates Profile for AI Agent Identity
draft-burls-mtac-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Reuben Burls | ||
| Last updated | 2026-10-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-burls-mtac-01
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-plants-
merkle-tree-certs-07>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
identifier-03>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
workload-creds-02>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[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,
<https://www.rfc-editor.org/rfc/rfc3986>.
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,
<https://www.rfc-editor.org/rfc/rfc5280>.
[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,
<https://www.rfc-editor.org/rfc/rfc5912>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[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,
<https://www.rfc-editor.org/rfc/rfc9881>.
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,
<https://csrc.nist.gov/pubs/fips/204/final>.
[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,
<https://datatracker.ietf.org/doc/draft-burls-mtac/00/>.
[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, <https://datatracker.ietf.org/doc/html/draft-
coetzee-oauth-spt-txn-tokens-03>.
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,
<https://datatracker.ietf.org/doc/html/draft-elkins-
plants-enterprise-mtc-deployment-00>.
[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, <https://datatracker.ietf.org/doc/html/draft-
emirdag-scitt-ai-agent-execution-01>.
[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, <https://datatracker.ietf.org/doc/html/
draft-fane-opena2a-aip-04>.
[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, <https://datatracker.ietf.org/doc/html/draft-gilda-
audit-agent-audit-record-00>.
[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, <https://datatracker.ietf.org/doc/html/
draft-gray-plants-mtc-deploy-use-cases-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-lamps-
pq-composite-sigs-19>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
transaction-tokens-11>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-scitt-
scrapi-11>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-stir-
certificate-transparency-04>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
aims-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
arch-08>.
[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,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
wpt-02>.
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, <https://datatracker.ietf.org/doc/html/draft-
izmaylov-agent-permission-receipts-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-jenkins-
cnsa2-pkix-profile-05>.
[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,
<https://datatracker.ietf.org/doc/html/draft-kuehlewind-
audit-architecture-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-maintainer-
1f916-agent-record-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-mih-scitt-
agent-action-capsule-05>.
[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, <https://datatracker.ietf.org/doc/html/draft-ni-
wimse-ai-agent-identity-03>.
[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,
<https://datatracker.ietf.org/doc/html/draft-noa-scitt-ai-
agent-receipt-01>.
[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, <https://datatracker.ietf.org/doc/html/
draft-novak-rats-tacra-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-palanisamy-
scitt-aac-runtime-00>.
[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,
<https://datatracker.ietf.org/doc/html/draft-sharif-apki-
agent-pki-01>.
[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,
<https://datatracker.ietf.org/doc/html/draft-sharif-x509-
agent-identity-profile-04>.
[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, <https://datatracker.ietf.org/doc/html/draft-
uppalapati-wimse-pq-agent-identity-00>.
[RFC5937] Ashmore, S. and C. Wallace, "Using Trust Anchor
Constraints during Certification Path Processing",
RFC 5937, DOI 10.17487/RFC5937, August 2010,
<https://www.rfc-editor.org/rfc/rfc5937>.
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,
<https://www.rfc-editor.org/rfc/rfc7942>.
[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,
<https://www.rfc-editor.org/rfc/rfc8693>.
[RFC9162] Laurie, B., Messeri, E., and R. Stradling, "Certificate
Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162,
December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.
[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, <https://www.rfc-editor.org/rfc/rfc9334>.
[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, <https://www.rfc-editor.org/rfc/rfc9360>.
[RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/rfc/rfc9711>.
[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,
<https://www.rfc-editor.org/rfc/rfc9942>.
[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,
<https://www.rfc-editor.org/rfc/rfc9943>.
[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, <https://www.rfc-editor.org/rfc/rfc9964>.
[TLOG-WITNESS]
C2SP, "Transparency Log Witness Protocol", October 2026,
<https://c2sp.org/tlog-witness@v1.1.0>.
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:<jkt> | 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]