ProtectChain: An Anchored Permissioned Ledger for Proof of Anteriority of Authored Works
draft-tempobono-protectchain-00

Independent Submission                                      O. Tempobono
Internet-Draft                                              N. Tempobono
Intended status: Informational                              L. Tempobono
Expires: 14 March 2027                                      F. Tempobono
                                                            C. Tempobono
                                       Global Innovation Technology LTDA
                                                       10 September 2026

 ProtectChain: An Anchored Permissioned Ledger for Proof of Anteriority
                           of Authored Works
                    draft-tempobono-protectchain-00

Abstract

   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.

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

Tempobono, et al.         Expires 14 March 2027                 [Page 1]
Internet-Draft                ProtectChain                September 2026

   This Internet-Draft will expire on 14 March 2027.

Copyright Notice

   Copyright (c) 2026 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents (https://trustee.ietf.org/
   license-info) in effect on the date of publication of this document.
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   3
     1.1.  Requirements Language . . . . . . . . . . . . . . . . . .   3
     1.2.  Definitions . . . . . . . . . . . . . . . . . . . . . . .   3
   2.  Data Model  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.1.  Records . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.2.  Blocks  . . . . . . . . . . . . . . . . . . . . . . . . .   4
     2.3.  Merkle Root with Domain Separation  . . . . . . . . . . .   5
   3.  Consensus . . . . . . . . . . . . . . . . . . . . . . . . . .   5
     3.1.  Co-signature Protocol . . . . . . . . . . . . . . . . . .   5
     3.2.  Independent Validation  . . . . . . . . . . . . . . . . .   6
     3.3.  Mirroring and Synchronization . . . . . . . . . . . . . .   6
     3.4.  Quorum and Fault Tolerance  . . . . . . . . . . . . . . .   7
     3.5.  Separation of Recording and Consensus . . . . . . . . . .   7
     3.6.  Availability Model  . . . . . . . . . . . . . . . . . . .   8
   4.  Anchoring to Public Time References . . . . . . . . . . . . .   8
     4.1.  Time-Stamp Tokens . . . . . . . . . . . . . . . . . . . .   8
     4.2.  Distributed Ledger Anchoring  . . . . . . . . . . . . . .   8
     4.3.  Clock Discipline  . . . . . . . . . . . . . . . . . . . .   8
   5.  Scope and Limits of the Temporal Evidence . . . . . . . . . .   9
     5.1.  What the Evidence Demonstrates  . . . . . . . . . . . . .   9
     5.2.  What the Evidence Does Not Demonstrate  . . . . . . . . .   9
     5.3.  The Trust Window and Its Mitigation . . . . . . . . . . .   9
   6.  Data Minimization . . . . . . . . . . . . . . . . . . . . . .  10
   7.  Admission of Additional Authorities . . . . . . . . . . . . .  11
   8.  Inter-Node Authentication . . . . . . . . . . . . . . . . . .  12
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  13
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  13
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  13
     11.2.  Informative References . . . . . . . . . . . . . . . . .  14
   Acknowledgements  . . . . . . . . . . . . . . . . . . . . . . . .  14
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  14

Tempobono, et al.         Expires 14 March 2027                 [Page 2]
Internet-Draft                ProtectChain                September 2026

1.  Introduction

   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:

   1.  a hash-chained ledger in which each block is signed by the
       authority that sealed it;

   2.  independent co-signature by additional authorities, each of which
       recomputes the block rather than trusting the sender;

   3.  anchoring of each block into public time references that the
       operator does not control.

   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.

1.1.  Requirements Language

   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.

1.2.  Definitions

   Record:  The set of digests and metadata submitted for a work.  It
      never contains the work itself.

   Block:  A batch of sealed records, linked to its predecessor by hash
      and signed by a sealer.

   Authority:  A node permitted to validate and co-sign blocks,

Tempobono, et al.         Expires 14 March 2027                 [Page 3]
Internet-Draft                ProtectChain                September 2026

      identified by an Ed25519 public key.  Roles are _sealer_ (produces
      blocks) and _validator_ (validates and co-signs).

   Anchor:  External evidence that a block existed no later than a given
      instant, obtained from a public time reference.

   Quorum:  The number of distinct authority signatures required for a
      block to be considered corroborated.

