Distributed Ledger Time-Stamp

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 11 July 2021.¶

Copyright Notice

Copyright (c) 2021 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. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.¶

Table of Contents

1. Introduction

Attesting that a file existed prior to a specific point in time can be useful - for example - to:¶

• prove when an agreement was signed, if it is disputed¶
• validate a signature after a revocation occurred¶
• prove the ownership for copyright¶
• grant record integrity¶

A Time-Stamp Token (TST) provided by a Time-Stamp Authority (TSA) compliant with RFC 3161 [RFC3161] can be based on an accurate time source linked to Coordinated Universal Time, and can be very precise - it can prove the existence also at the second or less. It is such a consolidated standard that - for example - the European Union legally enforced its usage by eIDAS Regulation [eIDAS], European Standards and Technical Specifications [ETSI.EN.319.422] [ETSI.TS.101.861].¶

In an in-deep appraisal of Time Stamping Schemes conducted in 2001 by Masashi Une [IMES], PKI TSA was evaluated as one of the most desirables in term of security against alteration of a time stamp.¶

The integrity of the timestamping process that is inevitably bound to the integrity of the TSA gave rise to other proposals like ANSI X9.95 [ANSI.X9.95] and ISO/IEC 18014-4 [ISO.IEC.18014-4].¶

Furthermore a TSA TST can be validated for a limited time - usually no longer than 20 years for technical reasons such as the TSA certificates expiration, or for economic reasons such as the cost of providing the validation service by TSA.¶

This situation brought about some solutions [ETSI.TS.102.778-4] aimed at mitigating the inconvenience by extending the validity of TSA timestamps.¶

Security of a Distributed Ledger (def. in Section 2) is based on hashes of data timestamped and widely published. Each timestamp includes the previous timestamp in its hash, forming a chain, with each additional timestamp reinforcing the ones before it.¶

The advantage of a Distributed Ledger Attestation (DLA) relies on the resilience of the distributed system and the overall design whose aim is the DL perpetual survival.¶

Based on a distributed trust scheme, a Distributed Ledger significantly increases security as already noted by Haber and Stornetta in 1991 [HaberStornetta].¶

In the case of a permissioned DL, security is provided by an authoritative network of trust [Hyperledger][NISTIR_8202], while in the case of a permissionless DL security is provided by the economic incentive for running full nodes [Nakamoto].¶

On the other hand, a DLA is not yet a standard solution. Furthermore, the bigger the network the less precise the DLA, because distributed nodes need time to reach consensus.¶

Since a DLA turns out to be a complementary element providing long-term validity to TST - the aim of this specification is to allow an extension of the Time-Stamp Token for Distributed Ledger Attestations (DLA).¶

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

This document also refers to the following terms and definitions:¶

Public Key Infrastructure

As defined in RFC 5280 [RFC5280]¶

Trusted Third Party

As defined in RFC 3161 [RFC3161]¶

Time-Stamp Authority

As defined in RFC 3161 [RFC3161]¶

Time-Stamp Token

As defined in RFC 3161 [RFC3161]¶

Distributed Ledger

Various definitions of blockchain and distributed ledger technology exist, and some of these stress different technical features. Given the nature and scope of this document and the lack of definitional consensus we chose to use the term as defined by UK Government Chief Scientific Adviser [UK-GCSA] "A distributed ledger is essentially an asset database that can be shared across a network of multiple sites, geographies or institutions. All participants within a network can have their own identical copy of the ledger. Any changes to the ledger are reflected in all copies in minutes, or in some cases, seconds. The assets can be financial, legal, physical or electronic. The security and accuracy of the assets stored in the ledger are maintained cryptographically through the use of 'keys' and signatures to control who can do what within the shared ledger. Entries can also be updated by one, some or all of the participants, according to rules agreed by the network".¶

Merkle Tree

As defined in [Merkle], [CrosbyWallach] and Section 2.1 of RFC 6962 [RFC6962]¶

Aggregation Server

A server providing the aggregation of digests to be timestamped in a Merkle Tree. Digests submitted for aggregation are added to a list periodically combined into a single Merkle Tree. Then the digest at the root of that tree is timestamped on a Distributed Ledger.¶

Distributed Ledger Attestation

A Distributed Ledger (Timestamping) Attestation is a proof or a promise of timestamping in a precise Distributed Ledger.¶

Calendar

A calendar is simply a collection of Distributed Ledger Attestations.¶

Calendar Server

A server providing remote access to a collection of Distributed Ledger Attestations.¶

3. Symbols And Abbreviations

PKI

Public Key Infrastructure¶

TTP

Trusted Third Party¶

TSA

Time-Stamp Authority¶

TST

Time-Stamp Token¶

TSU

