Merkle Tree Agent Certificates (MTAC): Batch-Issued Post-Quantum Identity Credentials for AI Agents

Internet-Draft	MTAC	July 2026
Burls	Expires 22 January 2027	[Page]

Abstract

This document specifies Merkle Tree Agent Certificates (MTAC), a credential format and issuance profile in which a certificate authority commits a batch of AI agent identity credentials to a Merkle tree, signs only the tree head with the post-quantum signature algorithm ML-DSA-65, and distributes a per-credential inclusion proof. A relying party verifies a credential offline against the signed tree head without contacting the issuer. Each batch root is additionally co-signed by an independently keyed witness, providing per-batch integrity and continuity attestation, and its root can be corroborated against an independent public record.¶

MTAC defines the leaf structure, its deterministic encoding, the leaf hash preimage, the signed tree head wire format, the witness co-signature, and an optional challenge-response proof of possession that binds a credential to a holder key. Test vectors are provided. This document specifies a credential issuance and verification mechanism. Declared scopes carried in a credential are self-reported parameters recorded at issuance; this document does not specify a runtime authorization mechanism.¶

1. Introduction

Autonomous AI agents increasingly act across organizational boundaries. A relying party receiving a request from such an agent needs to determine what credential that agent was issued, by which authority, under what declared parameters, and whether that credential is present in a tamper-evident log that can be independently checked. Existing credential formats address parts of this problem, but issuing an individual signed certificate per agent scales poorly when agent populations are large and credential lifetimes are short, and post-quantum signatures are substantially larger than the classical signatures they replace.¶

Merkle Tree Agent Certificates (MTAC) addresses this by making the batch, rather than the individual credential, the unit of issuance. A certificate authority collects agent identity assertions over a batch window, constructs a Merkle tree over the resulting leaves, and produces a single ML-DSA-65 [FIPS204] signature over the tree head. Each agent receives an inclusion proof of size logarithmic in the batch size. One signing operation covers the whole batch, and verification is a local hash computation against a signed tree head that the verifier already holds.¶

1.1. Position of this work

As of 21 July 2026, no third-party public document, specification, or shipped system specifies Merkle batch issuance as the unit of credential issuance for AI agent identity under post-quantum (ML-DSA-65) signed tree heads, with each batch root independently co-signed by a distinct witness key and publicly corroborated.¶

Adjacent work occupies other compositions. MAGIQ (arXiv:2605.06933) performs post-quantum batch authorization over a private, unlogged aggregation and states that it provides no revocation. The GoDaddy Agent Name Service operates a production, publicly queryable log labelled RFC9162_SHA256 recording per-entry agent registrations under classical signatures. draft-coetzee-oauth-spt-txn-tokens co-signs Merkle tree heads with an external witness over post-hoc authorization receipts rather than over credential issuance. draft-fane-opena2a-aip and draft-sharif-apki-agent-pki perform per-event Certificate Transparency style logging of agent credentials. [I-D.ietf-plants-merkle-tree-certs] specifies post-quantum Merkle batch issuance for non-agent subjects, and its working group is chartered for WebPKI and TLS.¶

The closest artifact is a shipped implementation rather than a specification. CIRISVerify requires hybrid Ed25519 and ML-DSA-65 signed tree heads over an RFC 6962 log for AI agents, and additionally defines N-of-M co-signature of those tree heads by independently keyed witnesses. It holds every element named above except one: its log records licence verification events, and its licences are signed individually rather than committed as a batch. The distinguishing property of this specification is therefore the issuance unit, not the witness arrangement and not the use of post-quantum signatures, both of which are present in prior work. See Section 12.¶

This document does not claim novelty in Merkle tree construction, in inclusion proofs, in post-quantum signatures, or in carrying an inclusion proof alongside a credential. Each of those is established practice, and Section 12 identifies where.¶

1.2. What this document does not specify

The distinction matters for correct implementation, so it is stated here rather than only in Section 14.¶