2.  Data Model

2.1.  Records

   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.

2.2.  Blocks

   A block links to its predecessor and commits to the records it
   contains:

Tempobono, et al.         Expires 14 March 2027                 [Page 4]
Internet-Draft                ProtectChain                September 2026

   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.

2.3.  Merkle Root with Domain Separation

   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.

3.  Consensus

   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.

3.1.  Co-signature Protocol

   1.  The sealer seals pending records into a block, computes
       block_hash, and signs it.

   2.  The sealer sends the block header and the list of record_hash
       values to the other authorities.  It MUST NOT send the content of
       any work.

Tempobono, et al.         Expires 14 March 2027                 [Page 5]
Internet-Draft                ProtectChain                September 2026

   3.  Each validator decides independently (Section 3.2) and, if it
       approves, mirrors the block locally and returns its signature
       over block_hash.

   4.  The sealer MUST accept a co-signature only if the signer is a
       known active authority and the signature verifies against that
       authority's public key.

   5.  A block reaches quorum when it holds signatures from distinct
       authorities in a number at least equal to the quorum
       (Section 3.4).

3.2.  Independent Validation

   Before co-signing, a validator MUST verify, on its own and without
   taking any value from the sender on trust, that:

   1.  the sealer is present in the active authority list;

   2.  block_hash, recomputed from the received fields, matches;

   3.  the Merkle root, recomputed from the received record_hash values,
       matches;

   4.  the sealer's Ed25519 signature over block_hash verifies;

   5.  prev_hash matches the block it already holds at index-1, if any;

   6.  it has not already co-signed a different block at the same index.

   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.

3.3.  Mirroring and Synchronization

   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.

Tempobono, et al.         Expires 14 March 2027                 [Page 6]
Internet-Draft                ProtectChain                September 2026

   A validator stores only record_hash values, which suffice to
   recompute the Merkle root and to serve inclusion proofs, without ever
   holding the work.

3.4.  Quorum and Fault Tolerance

   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                  |
               +-------------+--------+--------------------+

                  Table 1: Quorum by number of authorities

   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.

3.5.  Separation of Recording and Consensus

   Recording a work and obtaining consensus are distinct, asynchronous
   operations.

   *  Recording MUST NOT block while waiting for co-signatures.

   *  Propagation MUST occur outside the submitter's request path, in a
      periodic process.

   *  That process MUST reprocess blocks that have not reached quorum,
      so that the network converges without operator intervention when
      an unavailable authority returns.

Tempobono, et al.         Expires 14 March 2027                 [Page 7]
Internet-Draft                ProtectChain                September 2026

3.6.  Availability Model

   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:

   *  the sealer MUST continue to operate when it can reach no
      validator;

   *  an unreachable validator MUST NOT prevent sealing, anchoring, or
      recording;

   *  convergence MUST be eventual and automatic.

4.  Anchoring to Public Time References

   Because all initial authorities may belong to a single operator, each
   block is additionally committed to public references that the
   operator does not control.

4.1.  Time-Stamp Tokens

   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.

4.2.  Distributed Ledger Anchoring

   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.

4.3.  Clock Discipline

   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.

Tempobono, et al.         Expires 14 March 2027                 [Page 8]
Internet-Draft                ProtectChain                September 2026

5.  Scope and Limits of the Temporal Evidence

   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.

5.1.  What the Evidence Demonstrates

   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.

5.2.  What the Evidence Does Not Demonstrate

   1.  It does not fix the instant of creation.  The anchor is an upper
       bound: it shows the content was not created after that instant.

   2.  It does not validate the block's created_at field nor the
       submitter's declared creation date.  Neither is corroborated by
       the anchor; only the anchoring instant is.

   3.  It does not establish authorship or originality.  The submission
       is a self-declaration.

   4.  It does not prevent submission of a third party's work.  A
       submitter obtains evidence that the file existed by a given
       instant, which confers no right over it.

