Taistamp: Signed TAI64N Timestamps over HTTP
draft-mery-nagy-taistamp-00
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) | |
|---|---|---|---|
| Authors | Alejandro Mery , Nagy Károly Gábriel | ||
| Last updated | 2026-05-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-mery-nagy-taistamp-00
Network Working Group A. Mery
Internet-Draft K. G. Nagy
Intended status: Informational Apptly Software Ltd
Expires: 20 November 2026 19 May 2026
Taistamp: Signed TAI64N Timestamps over HTTP
draft-mery-nagy-taistamp-00
Abstract
This memo defines Taistamp, an HTTP-accessible service that returns
the current time as a TAI64N label, optionally signed with Ed25519.
The service is reached at the well-known URI /.well-known/taistamp
and is intended for clients that need an authenticated wall-clock
reading without running an NTP stack or relying on the client's own
clock for TLS certificate validation. The signing scheme uses a
length-prefixed, domain-separated framing and publishes verification
keys as DNS TXT records in a DKIM-inspired selector layout.
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."
This Internet-Draft will expire on 20 November 2026.
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.
Mery & Nagy Expires 20 November 2026 [Page 1]
Internet-Draft Taistamp May 2026
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Design Rationale . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Why HTTP . . . . . . . . . . . . . . . . . . . . . . . . 3
2.2. Why DNS-Based Key Discovery . . . . . . . . . . . . . . . 4
2.3. Why TAI64N . . . . . . . . . . . . . . . . . . . . . . . 5
2.4. Why the External Representation . . . . . . . . . . . . . 5
2.5. Why Ed25519 . . . . . . . . . . . . . . . . . . . . . . . 5
2.6. Why Nonce-Based Anti-Replay . . . . . . . . . . . . . . . 6
2.7. Precision Expectations . . . . . . . . . . . . . . . . . 6
2.8. Non-Goals . . . . . . . . . . . . . . . . . . . . . . . . 6
3. Relation to Other Protocols . . . . . . . . . . . . . . . . . 6
4. Conventions and Definitions . . . . . . . . . . . . . . . . . 7
5. Resource . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. Methods . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Cross-Origin Resource Sharing . . . . . . . . . . . . . . 8
5.3. Successful Response . . . . . . . . . . . . . . . . . . . 9
5.4. Nonce Echo . . . . . . . . . . . . . . . . . . . . . . . 10
6. Signing . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Framed Payload . . . . . . . . . . . . . . . . . . . . . 12
6.2. When to Sign . . . . . . . . . . . . . . . . . . . . . . 13
6.3. Intermediary Handling . . . . . . . . . . . . . . . . . . 14
7. Key Publication . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Key Rotation . . . . . . . . . . . . . . . . . . . . . . 15
7.1.1. Verifier Key Caching . . . . . . . . . . . . . . . . 15
7.1.2. Key Revocation . . . . . . . . . . . . . . . . . . . 15
8. Trust Levels . . . . . . . . . . . . . . . . . . . . . . . . 16
9. Verification . . . . . . . . . . . . . . . . . . . . . . . . 16
10. Security Considerations . . . . . . . . . . . . . . . . . . . 17
10.1. Threat Model . . . . . . . . . . . . . . . . . . . . . . 17
10.2. Replay . . . . . . . . . . . . . . . . . . . . . . . . . 17
10.3. Domain Separation . . . . . . . . . . . . . . . . . . . 17
10.4. DNS Trust . . . . . . . . . . . . . . . . . . . . . . . 18
10.5. Clock Manipulation . . . . . . . . . . . . . . . . . . . 18
10.6. Leap-Second Reporting . . . . . . . . . . . . . . . . . 18
10.7. Key Revocation Window . . . . . . . . . . . . . . . . . 18
10.8. Selector-Based DNS Amplification . . . . . . . . . . . . 19
10.9. Caching Intermediaries . . . . . . . . . . . . . . . . . 19
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
11.1. Well-Known URI . . . . . . . . . . . . . . . . . . . . . 20
11.2. Media Type . . . . . . . . . . . . . . . . . . . . . . . 20
11.3. Header Fields . . . . . . . . . . . . . . . . . . . . . 20
12. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
12.1. Normative References . . . . . . . . . . . . . . . . . . 21
12.2. Informative References . . . . . . . . . . . . . . . . . 22
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23
Mery & Nagy Expires 20 November 2026 [Page 2]
Internet-Draft Taistamp May 2026
1. Introduction
Many small clients need an accurate wall-clock reading to validate
certificates, evaluate signature freshness, or stamp local events.
Two common sources fall short:
* An NTP client is intrusive on constrained or sandboxed runtimes
and exposes the device to a separate trust domain.
* TLS does not provide an explicit authenticated time value to the
client; certificate validity checks depend on the client's
existing clock rather than establishing a trustworthy time
reading.
Taistamp addresses these by serving the current time as a 25-byte
TAI64N [TAI64] label over HTTP, with an optional Ed25519 [RFC8032]
signature bound to a client-supplied nonce. Verification keys are
published in DNS as TXT records under a DKIM-style [RFC6376]
selector, so keys can be rotated without coordinating with clients.
The protocol is deliberately small. A compliant implementation fits
in a single HTTP request handler, has no state beyond its signing
key, and is independent of any specific HTTP framework or runtime.
2. Design Rationale
2.1. Why HTTP
HTTP is available everywhere a network connection is. Browsers,
serverless runtimes (Cloudflare Workers, AWS Lambda, Deno Deploy),
edge nodes, and CDN origins can all serve and consume HTTP without
additional infrastructure. Port 443 (or 80) is open where UDP 123
(NTP), UDP 2002 (Roughtime, port assignment pending), and UDP 4014
(TAICLOCK [TAICLOCK]) are commonly firewalled. A compliant Taistamp
server requires nothing beyond a single request handler; a compliant
client requires nothing beyond an HTTP library, both of which exist
in every language and runtime in common use today.
Taistamp works over plain HTTP. The Ed25519 signature provides
authentication and integrity at the application layer, independent of
the transport: any in-transit modification breaks the signature, and
a client-supplied nonce prevents replay. These guarantees apply only
to responses bearing a valid TAI-Signature matching a request TAI-
Nonce. A network attacker who cannot forge the signature can at most
drop or delay responses, which is a denial of service rather than a
security breach.
Mery & Nagy Expires 20 November 2026 [Page 3]
Internet-Draft Taistamp May 2026
TLS [RFC8446] is RECOMMENDED. It adds transport confidentiality
(hiding that a client is querying for time and from which server) and
an additional layer of integrity. Where used, the two layers are
complementary: TLS protects the channel, the Ed25519 signature
protects the claim independently of which certificate authority
issued the server certificate.
The server is stateless beyond its signing key. This is a deliberate
design goal: a stateless handler can be deployed as a CDN edge
function, a serverless worker, or behind a load balancer with no
session affinity or shared state.
Taistamp is transported over TCP-based HTTP, which rules out UDP-
style spoofed-source amplification. The protocol-mandated fields of
a signed response contribute at most approximately 530 bytes at
maximum field lengths, excluding transport framing and any headers
added by intermediaries — the response body is a fixed 25 bytes, and
the protocol-defined headers (TAI-Nonce echo, TAI-Signature, TAI-Key-
Selector, TAI-Leap-Seconds) account for the remainder — an attacker
cannot induce a response meaningfully larger than the request, so
Taistamp is not usable as an amplification vector.
2.2. Why DNS-Based Key Discovery
Roughtime [Roughtime] addresses the same authenticated time problem
but distributes trust differently: clients ship with a configured
list of trusted server public keys. Key rotation therefore requires
a client update or a coordinated key-distribution mechanism outside
the protocol.
Taistamp operators instead publish verification keys as DNS TXT
records under a DKIM-inspired [RFC6376] selector scheme; they rotate
a key by publishing a new TXT record under a new selector and
reconfiguring the server, with no client coordination required. A
client that has cached a signed response can continue to verify it as
long as the TXT record at the old selector remains in DNS. DNSSEC
[RFC4033] protects the key material end-to-end and is strongly
recommended where the operator controls a signed zone.
This approach deliberately trades the ecosystem-level misbehaviour
detection that Roughtime's multi-server cross-checking provides for
simpler, decentralised deployability: any operator with a domain name
and an HTTP endpoint can run a Taistamp server without registering
with a central authority.
Mery & Nagy Expires 20 November 2026 [Page 4]
Internet-Draft Taistamp May 2026
2.3. Why TAI64N
POSIX time and UTC both admit leap seconds, making a given second
ambiguous: a timestamp of 23:59:60 is legal in UTC but meaningless in
most system clocks, which either smear the leap or repeat the last
second. For applications that check certificate validity windows or
evaluate signature freshness, an ambiguous second is a correctness
hazard.
TAI [TAI64] is strictly monotonic. TAI64N encodes TAI seconds and
nanoseconds in a fixed 25-byte ASCII label with no ambiguity at any
leap-second boundary. The TAI-Leap-Seconds header carries the offset
as informational guidance; clients requiring UTC equivalence MUST
source the offset from a trusted table rather than from the server
(see Section 10.6).
2.4. Why the External Representation
TAICLOCK [TAICLOCK] encodes timestamps as 16 bytes of binary TAI64NA
(8 bytes of seconds, 4 of nanoseconds, 4 of attoseconds). Taistamp
instead uses the TAI64N external representation [TAI64]: the ASCII
character @ followed by 16 lowercase hexadecimal digits for the
seconds field and 8 for the nanoseconds field, totalling 25 bytes.
The 9-byte difference over TAICLOCK's binary encoding arises from
three sources: the @ leader (+1 byte), hex-expanding the 8-byte
seconds field to 16 ASCII digits (+8 bytes), and hex-expanding the
4-byte nanoseconds field to 8 ASCII digits (+4 bytes), offset by
dropping the 4-byte attosecond field that TAI64NA carries and TAI64N
omits (−4 bytes).
The choice is driven by the HTTP context. A hex-encoded ASCII label
is trivially inspectable with curl, safe to log as plain text, and
requires no additional encoding in an HTTP response body. The 9-byte
overhead over binary is negligible in an HTTP exchange. Attoseconds
are omitted because no deployed clock provides sub-nanosecond
resolution.
2.5. Why Ed25519
Ed25519 [RFC8032] was chosen for three reasons. First, verification
is fast and keys and signatures are compact: a public key is 32 bytes
and a signature is 64 bytes, keeping the signed response small and
the verification cost negligible on constrained clients. Second,
signing is deterministic — no per-signature random nonce is required,
which removes an entire class of implementation hazard present in
ECDSA. Third, Ed25519 has no negotiable parameters; there is nothing
to downgrade.
Mery & Nagy Expires 20 November 2026 [Page 5]
Internet-Draft Taistamp May 2026
2.6. Why Nonce-Based Anti-Replay
An alternative to a client-supplied nonce would be a server-enforced
freshness window: reject any response older than N seconds. This
approach is circular: it requires the client to have an approximately
correct clock already, which is precisely the precondition Taistamp
is designed to avoid.
A client-supplied nonce breaks the circularity. The client need have
no prior knowledge of the time; it generates an unpredictable value,
sends it in the request, and the server's signature binds the
returned label to that value. A replayed response from an earlier
exchange will carry a different nonce and the signature will not
verify.
2.7. Precision Expectations
The TAI64N format encodes nanoseconds, but server implementations are
commonly limited to millisecond resolution. Runtimes such as
Cloudflare Workers deliberately freeze the clock at the last I/O
boundary as a Spectre mitigation; no sub-millisecond source is
available. Clients SHOULD NOT assume that the nanosecond field
carries sub-millisecond information; in practice the last six decimal
digits of the nanosecond value are often zero.
2.8. Non-Goals
Taistamp does not synchronise or discipline a local clock; callers
MUST treat the returned label as a single measurement subject to
network round-trip uncertainty. It does not protect against a server
operator who deliberately signs an incorrect time: the signature
attests to what the server claimed, not to the accuracy of its clock.
It does not provide confidentiality; TLS [RFC8446] SHOULD be used
when confidentiality of the query or response is required. It is not
a document timestamping service in the sense of RFC 3161 [RFC3161]:
it timestamps moments, not artefacts.
3. Relation to Other Protocols
*TAICLOCK [TAICLOCK]* is D. J. Bernstein's UDP-based TAI64N time
service (IANA port 4014). A client sends a packet between 20 and 256
bytes whose first four bytes are the ASCII string ctai; the server
echoes the packet with the first byte replaced by s and bytes 4–19
replaced with the current time in TAI64NA format. TAICLOCK is the
direct conceptual predecessor of Taistamp: both serve TAI64N
timestamps on demand. Taistamp differs in using HTTP (deployable
over existing HTTPS infrastructure, no dedicated daemon), adding
optional Ed25519 signatures, and publishing keys via DNS rather than
Mery & Nagy Expires 20 November 2026 [Page 6]
Internet-Draft Taistamp May 2026
relying on the transport for integrity.
*RFC 5905 (NTP) [RFC5905]* synchronises a local clock continuously
over UDP, adjusting for network delay across multiple exchanges.
Taistamp makes no attempt to discipline a local clock; it provides a
single authenticated reading that the caller treats as a measurement
subject to one round-trip time.
*RFC 8915 (NTS) [RFC8915]* adds cryptographic authentication to NTP
using TLS for key exchange and AEAD for packet authentication. NTS
inherits NTP's requirement for a dedicated daemon and UDP port 123.
Taistamp targets runtimes where neither is available.
*RFC 3161 (TSP) [RFC3161]* is a document timestamping protocol: a
client submits a hash of a document and receives a signed token
attesting that the document existed at a given time. TSP timestamps
artefacts; Taistamp timestamps moments. The two protocols are
complementary rather than overlapping.
*Roughtime [Roughtime]* is an authenticated time protocol that also
uses Ed25519 signatures and is designed for constrained clients. It
operates over UDP, distributes trust via a configured list of server
public keys, and detects misbehaving servers by comparing timestamps
and accuracy radii across multiple providers. Taistamp is simpler
and more narrowly scoped: a single HTTP endpoint, DNS-based key
discovery, and no ecosystem coordination requirement.
4. 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.
The terms "TAI" and "TAI64N" are used as defined in [TAI64].
The term "selector" is used in the DKIM sense [RFC6376]: an opaque,
host-scoped label that selects one verification key from possibly
many published under the same host.
The term "client" refers to any HTTP agent that fetches the Taistamp
resource at /.well-known/taistamp.
The term "verifier" refers to a client that performs signature
verification on a Taistamp response.
Mery & Nagy Expires 20 November 2026 [Page 7]
Internet-Draft Taistamp May 2026
HTTP field values defined in this document use Structured Field
Values [RFC9651]. Type annotations (Integer, Binary, Token) refer to
the item types defined in that specification.
5. Resource
A Taistamp service is reached at the well-known URI [RFC8615]:
/.well-known/taistamp
A request URI MUST be the exact path above. Query strings, if any,
are ignored by this version of the protocol and MUST NOT change the
response.
5.1. Methods
A server MUST accept GET and HEAD. A server that supports CORS (see
Section 5.2) MUST also accept OPTIONS; a server without CORS support
MAY accept OPTIONS. A server MUST respond 405 Method Not Allowed to
any method it does not accept. The Allow header on a 405 response,
and on a successful OPTIONS response, MUST enumerate the methods the
server accepts ([RFC9110], Section 10.2.1): a server that accepts
OPTIONS emits Allow: GET, HEAD, OPTIONS; one that does not emits
Allow: GET, HEAD.
A HEAD response MUST NOT include a body and MUST carry the same
headers as the corresponding GET response, with the exception that
TAI-Nonce, TAI-Key-Selector, and TAI-Signature MUST NOT be present.
Because the signed payload covers the response body, a signature
cannot be verified without it; HEAD is therefore useful only as a
liveness or configuration probe. Note that this makes HEAD responses
non-equivalent to the corresponding GET response in the sense of
[RFC9110] Section 9.3.2; carrying an unverifiable signature on a
bodyless response would be misleading.
OPTIONS responses MUST NOT carry any TAI-* response header and MUST
NOT be signed.
5.2. Cross-Origin Resource Sharing
A Taistamp server intended for access from browser pages SHOULD
respond to OPTIONS requests with status 200 and the following
headers:
* Access-Control-Allow-Origin: * (or a site-specific origin policy)
* Access-Control-Allow-Methods: GET, HEAD
* Access-Control-Allow-Headers: TAI-Nonce
Mery & Nagy Expires 20 November 2026 [Page 8]
Internet-Draft Taistamp May 2026
* Access-Control-Expose-Headers: TAI-Leap-Seconds, TAI-Nonce, TAI-
Key-Selector, TAI-Signature
* Access-Control-Max-Age: 600 (or a higher operator- chosen value)
A browser making a cross-origin request that includes the TAI-Nonce
header will send an OPTIONS preflight before the actual GET; without
the appropriate Access-Control-* response headers the browser will
block the request. Non-browser clients are unaffected.
Servers SHOULD emit Access-Control-Max-Age with a value of at least
600 seconds. Pre-flight responses carry no per-request data and are
safe to cache for the lifetime of the deployed CORS configuration.
In the absence of this header, browser pre-flight cache lifetimes
diverge significantly across implementations, which may cause a pre-
flight request to precede every cross-origin GET in high-traffic
deployments.
5.3. Successful Response
A successful GET response has status 200 OK and a body consisting of
exactly 25 ASCII bytes: the TAI64N external representation of the
server's current time, formatted per [TAI64]:
'@' hex16(seconds-since-TAI-epoch) hex8(nanoseconds)
where hex16 and hex8 denote 16 and 8 lowercase hexadecimal digits
respectively. The leading @ is literal.
The following headers MUST be present:
+==================+=====================+
| Header | Value |
+==================+=====================+
| Content-Type | application/tai64n |
+------------------+---------------------+
| Content-Length | 25 |
+------------------+---------------------+
| Cache-Control | no-store |
+------------------+---------------------+
| TAI-Leap-Seconds | sf-integer, e.g. 37 |
+------------------+---------------------+
Table 1
TAI-Leap-Seconds carries the offset, in seconds, between TAI and UTC
at the moment of the response, as a Structured Field Integer
[RFC9651]. leap-seconds emitted MUST be a non-negative integer in [0,
2^32−1]; sf-integer supports values up to ±10^15 but values outside
Mery & Nagy Expires 20 November 2026 [Page 9]
Internet-Draft Taistamp May 2026
[0, 2^32−1] cannot be encoded in leap-u32be. A verifier that
receives a TAI-Leap-Seconds value outside this range MUST treat the
response as unsigned. Its value is included in the signed payload as
leap-u32be (see Section 6.1). A server MUST emit it on every
successful response. It is a singleton field (Section 5.5 of
[RFC9110]) and MUST NOT appear more than once in a response. A
recipient that encounters more than one instance MUST treat the field
as absent per Section 4.2 of [RFC9651]; the recipient then has no
server-supplied TAI-to-UTC offset for this response and MUST treat
the response as unsigned regardless of whether TAI-Signature is
present.
5.4. Nonce Echo
A client MAY send a request header TAI-Nonce carrying an opaque byte
string encoded as a Structured Field Binary [RFC9651]. If present on
a GET request, the server MUST include a TAI-Nonce response field
whose sf-binary value encodes the same octet sequence as the request
field. TAI-Nonce is a singleton field (Section 5.5 of [RFC9110]) and
MUST NOT appear more than once in a request or response. A recipient
that encounters more than one instance MUST treat the field as absent
per Section 4.2 of [RFC9651]. A server that treats a request TAI-
Nonce as absent for this reason MUST NOT sign the response. A server
MAY instead respond with 400 Bad Request when a request contains
duplicate TAI-Nonce fields. A client that treats a response TAI-
Nonce as absent MUST treat the response as unsigned regardless of
whether TAI-Signature is present.
A server MUST NOT interpret the nonce. If a server receives a TAI-
Nonce that is a malformed sf-binary it MUST treat the field as absent
and MUST NOT sign the response. The decoded sf-binary value MUST
contain at least 7 octets and MUST NOT exceed 129 octets. When
serialized as sf-binary, these correspond exactly to field values of
14 octets (: + 12 base64 + padding + :) and 174 octets (: + 172
base64 + :) respectively; implementations MAY reject on wire length
before decoding as an optimisation, but the normative check is on
decoded length.
The lower bound of 7 decoded octets provides sufficient client-
supplied entropy for the replay defence in this section. The upper
bound of 129 decoded octets caps the nonce's contribution to overall
response size; combined with the 25-byte body and the other protocol-
defined response headers, the protocol-mandated fields contribute at
most approximately 530 bytes in total, excluding transport framing
and intermediary-added headers. Implementations that require larger
nonces for compatibility with a higher-entropy convention may
negotiate a future extension; this version of the protocol holds the
bounds fixed for interoperability.
Mery & Nagy Expires 20 November 2026 [Page 10]
Internet-Draft Taistamp May 2026
A server that receives a TAI-Nonce outside this range MUST NOT sign
the response. A zero-length or syntactically empty field value is
below the minimum and MUST be treated as absent. Clients SHOULD
choose nonces that are unpredictable to a network observer when
freshness matters; 16 random bytes encoded as an sf-binary value are
sufficient for typical use.
When a client included a TAI-Nonce in the request, the trust level of
the response is determined as follows. If the response carries no
TAI-Nonce field, the response is Plain (level 0) regardless of
whether a signature is present; a conformant server only signs
responses that echo a nonce (see Section 6), so any signature in such
a response MUST be ignored. If the response carries a TAI-Nonce
whose decoded octets do not match the request nonce, the response is
Inconsistent (level -1) and MUST be rejected regardless of signature
state. If the response carries a TAI-Nonce whose decoded octets
match the request nonce, the trust level depends on the key/signature
state as defined in Section 8. The key/signature state is
Unresolvable when TAI-Key-Selector is malformed or present but does
not resolve in DNS. These cases are summarised in the following
table.
+----------------+---------+--------------+--------------+-------+
| Response nonce | Matches | Key/Sig | Outcome | Level |
+----------------+---------+--------------+--------------+-------+
| Absent | N/A | Any | Plain | 0 |
| Present | No | Any | Inconsistent | -1 |
| Present | Yes | Absent | Unique | 1 |
| Present | Yes | Malformed | Unique | 1 |
| Present | Yes | Unresolvable | Unique | 1 |
| Present | Yes | Invalid | Inconsistent | -1 |
| Present | Yes | Valid | Signed | 2 |
+----------------+---------+--------------+--------------+-------+
Figure 1: Client trust level by response nonce and key/signature
state.
A network attacker who strips the TAI-Nonce from the outgoing request
causes the server to respond at level 0. A client that requires
level 1 or above treats this as a denial of service; a client that
accepts level 0 receives no freshness guarantee.
6. Signing
A Taistamp service MAY be configured with an Ed25519 [RFC8032]
signing key and a selector. When both are configured, the server
signs every response that carries a TAI-Nonce.
Mery & Nagy Expires 20 November 2026 [Page 11]
Internet-Draft Taistamp May 2026
A signed successful response carries two additional headers:
+==================+========================================+
| Header | Value |
+==================+========================================+
| TAI-Key-Selector | the selector, as an sf-token |
+------------------+----------------------------------------+
| TAI-Signature | the Ed25519 signature, as an sf-binary |
+------------------+----------------------------------------+
Table 2
The selector MUST match the following ABNF production [RFC5234]. The
grammar is constrained to the subset of DNS LDH labels ([RFC1035]
Section 2.3.1) that are also valid sf-tokens ([RFC9651]); the
leading-ALPHA requirement follows from sf-token, not from DNS alone,
because sf-token requires its first character to be ALPHA or *
([RFC9651] Section 4.1.7), excluding digit-leading labels that DNS
would otherwise permit:
selector = ALPHA [ *61( ALPHA / DIGIT / "-" )
( ALPHA / DIGIT ) ]
TAI-Key-Selector is a singleton field (Section 5.5 of [RFC9110]) and
MUST NOT appear more than once in a response. A recipient that
encounters more than one instance MUST treat the field as absent per
Section 4.2 of [RFC9651]; the response MUST then be treated as
unsigned.
TAI-Signature is a singleton field (Section 5.5 of [RFC9110]) and
MUST NOT appear more than once in a response. A recipient that
encounters more than one instance MUST treat the field as absent per
Section 4.2 of [RFC9651]; the response MUST then be treated as
unsigned.
A response that carries TAI-Signature without TAI-Key-Selector MUST
be treated as unsigned; the absent selector yields key/signature
state Absent, as if no signature were present.
6.1. Framed Payload
The signed payload is the concatenation, in order, of the following
fields:
Mery & Nagy Expires 20 November 2026 [Page 12]
Internet-Draft Taistamp May 2026
domain-tag = "taistamp-v1" %x00
label-bytes = 25 octets ; the response body
leap-u32be = 4 octets ; TAI-Leap-Seconds,
; big-endian unsigned
selector-len = 1 octet ; length of selector-bytes, 1..63
selector-bytes = 1..63 octets ; the selector, ASCII
nonce-bytes = octets ; decoded sf-binary octets
; of the TAI-Nonce field value
payload = domain-tag label-bytes leap-u32be
selector-len selector-bytes nonce-bytes
nonce-bytes is the octet sequence obtained by parsing the TAI-Nonce
field value as an sf-binary item per [RFC9651] and decoding the
base64 value. The textual representation of the field is not part of
the signed input; only the decoded bytes are signed.
The trailing NUL on domain-tag is significant: it prevents extension
of the tag into adjacent bytes by an attacker who controls the
protocol version string.
The selector is length-prefixed by a single byte. A downgrade
attacker who rewrites TAI-Key-Selector on the wire cannot match an
existing signature without also matching its length, as the signature
is bound to the exact payload including the length byte; forging a
valid signature for a different selector length is computationally
infeasible under the existential unforgeability of Ed25519.
The nonce occupies the tail of the payload. Its length is therefore
self-delimiting: a verifier computes nonce-bytes from the decoded
TAI-Nonce sf-binary value and appends it as the final payload
component, with no explicit length field required.
6.2. When to Sign
A server MUST sign a response if and only if all of the following
hold:
* The server is configured with a key and selector.
* The request carried a TAI-Nonce header.
* The response is a 200 to GET.
A request without a nonce MAY receive an unsigned response even when
the server is configured to sign. This allows lightweight unsigned
probes to coexist with authenticated reads, though the response
itself MUST remain Cache-Control: no-store because the label is time-
sensitive.
Mery & Nagy Expires 20 November 2026 [Page 13]
Internet-Draft Taistamp May 2026
6.3. Intermediary Handling
An intermediary (proxy or gateway) that forwards a Taistamp request
or response MUST forward the TAI-Nonce, TAI-Leap-Seconds, TAI-Key-
Selector, and TAI-Signature fields intact and MUST NOT modify or
remove them. Stripping or rewriting TAI-Nonce on a request prevents
the server from signing the response. Stripping or rewriting any of
the response fields prevents the client from verifying the signature.
These requirements apply to Taistamp-aware intermediaries. General-
purpose proxies that do not recognise TAI-* fields may strip or
modify them without violating their own specifications. Operators
who require signed responses SHOULD avoid placing non-transparent
intermediaries between client and server, or verify that any
intermediaries are configured to forward these fields intact.
7. Key Publication
This section applies only to servers configured with a signing key
and selector.
A server publishes its verification key as a DNS TXT record. The
owner name is
<selector> "._taistamp." <host>
where <host> is the authority component of the URL at which /.well-
known/taistamp is served, and <selector> is the value the server
emits in TAI-Key-Selector.
The TXT record value is a single string, of length at most 255
octets, formatted as a tag-value list in the DKIM/DMARC style:
v=tai1; k=ed25519; p=<base64-of-32-raw-pubkey-bytes>
+=====+==========================================================+
| Tag | Value |
+=====+==========================================================+
| v | Protocol version. tai1 for the framing in this document. |
+-----+----------------------------------------------------------+
| k | Key algorithm. ed25519 is the only algorithm currently |
| | defined. |
+-----+----------------------------------------------------------+
| p | Public key, standard base64 of the 32 raw Ed25519 public |
| | key bytes. |
+-----+----------------------------------------------------------+
Table 3
Mery & Nagy Expires 20 November 2026 [Page 14]
Internet-Draft Taistamp May 2026
Parsing is done as specified in Section 3.2 of [RFC6376]. A verifier
MUST treat unknown tags as informational. A verifier MUST treat an
unknown v or k as an unrecoverable failure for that selector and MUST
NOT fall back silently.
7.1. Key Rotation
Key rotation follows a publish-then-switch-then-retire sequence.
Operators SHOULD choose a DNS TTL for the TXT record that balances
query load against key rotation speed. A TTL between 3600 seconds (1
hour) and 86400 seconds (24 hours) is RECOMMENDED for stable keys.
When an operator plans to rotate a key, they SHOULD lower the TTL of
the existing TXT record well in advance of the rotation to ensure
that verifier caches clear quickly once the new key is deployed.
*Publish.* The operator publishes a new TXT record under a new
selector and waits at least one DNS TTL interval for propagation
before reconfiguring the server.
*Switch.* The server is reconfigured to sign responses with the new
key and selector.
*Retire.* The old TXT record SHOULD remain in DNS for at least one
DNS TTL interval after the switch, to allow verifiers that cached the
old record to complete any in-flight verification. The old TXT
record MAY then be removed.
7.1.1. Verifier Key Caching
A verifier MAY cache the parsed public key for a selector. Verifiers
MUST respect the DNS TTL returned by the resolver and MUST NOT use a
cached entry beyond that TTL. Verifiers MUST NOT apply a hardcoded
minimum or maximum cache lifetime that overrides the TTL set by the
authoritative operator. If verification of a cached key fails, the
verifier SHOULD re-fetch the TXT record once before treating the
signature as invalid.
7.1.2. Key Revocation
If a signing key is compromised, the operator MUST remove its TXT
record immediately, without a retirement period. Removing the TXT
record is the only revocation mechanism defined by this protocol; no
out-of-band revocation channel is specified.
Verifiers that have cached the public key will continue to accept
signatures made with it until their cached entry's DNS TTL expires.
The exposure window is therefore bounded by the TTL remaining on the
Mery & Nagy Expires 20 November 2026 [Page 15]
Internet-Draft Taistamp May 2026
cached entry at the moment of revocation. Operators who require
rapid revocation SHOULD configure a short TTL on key records,
accepting the trade-off of increased DNS query load.
8. Trust Levels
A Taistamp response is assigned one of four trust levels, combining
the nonce echo result and the key/signature state.
*Level 2 — Signed.* The response TAI-Nonce matches the request nonce
and the TAI-Signature verifies against the public key resolved from
TAI-Key-Selector. The time value is both fresh and authenticated.
*Level 1 — Unique.* The response TAI-Nonce matches the request nonce,
but the signature is absent, the TAI-Key-Selector is malformed, or
the TAI-Key-Selector does not resolve in DNS. The time value is
fresh but unauthenticated. A malformed or unresolvable selector
indicates a configuration error or that the signing key has not yet
propagated in DNS; this is a soft degradation, not a failure.
*Level 0 — Plain.* The response carries no echoed TAI-Nonce. The
time value carries no freshness or authentication guarantee from this
protocol.
*Level -1 — Inconsistent.* Either the response TAI-Nonce is present
but does not match the request nonce, or the TAI-Key-Selector
resolves but the TAI-Signature does not verify. The response MUST be
rejected.
A client MUST NOT use a response at trust level -1. Whether a client
accepts level 0 or level 1 when a higher level is expected is an
application policy decision outside the scope of this document.
9. Verification
This section applies when the response carries both TAI-Key-Selector
and TAI-Signature. A verifier reads the response and reconstructs
the framed payload as defined in Section 6. The verifier MUST:
1. Confirm that the decoded sf-binary octets of the response TAI-
Nonce match those of the request TAI-Nonce.
2. Confirm that the TAI-Key-Selector value is a well-formed selector
matching the ABNF in Section 6.
3. Resolve the TXT record at <selector>._taistamp.<host> and parse
the v, k, and p tags.
4. Verify the Ed25519 signature using the public key from p over the
framed payload.
Mery & Nagy Expires 20 November 2026 [Page 16]
Internet-Draft Taistamp May 2026
Each step produces a trust level outcome. If step 1 fails (nonce
mismatch), the response is Inconsistent (level -1) and MUST be
rejected. If step 2 fails (malformed selector) or step 3 yields no
DNS record (unresolvable selector), signature verification stops and
the response is Unique (level 1). If step 4 fails (signature does
not verify), the response is Inconsistent (level -1) and MUST be
rejected. If all four steps succeed, the response is Signed (level
2). Trust levels are defined in Section 8.
Verifiers MUST use the strict verification procedure described in
Section 5.1.7 of [RFC8032].
10. Security Considerations
10.1. Threat Model
Taistamp authenticates a single time reading at the moment a client
asks. It does not establish a long- running synchronised clock and
does not bound network delay; a client is responsible for treating
the returned label as a measurement subject to the round-trip time of
its request. The trust level framework (see Section 8) expresses the
combined freshness and authentication guarantees that a response
carries.
10.2. Replay
A response is bound to its request only via the TAI-Nonce echo and
its inclusion in the signed payload. A client that omits the nonce
receives a Plain (level 0) response with no freshness guarantee. A
client that reuses a nonce across requests gains no replay protection
even at level 1 or 2, since the nonce no longer uniquely identifies
the exchange. Clients SHOULD generate a fresh, unpredictable nonce
for each request.
Replay protection is scoped to the client's own nonce uniqueness
enforcement. The protocol does not prevent a recorded request/
response pair from being presented to a second application that does
not track nonce lifecycle. Clients SHOULD treat each Unique (level
1) or Signed (level 2) response as valid for a single use and SHOULD
NOT accept a response whose nonce was issued by a previous request.
10.3. Domain Separation
The taistamp-v1%x00 prefix prevents an Ed25519 key configured for
Taistamp from being induced to sign a message valid under another
protocol that happens to embed the same suffix. Operators MUST NOT
reuse a Taistamp signing key for any other purpose.
Mery & Nagy Expires 20 November 2026 [Page 17]
Internet-Draft Taistamp May 2026
10.4. DNS Trust
A Signed (level 2) response reduces to trusting the DNS lookup of the
TXT record at <selector>._taistamp.<host>. A verifier that does not
validate DNS responses (for instance via DNSSEC or a trusted resolver
path) is vulnerable to a DNS attacker who can substitute a public key
and then sign responses with the corresponding private key, producing
a forged time value that verifies successfully. Unlike DKIM, where
key substitution causes verification failures, here it enables
complete spoofing. Without authenticated DNS, a response that
appears Signed (level 2) provides no stronger guarantee than Unique
(level 1). A Unique (level 1) response does not involve DNS key
resolution and is therefore not subject to this attack, though it
provides no key authentication.
Operators SHOULD publish under a DNSSEC-signed zone. Verifiers
SHOULD validate DNSSEC signatures or use a resolver path that
provides equivalent guarantees.
10.5. Clock Manipulation
A signature attests that the server emitted a given label; it does
not attest that the server's clock is correct. An operator whose
clock is drifting or deliberately set wrong will sign whatever label
its clock produces. Clients that depend on Taistamp for high-stakes
decisions SHOULD compare readings from multiple independently
operated services.
10.6. Leap-Second Reporting
The TAI-Leap-Seconds header is included in the signed payload as
leap-u32be; the signature attests that the server emitted this
specific value, but not that it is correct. Signing it allows the
verifier to reconstruct the server's own UTC interpretation of the
timestamp, even though the verifier need not trust that value for UTC
conversion purposes. An operator whose leap-second table is wrong,
or who deliberately sets it wrong, will sign whatever count they
emit. Clients who require UTC equivalence MUST source the TAI-to-UTC
offset from a trusted table rather than from the server.
10.7. Key Revocation Window
When a TXT record is deleted to revoke a compromised key, verifiers
that have cached the corresponding public key will continue to assign
Signed (level 2) to responses made with that key until their cached
entry's DNS TTL expires. An attacker in possession of the
compromised private key can forge responses during this window; the
forged signatures will verify against the cached key, assigning
Mery & Nagy Expires 20 November 2026 [Page 18]
Internet-Draft Taistamp May 2026
Signed (level 2) when the correct assignment — given the revoked key
— would be Unique (level 1) at best.
The exposure window is bounded by the DNS TTL remaining on the cached
entry at the moment of revocation. Verifiers that honour the TTL
limit required by Section 7.1.1 will naturally limit this window to
at most one TTL interval. Operators who require a short revocation
window SHOULD configure a low DNS TTL on key records.
10.8. Selector-Based DNS Amplification
A verifier that performs one DNS lookup per incoming response
carrying a selector that is malformed or does not resolve
(Unresolvable key/signature state, yielding Unique (level 1) per
Section 8) amplifies query load onto the authoritative server
publishing the _taistamp.<host> TXT records. Two cases arise: a
cached key that fails verification triggers a re-fetch per
Section 7.1.1; a previously unseen selector triggers a first-time
lookup, which the per-name re-fetch limit does not bound. Verifiers
MUST apply rate-limiting or exponential back-off on all DNS lookups
for names under _taistamp.<host>, regardless of whether the lookup is
a first fetch or a re-fetch.
10.9. Caching Intermediaries
Note: this section is non-normative.
Successful GET responses carry Cache-Control: no-store (see
Section 5.3), which instructs intermediaries not to retain or serve
the response from cache. However, CDN and proxy configurations
sometimes override this directive, for instance via path-based cache
rules that match /.well-known/ resources. A client that included a
TAI-Nonce is protected: a cached response carries a different nonce,
producing Inconsistent (level -1), which MUST be rejected. A client
that did not include a TAI-Nonce receives a Plain (level 0) response
with no indication that the time value is stale.
Operators deploying Taistamp behind a CDN or reverse proxy SHOULD
explicitly configure the intermediary to pass GET responses to
/.well-known/taistamp through without caching, and SHOULD verify this
behaviour before relying on Signed (level 2) responses for time-
sensitive decisions.
11. IANA Considerations
Mery & Nagy Expires 20 November 2026 [Page 19]
Internet-Draft Taistamp May 2026
11.1. Well-Known URI
IANA is requested to register the following entry in the "Well-Known
URIs" registry [RFC8615]:
+=====================+=====================+
| Field | Value |
+=====================+=====================+
| URI Suffix | taistamp |
+---------------------+---------------------+
| Change Controller | Apptly Software Ltd |
+---------------------+---------------------+
| Reference | This document |
+---------------------+---------------------+
| Status | permanent |
+---------------------+---------------------+
| Related Information | none |
+---------------------+---------------------+
Table 4
11.2. Media Type
IANA is requested to register the media type application/tai64n in
the "Media Types" registry per [RFC6838]:
* Type name: application
* Subtype name: tai64n
* Required parameters: none
* Optional parameters: none
* Encoding considerations: 7-bit (ASCII)
* Security considerations: see Section 10
* Interoperability considerations: none
* Published specification: this document
* Applications that use this media type: time- authentication
clients
* Fragment identifier considerations: none
* Restrictions on usage: none
* Provisional registration: no
* Author/Change controller: Apptly Software Ltd
11.3. Header Fields
IANA is requested to register the following entries in the "Hypertext
Transfer Protocol (HTTP) Field Name Registry" [RFC9110]:
Mery & Nagy Expires 20 November 2026 [Page 20]
Internet-Draft Taistamp May 2026
+==================+===========+=================+===============+
| Field Name | Status | Structured Type | Reference |
+==================+===========+=================+===============+
| TAI-Leap-Seconds | permanent | Integer | this document |
+------------------+-----------+-----------------+---------------+
| TAI-Nonce | permanent | Binary | this document |
+------------------+-----------+-----------------+---------------+
| TAI-Key-Selector | permanent | Token | this document |
+------------------+-----------+-----------------+---------------+
| TAI-Signature | permanent | Binary | this document |
+------------------+-----------+-----------------+---------------+
Table 5
12. References
12.1. Normative References
[RFC1035] Mockapetris, P., "Domain names - implementation and
specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
November 1987, <https://www.rfc-editor.org/info/rfc1035>.
[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/info/rfc2119>.
[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.
[RFC6376] Crocker, D., Ed., Hansen, T., Ed., and M. Kucherawy, Ed.,
"DomainKeys Identified Mail (DKIM) Signatures", STD 76,
RFC 6376, DOI 10.17487/RFC6376, September 2011,
<https://www.rfc-editor.org/info/rfc6376>.
[RFC8032] Josefsson, S. and I. Liusvaara, "Edwards-Curve Digital
Signature Algorithm (EdDSA)", RFC 8032,
DOI 10.17487/RFC8032, January 2017,
<https://www.rfc-editor.org/info/rfc8032>.
[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/info/rfc8174>.
Mery & Nagy Expires 20 November 2026 [Page 21]
Internet-Draft Taistamp May 2026
[RFC8615] Nottingham, M., "Well-Known Uniform Resource Identifiers
(URIs)", RFC 8615, DOI 10.17487/RFC8615, May 2019,
<https://www.rfc-editor.org/info/rfc8615>.
[RFC9651] Nottingham, M. and P. Kamp, "Structured Field Values for
HTTP", RFC 9651, DOI 10.17487/RFC9651, September 2024,
<https://www.rfc-editor.org/info/rfc9651>.
[TAI64] Bernstein, D. J., "TAI64, TAI64N, and TAI64NA", 1997,
<https://cr.yp.to/libtai/tai64.html>.
12.2. Informative References
[RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato,
"Internet X.509 Public Key Infrastructure Time-Stamp
Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August
2001, <https://www.rfc-editor.org/info/rfc3161>.
[RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S.
Rose, "DNS Security Introduction and Requirements",
RFC 4033, DOI 10.17487/RFC4033, March 2005,
<https://www.rfc-editor.org/info/rfc4033>.
[RFC5905] Mills, D., Martin, J., Ed., Burbank, J., and W. Kasch,
"Network Time Protocol Version 4: Protocol and Algorithms
Specification", RFC 5905, DOI 10.17487/RFC5905, June 2010,
<https://www.rfc-editor.org/info/rfc5905>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.
[RFC8446] Rescorla, E., "The Transport Layer Security (TLS) Protocol
Version 1.3", RFC 8446, DOI 10.17487/RFC8446, August 2018,
<https://www.rfc-editor.org/info/rfc8446>.
[RFC8915] Franke, D., Sibold, D., Teichel, K., Dansarie, M., and R.
Sundblad, "Network Time Security for the Network Time
Protocol", RFC 8915, DOI 10.17487/RFC8915, September 2020,
<https://www.rfc-editor.org/info/rfc8915>.
[RFC9110] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
Ed., "HTTP Semantics", STD 97, RFC 9110,
DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.
Mery & Nagy Expires 20 November 2026 [Page 22]
Internet-Draft Taistamp May 2026
[Roughtime]
Ladd, W. and M. Dansarie, "Roughtime", 2026,
<https://datatracker.ietf.org/doc/draft-ietf-ntp-
roughtime/>. Aanchal Malhotra and Adam Langley authored
early drafts of this document.
[TAICLOCK] Bernstein, D. J., "TAICLOCK", 1997,
<https://cr.yp.to/proto/taiclock.txt>.
Authors' Addresses
Alejandro Mery
Apptly Software Ltd
Email: amery@apptly.co
URI: https://apptly.co
Károly Gábriel Nagy
Apptly Software Ltd
Email: nagy.karoly@apptly.co
URI: https://apptly.co
Mery & Nagy Expires 20 November 2026 [Page 23]