Declared scopes in an MTAC leaf are self-reported parameters recorded at issuance. This document specifies how they are encoded, committed, and verified as having been issued. It does not specify a runtime authorization mechanism, and a relying party MUST NOT treat the presence of a scope token as evidence that the agent operated within it.¶

Verification establishes that a credential was validly issued by the named authority and is present in the log at the given tree head. It does not establish what the agent subsequently did.¶

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.¶

Batch:: The set of agent identity assertions committed to a single Merkle tree by one certificate authority during one batch window.¶
Leaf:: The canonical encoding of a single agent identity assertion, as defined in Section 4.¶
Leaf hash:: The 32-octet SHA-256 value computed over the preimage defined in Section 5.¶
Signed Tree Head (STH):: The structure defined in Section 6, binding a log identifier, a tree size, a timestamp, and a Merkle root, signed with ML-DSA-65.¶
Witness:: An entity holding a signing key distinct from the certificate authority key, which co-signs batch roots as described in Section 8.¶
Holder commitment:: A thumbprint of a public key, carried as a scope token in a leaf, committing the credential to a key whose possession can later be demonstrated (Section 9).¶
Declared scope:: A self-reported parameter recorded in a leaf at issuance. The term "declared" is load-bearing throughout this document.¶

4. MtacLeaf

4.1. Structure

An MtacLeaf contains exactly six fields. All six are mandatory. There are no optional fields in schema version 1.¶

Table 1
Field	CBOR type	Description
`schema_version`	unsigned integer	MUST be 1
`agent_id`	text string	Identifier of the agent
`sponsor_id`	text string	Identifier of the sponsoring entity
`authorized_scopes`	array of text string	Declared scopes; see Section 4.3
`not_before`	unsigned integer	Start of the validity window, seconds since the Unix epoch
`not_after`	unsigned integer	End of the validity window, seconds since the Unix epoch

schema_version is an ordinary map entry. It is not a CBOR tag and not an envelope. A decoder that encounters schema_version other than 1 MUST reject the leaf.¶

Implementations MUST NOT assume that not_before is less than or equal to not_after. The encoding layer is value-agnostic, and coherence of the validity window is a policy check performed above this layer. A verifier that requires a coherent window MUST check it explicitly.¶

4.2. Canonical encoding

A leaf is encoded as a CBOR [RFC8949] map using the deterministic encoding rules of [RFC8949] Section 4.2.1 (CDER), with the additional constraints in this section. The rules below are normative and are restated here rather than incorporated by reference, because two of them are commonly implemented incorrectly and both change the leaf hash.¶

Map key ordering is bytewise over the ENCODED key. Keys MUST be sorted by comparing their complete CBOR encodings as octet strings, which includes the initial length head. This is not string-lexicographic ordering of the key text. See Section 4.2.1.¶
Integers MUST use the shortest form. An encoder MUST NOT emit a value in a wider representation than necessary. A decoder MUST reject non-shortest-form integers.¶
Text strings MUST be in Unicode Normalization Form C (NFC), and normalization is applied before the length head is computed. An encoder that emits non-NFC UTF-8 produces a different leaf hash for a semantically equal leaf. A decoder MUST reject text that is not in NFC.¶
Duplicate map keys MUST be rejected by decoders.¶
Array element order is preserved and is significant. Only map keys are reordered by the canonical form. Two leaves whose authorized_scopes contain the same elements in a different order are different leaves with different leaf hashes. Implementations MUST NOT sort authorized_scopes as a normalization step.¶

A decoder that accepts any of the forms this section requires to be rejected introduces malleability: two distinct octet strings would decode to the same leaf, while hashing to different leaf hashes.¶

4.2.1. Map key ordering, worked

The six schema version 1 keys, with their encoded first octet:¶

Table 2
Key	Length	First encoded octet
`agent_id`	8	0x68
`not_after`	9	0x69
`not_before`	10	0x6a
`sponsor_id`	10	0x6a
`schema_version`	14	0x6e
`authorized_scopes`	17	0x71

