]> Infinitum Nihil

Oxford Mississippi United States of America nt@infinitum-nihil.com

Security Individual Submission attestation ordering hash chain monotonic integrity This document defines the Monotonic Attestation Service (MAS), a protocol for issuing cryptographically attested, monotonically increasing sequence numbers within named namespaces. Each attestation includes a hash chain linking it to all prior entries in the namespace, providing verifiable proof of ordering and completeness. MAS is designed to complement RFC 3161 Trusted Timestamping: where RFC 3161 proves when an event occurred, MAS proves in what order and that the sequence is complete.

Introduction Many systems require proof that events occurred in a specific order and that no events have been inserted, removed, or reordered after the fact. Wall-clock timestamps (including RFC 3161 trusted timestamps) prove temporal existence but do not guarantee causal ordering -- two events timestamped milliseconds apart may have arrived in either order, and a compromised clock can backdate events. MAS addresses this gap by providing a monotonic counter with hash chain attestation per namespace. Each attestation includes:

• A sequence number that strictly increases and never repeats
• A cryptographic hash of the payload being attested
• A cryptographic hash linking to the previous attestation in the chain
• A digital signature from the MAS operator

The combination of monotonic sequencing and hash chaining provides two guarantees that timestamps alone cannot:

Total ordering:

Event N happened before event N+1. Not "at roughly the same time" -- before. Unambiguously.

Completeness:

If the verifier has attestations 1 through N with a valid hash chain, no attestations have been inserted or removed. The sequence is intact.

Relationship to RFC 3161 MAS is designed to operate alongside RFC 3161 , not replace it. A system MAY request both a MAS attestation (for ordering) and an RFC 3161 timestamp (for wall-clock anchoring) for the same event. The combination provides four independent guarantees:

Guarantee	Provider
Wall-clock existence	RFC 3161 TSA
Causal ordering	MAS sequence number
Sequence completeness	MAS hash chain
Authority	MAS Ed25519 signature

Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in .

Namespace:

A named scope within which sequence numbers are issued. Sequence numbers are unique and monotonically increasing within a namespace but independent across namespaces.

Attestation:

A signed record binding a sequence number to a payload hash within a namespace, chained to the previous attestation.

Chain:

The ordered, hash-linked sequence of all attestations within a namespace.

Operator:

The entity running the MAS instance and holding the signing key.

Requester:

The entity requesting an attestation for a payload.

Verifier:

Any entity validating an attestation or chain of attestations.

Data Model

Attestation Record An attestation record contains the following fields:

Field	Type	Description
version	unsigned integer	Protocol version. This document defines version 1.
namespace	text string	The namespace this attestation belongs to. UTF-8 encoded.
sequence	unsigned integer (64-bit)	Monotonically increasing sequence number within the namespace. Starts at 1.
payload_hash	byte string	SHA-256 hash of the payload being attested. The MAS never sees the payload itself.
previous_hash	byte string	SHA-256 hash of the previous attestation record in serialized form. For sequence 1, this is 32 zero bytes.
timestamp	unsigned integer (64-bit)	UNIX timestamp in milliseconds when the attestation was issued. This is the operator's local time and is NOT a trusted timestamp -- use RFC 3161 for trusted wall-clock time.
signature	byte string	Ed25519 signature over the canonical serialization of all preceding fields.

Canonical Serialization The canonical serialization of an attestation for hashing and signing is CBOR encoded as a definite-length array in field order: The signature is computed over the SHA-256 hash of this serialized array. The signature itself is NOT included in the array that is hashed.

Chain Genesis The first attestation in a namespace (sequence = 1) MUST use 32 zero bytes as the previous_hash. This is the chain genesis.

Chain Integrity For any attestation with sequence N > 1, the previous_hash field MUST equal the SHA-256 hash of the canonical serialization of the attestation with sequence N-1. A verifier can confirm chain integrity by iterating from sequence 1 to N, verifying that each attestation's previous_hash matches the hash of the prior record.

Protocol

Transport MAS is transport-agnostic. This document defines bindings for HTTPS () and Service Binding RPC (). Implementations MAY define additional transport bindings.

HTTPS Binding

Request Attestation } ]]>

Attestation Response , "previous_hash": <32 bytes>, "timestamp": 1710590400000, "signature": <64 bytes, Ed25519> } ]]>

Verify Single Attestation , "operator_public_key": <32 bytes, Ed25519 public key> } ]]> Response:

Verify Chain Segment , ... ], "operator_public_key": <32 bytes> } ]]> Response (complete chain): Response (broken chain):

Retrieve Attestation by Sequence

Retrieve Chain Segment

Retrieve Operator Public Key Response: , "valid_from": 1710590400000, "valid_until": null, "previous_keys": [ { "public_key": <32 bytes>, "valid_from": 1700000000000, "valid_until": 1710590400000 } ] } ]]>

Service Binding RPC Binding For environments where the MAS operator runs on the same infrastructure as the requester (e.g., Cloudflare Service Bindings, AWS Lambda extensions, sidecar containers), the same request/response format is used but transported via the platform's native RPC mechanism instead of HTTPS. The serialization format (CBOR) and field semantics are identical. The transport binding simply replaces the HTTP layer with the platform's internal call mechanism. This is the RECOMMENDED binding when the MAS is co-located with the requester, as it eliminates TLS overhead and DNS resolution.

Operational Considerations

Single-Writer Requirement A MAS instance MUST guarantee that sequence numbers within a namespace are issued by exactly one writer. Concurrent writers on the same namespace would violate monotonicity. Implementations SHOULD use a mechanism that provides single-writer semantics natively, such as:

• A serialized process with exclusive access to the counter
• A database with serializable isolation on the counter row
• A distributed coordination primitive with leader election

