| Internet-Draft | ProtectChain | September 2026 |
| Tempobono, et al. | Expires 14 March 2027 | [Page] |
This document specifies ProtectChain, a permissioned, hash-chained and cryptographically signed ledger whose purpose is to produce verifiable evidence that a given digital work already existed no later than a given point in time, under an authorship claim made by an identified account.¶
ProtectChain records only cryptographic digests and pseudonymous identifiers; the work itself never enters the ledger. Because all initial authorities may be operated by a single organization, every block is also anchored to independent public time references, so that the upper bound on a record's date does not rest on the operator's assertion.¶
This document is deliberately explicit about the limits of the evidence produced: an anchor establishes that data existed no later than a given instant; it does not establish the exact instant of creation, nor does it establish authorship or originality.¶
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 14 March 2027.¶
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.¶
Under the Berne Convention [BERNE] and most national legislation, copyright arises automatically upon creation of a work; registration is not a condition of protection. The practical difficulty is therefore not obtaining the right, but proving, in a later dispute, that a particular work existed at a particular time and was claimed by a particular party.¶
Services that produce such evidence are common. Their recurring weakness is that the recorded date rests entirely on the provider's own database and clock: an operator could, in principle, insert a record and assert an earlier date for it.¶
ProtectChain addresses that weakness by combining three mechanisms:¶
The work itself is never transmitted to or stored in the ledger. Only digests and pseudonymous identifiers are recorded, which keeps the confidentiality of the work independent of the number of participants in the network.¶
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.¶
A record carries the SHA-256 and SHA-512 digests of the work, an opaque reference to the submitting account, an optional declared creation date, an optional certificate code, and the instant at which the node received it.¶
Implementations MUST NOT place the content of the work, or any direct personal data, in a record. The record identifier is computed as the SHA-256 of the following canonical form, with fields separated by a single LF character (0x0A):¶
record_hash = SHA-256(
"record" LF
node_id LF
work_ref LF
sha256 LF
sha512 LF
declared_at LF
received_at LF
cert_code )
¶
Absent optional fields are represented as the empty string. All digests are lowercase hexadecimal.¶
A block links to its predecessor and commits to the records it contains:¶
block_hash = SHA-256(
"block" LF
index LF
prev_hash LF
merkle_root LF
created_at LF
node_id LF
record_count )
signature = Ed25519-Sign(sealer_private_key, block_hash)
¶
The genesis block has index 1, a prev_hash of sixty-four ASCII zeros, and no records. Signatures use Ed25519 [RFC8032] and are computed over the lowercase hexadecimal representation of block_hash.¶
A naive Merkle construction that duplicates the final element when a level holds an odd number of nodes admits distinct record sets that produce identical roots. Implementations MUST therefore use domain separation between leaves and interior nodes, in the spirit of [RFC9162]:¶
leaf(h) = SHA-256( 0x00 || h ) node(a, b) = SHA-256( 0x01 || a || b ) empty list = SHA-256( 0x00 )¶
The prefixes 0x00 and 0x01 are single octets, and
h, a and b are the 32-octet binary digests, not their hexadecimal
encodings. When a level holds an odd number of nodes, the final element
MUST be promoted unchanged to the next level; it
MUST NOT be duplicated or paired with itself. The root is
published in lowercase hexadecimal.¶
Only authorities produce and validate blocks. Each node publishes the authority list, so that any verifier can determine which keys may legitimately co-sign. There is no mining and no proof of work; the identity of operators is known and auditable.¶
Before co-signing, a validator MUST verify, on its own and without taking any value from the sender on trust, that:¶
A validator that merely echoed what it received would add no evidence. It is the independent recomputation that gives a co-signature meaning: a block carrying N signatures indicates that N machines, in distinct locations, independently reached the same result.¶
A validator replicates the chain; it MUST NOT maintain a competing one. Upon receiving a block whose predecessor it does not hold, it MUST obtain the missing blocks from an authority and revalidate each one before adopting it. Data arriving over the network is never adopted on trust, even when it originates from an authority.¶
Consequently, only the sealer creates the genesis block. A validator that created its own genesis would diverge on prev_hash and reject the legitimate chain.¶
A validator stores only record_hash values, which suffice to recompute the Merkle root and to serve inclusion proofs, without ever holding the work.¶
Quorum is the simple majority of active authorities, counting the sealer's own signature.¶
| Authorities | Quorum | Tolerated failures |
|---|---|---|
| 1 | 1 | 0 |
| 2 | 2 | 0 |
| 3 | 2 | 1 |
| 4 | 3 | 1 |
| 5 | 3 | 2 |
A block that has not yet reached quorum is not invalid; it is less corroborated. It remains chained, signed and publicly anchored. This distinction is deliberate: the evidence available to a submitter MUST NOT depend on the availability of third parties.¶
Recording a work and obtaining consensus are distinct, asynchronous operations.¶
Authorities are expected to sit behind network address translation in distinct sites, and connectivity between peers may be asymmetric or intermittent. This specification treats that as normal rather than exceptional:¶
Because all initial authorities may belong to a single operator, each block is additionally committed to public references that the operator does not control.¶
Implementations SHOULD obtain a time-stamp token over block_hash from one or more independent Time-Stamping Authorities as defined in [RFC3161]. This yields an immediate signed upper bound on the block's date.¶
Implementations SHOULD additionally commit block_hash to a public distributed ledger whose history the operator cannot rewrite, using an aggregation scheme so that many commitments share a single ledger transaction. Such proofs are inherently asynchronous: they mature only when the underlying ledger confirms. Until then, the immediate guarantee is provided by Section 4.1.¶
Nodes SHOULD discipline their clocks against authoritative time sources using NTP [RFC5905]. Clock accuracy serves precision and record-keeping; the property that makes a date assertable against third parties comes from the anchors, not from the local clock. A well-disciplined clock narrows, but does not eliminate, the window described in Section 5.3.¶
This section is deliberately explicit. A specification about evidence loses credibility if it overstates what it proves. Implementations and accompanying materials MUST NOT claim more than what is described here.¶
An anchor over block_hash demonstrates, verifiably by third parties and without relying on the operator's assertion, that the block -- and, by Merkle inclusion, every record within it -- already existed no later than the instant of the anchor. Because record_hash incorporates the digests of the submitted file, this is equivalent to demonstrating that a file with exactly that content already existed by that instant.¶
Between the created_at value written into a block and the instant of anchoring there is a window within which the accuracy of the date depends on the operator's honesty. A dishonest operator cannot backdate a record beyond the anchor, since the anchor is always later; it could, within the window, declare a created_at slightly earlier than reality.¶
Mitigations:¶
Recording early is what creates value: the evidence is as strong as its earliest anchor is old. No technology can retroactively demonstrate that data is older than its first anchor.¶
The following table summarizes what does and does not reach the ledger.¶
| Data | Enters the ledger |
|---|---|
| The work itself | Never |
| SHA-256 / SHA-512 of the work | Yes |
| Work and certificate identifiers, dates | Yes |
| Submitter identity | Only as an opaque pseudonymous reference |
| Name, e-mail, documents, address | Never |
Identifiers recorded in the ledger are pseudonymous, not anonymous: alone they reveal nothing, but they can be relinked to a person by whoever holds the operator's account database. Implementations MUST NOT place direct personal data in the ledger, nor any metadata that identifies a person on its own.¶
Deployments subject to data protection regimes that grant a right to erasure face a known tension with append-only, anchored records. The approach taken here is minimization and unlinking rather than deletion: personal data resides exclusively outside the ledger and remains erasable; once the link between the pseudonymous reference and the person is destroyed, the ledger entry retains only an irreversible digest and opaque identifiers. Submitters MUST be informed, before recording, that digests and pseudonymous identifiers are written permanently.¶
A candidate authority MUST satisfy the following. None of these is ceremonial; each exists so that the candidate's co-signature carries meaning.¶
Admission proceeds by request, review, network provisioning, a probation period during which the candidate replicates and revalidates the chain without co-signing, and finally addition of its public key to the authority list, at which point quorum is recomputed.¶
Removal of an authority MUST be possible at any time and consists of withdrawing its public key from the authority list. Revocation MUST NOT invalidate blocks the authority previously co-signed: each signature remains verifiable against the key that produced it, and the date remains supported by the anchors. Revocation applies prospectively.¶
What authorizes a block is the Ed25519 signature of the authority that sealed it, verified against the authority list. No transport credential substitutes for that: a block carrying an invalid signature is rejected even when it arrives over a perfectly authenticated channel.¶
Calls between authorities MUST be authenticated by the Ed25519 signature of the issuing node, verified against the authority list. Shared secrets MUST NOT be used between authorities, because they make an individual participant neither distinguishable nor revocable.¶
Each request carries the issuing node identifier, a timestamp, a nonce and a signature over the canonical form:¶
SHA-256 of the request body is included, so the signature binds
who, what, where, when, and the exact payload:
"pcauth-v1" LF
node_id LF
METHOD LF
path LF
timestamp LF
nonce LF
SHA-256(body)
¶
A receiver MUST reject requests outside a bounded clock tolerance, MUST require the issuer to be an active authority, MUST verify the signature against the registered public key, and MUST reject reuse of a nonce within the tolerance window. A tolerance of 300 seconds is RECOMMENDED.¶
Confidentiality of the work. The work never enters the ledger (Section 6). Adding authorities therefore widens corroboration without widening exposure of content.¶
Backdating. Anchoring prevents assigning a record a date earlier than its anchor. The residual window between created_at and anchoring is addressed in Section 5.3. Implementations that omit anchoring reduce the guarantee to the operator's assertion.¶
Merkle malleability. Domain separation (Section 2.3) prevents distinct record sets from yielding the same root, and promotion of the odd element removes the ambiguity introduced by duplication.¶
Compromise of a sealer key. An attacker holding a sealer's private key could forge new blocks, but could not alter blocks already anchored, since their digests are committed externally. Key rotation MUST be recorded in the chain, and quorum limits the damage: forged blocks would fail independent validation by other authorities.¶
Equivocation. A validator MUST NOT co-sign two distinct blocks at the same index; implementations MUST keep persistent state sufficient to detect this across restarts.¶
Replay. Inter-node authentication binds method, path, timestamp, nonce and body digest (Section 8). Without nonce rejection, a captured request could be replayed within the clock tolerance.¶
Digest strength. Evidence rests on SHA-256 and SHA-512 [RFC6234] jointly; a forgery would require simultaneous collisions in both with semantically useful content. Should either function be weakened, deployments will need a migration path that re-anchors existing records under a stronger function; this document does not specify one.¶
Availability is not integrity. Loss of quorum reduces corroboration but never causes acceptance of an invalid block. Conversely, a reachable but dishonest authority cannot cause an invalid block to be accepted by honest validators, since each validates independently.¶
Transport. Private, authenticated and encrypted transport between authorities is defence in depth, not the foundation of the evidence: a forged block would be rejected by signature and chaining checks regardless of the channel. Deployments concerned with long-term confidentiality of consensus traffic SHOULD select transports offering protection against future cryptanalytic advances, including those enabled by quantum computation.¶
Legal weight. The evidence produced is one element of proof, subject to evaluation by the relevant forum. It is not an absolute legal presumption in any jurisdiction, and it does not replace official registration where such registration carries specific effects.¶
This document has no IANA actions.¶
The design of the Merkle construction in Section 2.3 follows the domain-separation approach established by Certificate Transparency [RFC9162].¶