Because the length head is the first octet compared, shorter keys sort first. The correct order is therefore:¶

agent_id, not_after, not_before, sponsor_id, schema_version,
authorized_scopes

Sorting the same six keys as text strings yields a different order:¶

agent_id, authorized_scopes, not_after, not_before, schema_version,
sponsor_id

An implementation that produces the second order produces a different octet string and therefore a different leaf hash. This is the single most likely source of interoperability failure in this specification.¶

4.3. Declared scopes

authorized_scopes is an array of text strings. Two token classes are defined.¶

A capability scope token describes an operation class the agent declares it may perform. Capability scope tokens are self-reported by the requesting entity and recorded by the CA. They are declared parameters. This document specifies no vocabulary for them and no mechanism by which they constrain agent behaviour.¶

A holder commitment token has the form aegis:holder:<jkt>, where <jkt> is the 43-character thumbprint defined in Section 9.1. A holder commitment token is a key commitment. It grants nothing and gates nothing by itself. It is not a permission and not an access grant. Its only function is to identify the key whose possession may be demonstrated under Section 9.¶

A relying party MUST NOT interpret either token class as evidence about agent behaviour.¶

5. Leaf hash

The leaf hash is SHA-256 over a preimage of exactly four concatenated segments:¶

Table 3
Offset	Length	Contents
0	1	0x00, the [RFC9162] Section 2.1.1 leaf type octet
1	16	`DOMAIN_LABEL`, defined below
17	32	CA public key fingerprint, defined below
49	L	The canonical leaf encoding from Section 4.2

The total preimage length is 49 + L octets.¶

DOMAIN_LABEL is the following 16 octets:¶

"aegis-leaf/v1\n\0\0"
61 65 67 69 73 2d 6c 65 61 66 2f 76 31 0a 00 00

The CA public key fingerprint is the SHA-256 of the raw 1952-octet ML-DSA-65 public key as defined by [FIPS204] Section 5.3. The public key MUST NOT be wrapped in any ASN.1, DER, or other structure before hashing. Implementations that wrap the key before hashing will compute a different fingerprint, a different leaf hash, and will fail to interoperate.¶

The same 32-octet value is used as the log_id in Section 6. One value therefore binds a leaf to its issuer and identifies the log in the signed tree head.¶

No length prefix and no separator appears before the trailing leaf encoding. The construction is unambiguous because the three preceding segments are of fixed width, so the boundary between the fingerprint and the leaf encoding is determined by position alone. Implementations MUST NOT insert a length prefix.¶

Leaf index and batch epoch are deliberately absent from the preimage. Position in the tree is bound by the inclusion proof and the verification algorithm that consumes leaf_index, following [RFC9162] Section 2.1.3.2.¶

5.1. Test vector

The following vector is fully reproducible. The CA public key is synthetic and defined by a rule rather than supplied as a blob, so no key file is required.¶

Leaf field values:¶

schema_version    : 1
agent_id          : "urn:aegis:agent:f01"
sponsor_id        : "sponsor@example.com"
authorized_scopes : ["scope:read"]
not_before        : 1713600000
not_after         : 1745136000

Canonical leaf encoding, L = 138 octets:¶

a6686167656e745f69647375726e3a61656769733a6167656e743a663031696e6f745f61
667465721a6804a9806a6e6f745f6265666f72651a662376006a73706f6e736f725f6964
7373706f6e736f72406578616d706c652e636f6d6e736368656d615f76657273696f6e01
71617574686f72697a65645f73636f706573816a73636f70653a72656164

CA public key: 1952 octets where octet i has value (i mod 256), for i from 0 to 1951. Its SHA-256 fingerprint is:¶

0a9594d4796731c68bae082ee8641342b7782bd5eac0919dea05c16a4f48683d

Preimage length: 1 + 16 + 32 + 138 = 187 octets. Resulting leaf hash:¶