Time-Stamping Unit¶

DL

Distributed Ledger¶

DLA

Distributed Ledger Attestation¶

4. DL Attestation

A Digital Ledger can be seen as an untrusted logger - serving a number of clients who wish to store their events in the log - kept honest by a number of auditors who will challenge the logger to prove its correct behaviour [CrosbyWallach].¶

A Merkle Tree data structure accomplishes this in a very efficient way by aggregating many requests and submitting periodically to the log only the root digest of the tree. This log is built as a hash chain (aka blockchain) of small blocks of data. Consequently, the entire chain can be shared and maintained by a large number of nodes, becoming a distributed system.¶

In a permissioned DL the number of nodes can be small enough to permit a quick synchronization and reach consensus concerning the state of the chain. In a permissionless DL the large number of nodes introduces a relevant delay in order to reach consensus.¶

In the case of Bitcoin, consensus is reached statistically. Usually in an average elapsed time of one hour six new blocks are added to the chain. A block of data that was added before the last six blocks, is considered to be practically immutable. This is due to the high computational power that would be required to rewrite the chain.¶

As a result of this scenario the elapsed time - from the request of aggregation of a digest to the proof consolidated inside the DL, may amount to one hour or more.¶

This is why we distinguish between a promise of attestation and a proof of attestation. Generally, an Aggregation Server provides only a promise to timestamp the client's digest in the DL. However, when the aggregation is completed and the Merkle Tree root hash recorded in a block within the chain, the promise has not yet been confirmed.¶

Only after reaching consensus on that block can attestation be considered as proof, and made available by the Calendar Server.¶

For the sake of simplicity, the Aggregation Server and the Calendar Server can be implemented as a unique instance. In this document we will generically refer to a Calendar Server indicating both services.¶

The DLA data structure is out of scope in this specification document. Any Calendar Server can define his application protocol and data structure. For this specification the DLA is considered as pure data.¶

5. DL Time-Stamp Objects

The new objects MUST have the following root OID:¶

id-ce-dlts OBJECT IDENTIFIER ::= { id-ce TBD1 }

where id-ce identifies the root of standard extensions as described in RFC 5280 [RFC5280].¶

The ASN.1 structure of Promise type is as follows:¶

Promise ::= SEQUENCE {
    version          INTEGER,
    calendarFormat   UTF8String,
    dlPromise        DLPromise,
    signerInfo       issuerAndSerialNumber,
    serialNumber     INTEGER }

DLPromise ::= OCTET STRING

The ASN.1 structure of Proof type is as follows:¶

Proof ::= SEQUENCE {
    version          INTEGER,
    calendarFormat   UTF8String,
    dlProof          DLProof,
    signerInfo       issuerAndSerialNumber,
    serialNumber     INTEGER }

DLProof ::= OCTET STRING

The fields of Promise and Proof type have the following meanings:¶

• version is the syntax version number. It MUST always be 0. The usage is as described in Section 1.3 of RFC 5652 [RFC5652]¶
• calendarFormat is the media type format of the DL attestation. It MUST be a registered application media type, in accordance with procedures laid out in RFC 6838 [RFC6838]¶
• dlProof and dlPromise are the proof and promise obtained from a Calendar Server using as input value the value of the signature field of the SignerInfo structure inside the digital signature of the TimeStampToken, as described in Section 5.3 of RFC 5652 [RFC5652]¶
• signerInfo is an IssuerAndSerialNumber type that identifies the TSU signing certificate as described in Section 10.2.4 of RFC 5652 [RFC5652]¶
• serialNumber is an integer assigned by the TSA to each TimeStampToken as described in Section 2.4.2 of RFC 3161 [RFC3161]¶

id-ce-dlts-promises OBJECT IDENTIFIER ::= { id-ce-dlts 0 }

Promises            SET OF Promise

id-ce-dlts-proofs OBJECT IDENTIFIER ::= { id-ce-dlts 1 }

Proofs              SET OF Proof

id-ce-dlts-promises OBJECT IDENTIFIER

Promises            SET OF Promise

id-ce-dlts-proofs OBJECT IDENTIFIER

Proofs               SET OF Proof

6. Security Considerations

Each security consideration described in Section 4 of RFC 3161 [RFC3161] SHALL be evaluated designing TSA services that include DL Time-Stamp extensions.¶

When a TSA executes a request to a Calendar Server the use of a nonce is RECOMMENDED because using a nonce always allows the client to detect replays.¶

Safety and reliability of the DL proofs depends on the robustness of the hash algorithms and on the stability of the DL, i.e. how expensive or difficult it would be for an attacker to alter the DL.¶

7. IANA Considerations

This document does not require any action by IANA.¶

Authors' Addresses