The specific mechanism is an implementation choice and not specified by this protocol.

Namespace Isolation Sequence numbers in different namespaces are independent. An operator MAY host many namespaces. There is no ordering relationship between attestations in different namespaces.

Key Management The operator SHOULD rotate signing keys periodically. When rotating, the operator MUST:

1. Publish the new public key via the /key endpoint before using it
2. Include the old key in the previous_keys array with its validity period
3. Sign a transition attestation in the old key that references the new key

Verifiers MUST use the key that was valid at the attestation's timestamp when verifying signatures.

Persistence The operator MUST persist all attestations durably. Loss of attestation records breaks the hash chain for all subsequent records. The operator SHOULD provide a retrieval API (, ) so that verifiers can reconstruct and verify chain segments.

Clock Advisory The timestamp field is advisory only -- it reflects the operator's local clock and is NOT a trusted timestamp. Systems requiring trusted wall-clock time SHOULD additionally obtain an RFC 3161 timestamp for the same payload. The timestamp field exists to assist verifiers in correlating attestations with real-world time ranges. It MUST NOT be used as the sole basis for temporal claims.

Verification

Single Attestation Verification To verify a single attestation, a verifier MUST:

1. Obtain the operator's public key that was valid at the attestation's timestamp
2. Reconstruct the canonical serialization () from the attestation fields
3. Compute the SHA-256 hash of the canonical serialization
4. Verify the Ed25519 signature over this hash using the operator's public key

A valid signature proves the operator issued this attestation with these exact field values.

Chain Verification To verify a chain segment from sequence S to sequence E, a verifier MUST:

1. Verify each individual attestation per
2. For each attestation with sequence N > S, verify that previous_hash equals SHA-256 of the canonical serialization of attestation N-1
3. If S = 1, verify that attestation 1 has previous_hash equal to 32 zero bytes

If all verifications pass, the chain segment is complete and unmodified.

Gap Detection If a verifier has attestations with non-contiguous sequence numbers (e.g., 100, 101, 103), this indicates either:

• Attestation 102 was not provided (incomplete disclosure)
• Attestation 102 never existed (operator error)

The verifier SHOULD report the gap and MUST NOT treat the chain as complete.

Fork Detection If a verifier encounters two different attestations with the same namespace and sequence number but different content, this indicates a fork -- the operator (or an attacker) issued conflicting attestations. This is a critical integrity violation. A verifier that detects a fork MUST reject both attestations and SHOULD alert the relying party.

Interaction with RFC 3161 A system that uses both MAS and RFC 3161 for the same event has two independent attestations:

1. MAS attestation: proves ordering and chain completeness
2. RFC 3161 timestamp token: proves wall-clock existence

These can be bundled together as a dual attestation: , "rfc3161_token": , "binding_hash": } ]]> The binding_hash cryptographically links the two attestations, preventing an attacker from mixing attestations from different events.

Security Considerations

Operator Trust MAS requires trust in the operator. A compromised operator can issue false attestations, skip sequence numbers, or maintain a shadow chain. This is analogous to the trust model of RFC 3161 TSAs. Mitigation: requesters MAY submit the same payload to multiple independent MAS operators and compare sequence assignments. Disagreement indicates compromise.

Denial of Service An attacker flooding the MAS with requests could exhaust sequence space or degrade performance. Operators SHOULD implement rate limiting per requester. The 64-bit sequence space supports 2^64 attestations per namespace, which is sufficient for all practical purposes.

Replay Attestation responses are deterministic for a given input and state. An attacker replaying an old attestation request will receive a new attestation with a new sequence number, not a replay of the old response. The hash chain prevents inserting the replayed response into the chain.

Namespace Squatting Namespaces are first-come-first-served within an operator. Operators SHOULD implement namespace registration and access control to prevent unauthorized use.

Quantum Resistance Ed25519 is not quantum-resistant. Future versions of this specification MAY define additional signature algorithms (e.g., ML-DSA / CRYSTALS-Dilithium) for post-quantum security. The version field enables algorithm negotiation.

IANA Considerations This document has no IANA actions at this time. A future version may request registration of a well-known URI (e.g., /.well-known/mas) and a media type for MAS attestations.

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. The Concise Binary Object Representation (CBOR) is a data format whose design goals include the possibility of extremely small code size, fairly small message size, and extensibility without the need for version negotiation. These design goals make it different from earlier binary serializations such as ASN.1 and MessagePack. This document obsoletes RFC 7049, providing editorial improvements, new details, and errata fixes while keeping full compatibility with the interchange format of RFC 7049. It does not create a new version of the format. Informative References This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] Federal Information Processing Standard, FIPS This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. This document describes version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document.

Reference Implementation A reference implementation is available as a Cloudflare Durable Object with Service Binding RPC transport. The implementation uses:

• ed25519-dalek for Ed25519 signatures
• sha2 for SHA-256 hashing
• ciborium for CBOR serialization
• Durable Object SQLite for counter persistence and attestation storage

The reference implementation is approximately 300 lines of Rust.

Example Chain

Genesis (sequence 1)

Sequence 2

Verification A verifier with both records confirms:

1. Attestation 1: previous_hash is 32 zero bytes (genesis). Signature valid.
2. Attestation 2: previous_hash equals SHA-256 of attestation 1's canonical serialization. Signature valid.
3. Sequence is contiguous (1, 2). Chain is complete.

Acknowledgments The concept of hash-chained monotonic attestation draws from Certificate Transparency , blockchain consensus mechanisms, and the Merkle tree structures underlying distributed ledger technologies. MAS simplifies these into a single-writer model suitable for centralized trust contexts where distributed consensus is unnecessary.