8dd4e9aad96815df9ffe9fddb2d7ff7e867cc345a771b2d40fc8e464f04b9995

An implementation that reproduces this value has correctly implemented Section 4.2 and this section, including the map key ordering of Section 4.2.1.¶

6. Signed Tree Head

6.1. Wire format

The signed tree head is a CBOR array of two elements:¶

array(2)[
  tstr "AEGIS-STH-v1",
  bstr( array(5)[ log_id         bstr(32),
                  tree_size      uint,
                  timestamp      uint,
                  root_hash      bstr(32),
                  sth_extensions array ] )
]

The envelope and the body are emitted in definite-length shortest form. The octet string in position 1 is the signed message: the signature is computed over exactly those octets as received. A verifier MUST verify over the received octets and MUST NOT re-encode the body before verifying, because any re-encoding that differs by a single octet produces a different message and a failed verification.¶

log_id is the SHA-256 of the raw ML-DSA-65 CA public key, the same value used as the fingerprint in Section 5.¶

timestamp is milliseconds since the Unix epoch.¶

sth_extensions is an array, empty in this version. This document defines no extension semantics; the field exists so that the signed body has a place for future extension, and it is covered by the signature. Implementations MUST accept an empty array and MUST NOT assume the field is absent.¶

The wire order is tree_size before timestamp. Implementations MUST emit and parse the body in the order given above. Any ordering derived from a struct declaration, a serialization library's field order, or alphabetical sorting is incorrect.¶

6.2. Signature and domain separation

The signature is ML-DSA-65 [FIPS204] over the signed message, using the FIPS 204 Section 5.2 context parameter with the value:¶

ctx = "AEGIS-STH-v1"

Domain separation is therefore dual layer: the context string appears both as the tag in position 0 of the envelope, which is inside the hashed message, and as the FIPS 204 context, which is not. A verifier MUST supply the context string. Verifying with an empty context will reject valid signatures.¶

The signature is 3309 octets. The CA public key is 1952 octets. Both lengths are as specified in [FIPS204] for ML-DSA-65 and are cross-referenced in [RFC9964].¶

6.3. Relationship to ML-DSA in JOSE and COSE

MTAC signatures are raw [FIPS204] signatures. They are not JOSE or COSE signatures, and this document does not define a COSE or JOSE serialization.¶

This distinction is stated explicitly because [RFC9964] Section 5 requires that "the ctx parameter MUST be the empty string for ML-DSA-44, ML-DSA-65, and ML-DSA-87" when ML-DSA is used in JOSE or COSE, whereas every MTAC signature uses a non-empty FIPS 204 context. There is no conflict: that requirement governs the JOSE and COSE serializations [RFC9964] defines, and MTAC uses neither.¶

[RFC9964] is cited normatively by this document for two things only: the AKP key type and the ML-DSA-65 algorithm name used in the holder thumbprint of Section 9.1, and the confirmation of [FIPS204] key and signature lengths. It is not cited as the serialization for any MTAC signature.¶

An implementation that wishes to carry MTAC evidence inside COSE, for example as a COSE Receipt, cannot reuse an MTAC signature directly: a COSE object asserting ML-DSA-65 must have been produced with an empty context, so it would be a second, separate signature over a different input. That is a known consequence of the design and is discussed further in Section 12.2.¶

7. Inclusion proof

An inclusion proof is a CBOR array of three elements, emitted in definite-length shortest form:¶

array(3)[ tree_size uint, leaf_index uint, path array of bstr(32) ]

Note the element order: tree_size precedes leaf_index. The two elements are both unsigned integers, so a decoder cannot detect a transposition by type, and an implementation that reverses them will verify single-leaf trees successfully while failing on every larger tree. This order is deliberately the same as the inclusion proof of [RFC9942] Section 5.2, so that an MTAC proof can be carried as a COSE Receipt proof without reordering. See Section 12.¶