5.3.  The Trust Window and Its Mitigation

   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:

   *  Implementations MUST anchor each block immediately after sealing,
      keeping the window in the order of seconds.

Tempobono, et al.         Expires 14 March 2027                 [Page 9]
Internet-Draft                ProtectChain                September 2026

   *  Material citing a proven date SHOULD present the anchoring instant
      as the demonstrated date, and created_at or any declared date as
      asserted information.

   *  Federation with independent operators reduces the window to a
      problem of collusion between distinct parties.

   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.

6.  Data Minimization

   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                  |
   +-----------------------------------------+------------------------+

                         Table 2: Data placement

   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.

Tempobono, et al.         Expires 14 March 2027                [Page 10]
Internet-Draft                ProtectChain                September 2026

7.  Admission of Additional Authorities

   A candidate authority MUST satisfy the following.  None of these is
   ceremonial; each exists so that the candidate's co-signature carries
   meaning.

   1.  Verifiable identification of the operator and formal acceptance
       of the network's terms.

   2.  Independence: the candidate MUST NOT be controlled by the same
       entity as another active authority.  Two authorities under common
       control do not add independence.

   3.  A distinct site: separate physical machine, provider and network
       path.  Placement in a different jurisdiction from existing
       authorities is RECOMMENDED.

   4.  Clocks disciplined per Section 4.3.

   5.  Locally generated Ed25519 key material.  The private key MUST NOT
       leave the node, including in backups or images.

   6.  Participation over a private, authenticated and encrypted
       network.  The consensus API MUST NOT be exposed on a public
       address.

   7.  Authentication of inter-node calls by signature (Section 8).
       Shared secrets MUST NOT be used between authorities.

   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.

Tempobono, et al.         Expires 14 March 2027                [Page 11]
Internet-Draft                ProtectChain                September 2026

8.  Inter-Node Authentication

   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.

9.  Security Considerations

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

Tempobono, et al.         Expires 14 March 2027                [Page 12]
Internet-Draft                ProtectChain                September 2026

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

10.  IANA Considerations

   This document has no IANA actions.

11.  References

11.1.  Normative References

Tempobono, et al.         Expires 14 March 2027                [Page 13]
Internet-Draft                ProtectChain                September 2026

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

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

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

   [RFC6234]  Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms
              (SHA and SHA-based HMAC and HKDF)", RFC 6234,
              DOI 10.17487/RFC6234, May 2011,
              <https://www.rfc-editor.org/info/rfc6234>.

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

11.2.  Informative References

   [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/info/rfc9162>.

   [RFC5905]  Mills, D., Martin, J., 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>.

   [BERNE]    World Intellectual Property Organization, "Berne
              Convention for the Protection of Literary and Artistic
              Works", 1979,
              <https://www.wipo.int/treaties/en/ip/berne/>.

Acknowledgements

   The design of the Merkle construction in Section 2.3 follows the
   domain-separation approach established by Certificate Transparency
   [RFC9162].

Authors' Addresses

Tempobono, et al.         Expires 14 March 2027                [Page 14]
Internet-Draft                ProtectChain                September 2026

   Orlando Tempobono
   Global Innovation Technology LTDA
   Sao Paulo, SP
   Brazil
   Email: orlando@globalcopyrights.org
   URI:   https://orcid.org/0009-0002-2533-7446

   Nelson Tempobono
   Global Innovation Technology LTDA
   Sao Paulo, SP
   Brazil
   Email: nelson@globalcopyrights.org

   Lucas Tempobono
   Global Innovation Technology LTDA
   Sao Paulo, SP
   Brazil
   Email: lucas@globalcopyrights.org

   Felipe Tempobono
   Global Innovation Technology LTDA
   Sao Paulo, SP
   Brazil
   Email: felipe@globalcopyrights.org

   Clara Tempobono
   Global Innovation Technology LTDA
   Sao Paulo, SP
   Brazil
   Email: clara@globalcopyrights.org

Tempobono, et al.         Expires 14 March 2027                [Page 15]