path contains the sibling hashes from the leaf to the root, in leaf-to-root order. Interior nodes are hashed with the 0x01 prefix, per [RFC9162] Section 2.1.1, so that no interior node hash can collide with a leaf hash, which uses the 0x00 prefix given in Section 5.¶

For a tree of size 1 the path is empty and the leaf hash equals the root hash. A single-leaf proof therefore encodes as the four octets 83 01 00 80, which is array(3) followed by tree_size 1, leaf_index 0, and an empty path.¶

Verification folds the path using the bits of leaf_index, following [RFC9162] Section 2.1.3.¶

8. Witness co-signature

8.1. Purpose and limits

A witness holds a signing key distinct from the CA key and co-signs batch roots. The witness provides per-batch, independent-key co-signed integrity and continuity attestation. It protects a relying party that checks it against a compromise limited to the CA key, and against dropped or truncated batches.¶

The witness described here does NOT provide non-equivocation. Achieving that property would require an independently operated third-party witness and a route by which entries can be enumerated, neither of which this document specifies. Implementers and reviewers comparing this mechanism against the receipts of [RFC9942], which does address that property, should note the difference. The witness check is additive: it does not replace the primary verification result defined in Section 10.¶

8.2. Co-signature format

The witness signs a five-line note. The note is deliberately human-readable rather than CBOR, so that an auditor can inspect a co-signature artifact by eye. The signed octets are exactly, with no trailing octet after the final newline:¶

AEGIS-WITNESS-v1\n
origin:<origin>\n
size:<size>\n
root_hash:<root_hash_hex>\n
timestamp:<timestamp>\n

Byte-exact reconstruction is required to verify the signature, so each field is specified precisely:¶

origin: A textual log identifier, assigned by the operator and carried in the log's metadata. It is not cryptographically bound to log_id in this version, and a verifier MUST NOT treat it as an authenticated identifier. It is present so that a human auditor can tell two logs apart in a co-signature artifact. Binding it is a candidate for a future revision.¶
size: The tree_size of the signed tree head being co-signed, rendered as decimal ASCII with no leading zeros and no separators.¶
root_hash_hex: The root_hash of that signed tree head, rendered as exactly 64 lowercase hexadecimal characters.¶
timestamp: The timestamp field of the signed tree head being co-signed, rendered as decimal ASCII with no leading zeros. It is the log's timestamp, not the witness's own signing time, so a verifier reproduces it from the tree head rather than from any clock.¶

The signature algorithm is ML-DSA-65 with the FIPS 204 context:¶

ctx = "AEGIS-WITNESS-v1"

This context MUST differ from the CA context of Section 6. A verifier MUST NOT accept a witness co-signature as a CA tree head signature or the reverse.¶

The batch identifier is NOT part of the signed note. A verifier locates a co-signature by root_hash, not by batch identifier.¶

8.3. Witness trust root

The witness public key is a trust root. A verifier MUST obtain it out of band, from a list of trusted witnesses it maintains, and MUST NOT take it from the co-signature artifact itself. An artifact-supplied key verifies its own contents and provides nothing: the artifact is controlled by the same party that produced it, so accepting an inline key reduces the check to self-attestation.¶

A verifier that encounters a co-signature whose public key is not in its trusted list MUST treat the co-signature as untrusted rather than as absent, because the two conditions have different causes and a deployment may wish to distinguish them.¶

8.4. High-water mark

To detect truncation of the batch sequence, a witness maintains a signed high-water mark. The signed payload is 21 octets:¶

"AEGIS-HWM-v1:" || uint64_be(hwm)

The FIPS 204 context for the high-water mark signature is:¶

ctx = "AEGIS-HWM-v1"

This context MUST differ from the contexts of Section 6 and Section 8.2. Note that the context string and the payload prefix are not the same octets: the payload prefix carries a trailing colon and the context string does not. An implementation that reuses one for the other will produce signatures no conforming verifier accepts.¶

A verifier that observes a latest batch number lower than a previously observed signed high-water mark MUST treat the sequence as truncated.¶

9. Holder proof of possession

This mechanism is OPTIONAL. A credential carrying no holder commitment is a bearer credential, and verification behaviour is unchanged.¶

9.1. Thumbprint computation

The holder commitment is the base64url encoding, without padding [RFC4648] Section 5, of the SHA-256 of a canonical JSON object with exactly three members, in this order:¶

{"alg":"ML-DSA-65","kty":"AKP","pub":"<base64url-nopad raw public key>"}

There is no whitespace. The member order is lexicographic by member name, as required by the [RFC7638] Section 3 process. The kty value AKP and the algorithm name ML-DSA-65 are as registered in [RFC9964] Section 3. The pub member carries the raw [FIPS204] Section 5.3 public key encoding.¶

The resulting thumbprint is 43 characters.¶

This document specifies SHA-256 as the thumbprint hash. Neither [RFC7638] nor [RFC9964] mandates a particular hash for this computation: [RFC7638] Section 3.4 leaves the choice to the application. Implementations MUST use SHA-256 for MTAC holder commitments.¶

The COSE integer values registered in [RFC9964] for the key type and algorithm are not used in this computation. The JSON member values are the strings above.¶

9.1.1. Test vector

Using the same synthetic key rule as Section 5.1, namely 1952 octets where octet i has value (i mod 256), the canonical JSON object begins:¶

{"alg":"ML-DSA-65","kty":"AKP","pub":"AAECAwQFBgcICQoLDA0ODx...

and the resulting thumbprint is:¶

u0JcdAyiIOVlMstYWc-w2n2RJ437Y3-WbE4QfBHG35U

One synthetic key therefore serves both test vectors in this document.¶

9.2. Committed form

The commitment is carried as a single scope token in authorized_scopes:¶

aegis:holder:<43-character thumbprint>

The token is 56 characters. No field is added to the leaf. The leaf structure of Section 4 is unchanged, and a verifier that does not implement this section parses the leaf normally and treats the token as an opaque scope string.¶

9.3. Challenge and response

A verifier generates a challenge and transmits it to the presenting party. The presenting party signs a payload constructed as a CBOR array of two elements, encoded in definite-length shortest form:¶

array(2)[ bstr(challenge), tstr(session_identifier) ]

The session identifier is the value of the leaf's agent_id field. It is taken from the verified leaf, not from any value the presenting party supplies.¶

The signature uses ML-DSA-65 with the FIPS 204 context:¶

ctx = "AEGIS-HOLDER-v1"

This gives three-way domain separation across the tree head, witness, and holder contexts.¶

Payload test vector, for a 16-octet challenge of 00 01 02 ... 0f and session identifier urn:aegis:session:golden:¶

8250000102030405060708090a0b0c0d0e0f781875726e3a61656769733a
73657373696f6e3a676f6c64656e

9.4. Verifier requirements

A verifier performing a possession check MUST:¶

Reconstruct the signed payload from the challenge IT generated and the session identifier committed in the credential. It MUST NOT use values supplied by the presenting party for either.¶
Verify the signature BEFORE comparing the thumbprint. The check order is signature first, then thumbprint.¶
Recompute the thumbprint from the presented public key per Section 9.1 and compare it against the committed token.¶

A challenge MUST be at least 16 octets.¶

Challenge uniqueness is an operational obligation of the verifier. This specification defines no challenge generator, no nonce store, no replay ledger, and no challenge expiry. A verifier that reuses a challenge, or that accepts a challenge it did not itself generate, obtains no possession guarantee. See Section 14.¶

A successful possession check demonstrates that the presenting party holds the private key committed at issuance, at the time of presentation. It does not establish that the presenting party is the agent named in the credential, and it does not establish independent actor status. Where a single operator holds both the CA key and the holder key, key custody is deployment-dependent.¶

10. Verification

10.1. Primary verification

A relying party verifying a credential MUST perform all of the following:¶

Decode the leaf, rejecting any non-canonical form per Section 4.2.¶
Recompute the leaf hash per Section 5.¶
Fold the inclusion proof to a candidate root.¶
Compare the candidate root against root_hash in the signed tree head.¶
Verify the ML-DSA-65 signature over the signed tree head with the context of Section 6, using a CA public key obtained out of band.¶

The result of primary verification is that the credential was validly issued by the authority identified by log_id and is present in the log at the given tree head. This is the complete meaning of a successful result. It carries no implication about the agent's subsequent behaviour.¶

The CA public key is a trust root. It MUST be obtained out of band and pinned. A verifier that accepts a CA public key supplied alongside the credential obtains no security property, because a substituted key accompanied by a re-signed tree head verifies successfully.¶

10.2. Freshness and replay

A verifier MAY additionally require freshness by rejecting a tree head older than a configured maximum age, and MAY reject a tree head whose timestamp is not strictly greater than the last one observed for the same log_id. Both are implemented in the reference verifier described in Section 13.¶

10.3. Additive checks

The witness check of Section 8 and the possession check of Section 9 are additive. Where a relying party demands one and it fails, that is a distinct outcome from primary verification failure, and implementations SHOULD signal the two distinctly.¶

10.4. Public corroboration

An MTAC log operator MAY publish batch roots to an independent public medium so that a relying party can confirm that a root matches what the log committed, without trusting the log operator. Where such corroboration is published on a public ledger, the published value corroborates the signed tree head Merkle root only. It does not establish anything about agent behaviour, and the availability properties of the publishing medium are outside the scope of this document.¶

13. Implementation Status

This section is to be removed before publication as an RFC, per [RFC7942].¶

13.1. Reference verifier

An independent verifier implementation is published and installable:¶

pip install aegis-verifier==0.1.3

Table 4
Property	Value
Version	0.1.3
Released	2026-05-21
License	Apache-2.0
Requires	Python 3.11 or later
Coverage	Linux x86_64 and aarch64 (manylinux and musllinux), macOS universal2, Windows x86_64

The distribution is built from a Rust core with PyO3 and maturin. liboqs is statically bundled, so no native build dependencies are required at install time.¶

13.2. What the published version verifies

Version 0.1.3 performs primary verification as defined in Section 10: signed tree head signature, Merkle inclusion, and leaf hash. It additionally implements the freshness and replay checks described in Section 10, exposing a stateful verifier that tracks the last seen tree head per log_id.¶

Version 0.1.3 does NOT implement the witness co-signature check of Section 8 or the holder possession check of Section 9. Those checks were added to the issuing implementation after this version was released and are performed by the issuing side tooling. A future release is expected to cover them.¶

13.3. Verified behaviour

The following were executed against the published distribution on 2026-07-21.¶

Primary verification of a genuine ML-DSA-65 signed batch succeeded, returning leaf index, tree size, and tree head timestamp. Three negative controls were each rejected: a corrupted signature, a substituted CA public key, and a single flipped octet in the leaf.¶

The leaf hash test vector of Section 5.1 was computed independently in two implementations, a Python reimplementation written from this document and the Rust reference, producing identical output. The thumbprint golden vector of Section 9.1 was likewise confirmed by executing the reference implementation's own test suite against the pinned reference revision.¶

The FIPS 204 public key encoding was confirmed by taking the ML-DSA-65 example from [RFC9964] Appendix A, which the RFC states is the [FIPS204] Section 5.3 encoding, and verifying the RFC's published signature under the RFC's published public key using the same liboqs build the implementation uses. Verification succeeded and a tampered-message control was rejected.¶

The decoder rejections required by Section 4.2 were each confirmed against the reference decoder: non-shortest-form integers, misordered map keys, duplicate map keys, and non-NFC text are all rejected.¶

13.4. Public corroboration deployment

The issuing implementation publishes batch roots to a contract on the Ethereum Sepolia testnet, dev-grade key. A relying party can compare a published root against the signed tree head root it already holds. The published value corroborates the signed tree head Merkle root only.¶

14. Security Considerations

14.1. The issuance-time boundary

This is the most important consideration in this document.¶

MTAC establishes what credential a session or agent was issued, by which authority, under what declared parameters, and that the credential is present in the log. It does not establish what the agent does at request time. A credential that verifies successfully may be held by an agent whose behaviour has since changed.¶

Declared scopes are not proof of behaviour. A relying party that treats a scope token as a behavioural guarantee has made an error this specification cannot detect. Relying parties requiring assurance about request-time behaviour need a mechanism outside this document.¶

14.2. Challenge freshness

The possession mechanism of Section 9 derives its value entirely from challenge freshness, and this specification places that obligation on the verifier. The software requirement is a minimum challenge length of 16 octets and nothing more. There is no challenge generator, no nonce store, no replay ledger, and no expiry defined here or implemented in the reference tooling.¶

A verifier that reuses challenges, accepts challenges generated elsewhere, or fails to bind the challenge to the session under check obtains no possession guarantee, while the protocol appears to succeed. Implementers MUST generate challenges from a cryptographically secure random source, MUST use each challenge once, and SHOULD bind challenge lifetime to the transaction.¶

14.3. Bearer behaviour by default

A credential carrying no holder commitment is a bearer credential. Anyone holding the credential bytes can present them and primary verification will succeed. Where a relying party does not demand a possession check, behaviour is identical to bearer. Deployments requiring more MUST demand the check explicitly rather than assuming it occurred.¶

14.4. Encoding malleability

The decoder requirements of Section 4.2 are security requirements, not style preferences. A decoder that accepts non-canonical forms permits two distinct octet strings to decode to the same logical leaf while hashing to different leaf hashes, which breaks the correspondence between what was committed and what is verified.¶

The NFC requirement is easy to overlook. Two agent identifiers that render identically but differ in Unicode normalization produce different leaf hashes. The array-order requirement is similarly easy to overlook: implementations MUST NOT sort authorized_scopes.¶

14.5. Trust root distribution

The CA public key is the trust root and MUST be pinned out of band. A verifier that takes the CA key from the same channel as the credential gains nothing, because an adversary supplying both a substituted key and a re-signed tree head produces a successful verification. The log_id binding of Section 5 means a substituted key also changes every leaf hash, so a mismatched pin is detectable, but only if a pin exists.¶

14.6. Witness limits

The witness of Section 8 protects against a compromise limited to the CA key and against dropped or truncated batches. It does not protect against an adversary who controls both the CA key and the witness key, and it does not provide non-equivocation. A deployment operating both the CA and the witness under one administrative authority obtains integrity and continuity attestation, not independence.¶

14.7. Post-quantum posture

ML-DSA-65 [FIPS204] is used for all signatures. Signature size is 3309 octets and public key size is 1952 octets. Batch issuance amortizes the signing cost across a batch, but each relying party still transports one tree head signature. Deployments with constrained transport should size batches accordingly.¶

The security of the construction also depends on SHA-256, used for the leaf hash, the Merkle tree, and the thumbprint.¶

16. References

16.1. Normative 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>.
[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>.
[RFC4648]: Josefsson, S., "The Base16, Base32, and Base64 Data Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, <https://www.rfc-editor.org/rfc/rfc4648>.
[RFC7638]: Jones, M. and N. Sakimura, "JSON Web Key (JWK) Thumbprint", RFC 7638, DOI 10.17487/RFC7638, September 2015, <https://www.rfc-editor.org/rfc/rfc7638>.
[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>.
[RFC8949]: Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, DOI 10.17487/RFC8949, December 2020, <https://www.rfc-editor.org/rfc/rfc8949>.
[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>.
[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>.

16.2. Informative 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-05, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-plants-merkle-tree-certs-05>.
[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>.
[RFC6962]: Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/rfc/rfc6962>.
[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>.
[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>.