idnits 2.17.1 draft-intesigroup-dlts-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (January 7, 2021) is 1198 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Cisbani 3 Internet-Draft D. Ribaudo 4 Intended status: Standards Track G. Damiano 5 Expires: July 11, 2021 Intesi Group 6 January 7, 2021 8 Distributed Ledger Time-Stamp 9 draft-intesigroup-dlts-01 11 Abstract 13 This document defines a standard to extend Time Stamp Tokens with 14 Time Attestations recorded on Distributed Ledgers. 16 The aim is to provide long-term validity to Time Stamp Tokens, 17 backward compatible with currently available software. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on July 11, 2021. 36 Copyright Notice 38 Copyright (c) 2021 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 3 55 3. Symbols And Abbreviations . . . . . . . . . . . . . . . . . . 5 56 4. DL Attestation . . . . . . . . . . . . . . . . . . . . . . . 5 57 5. DL Time-Stamp Objects . . . . . . . . . . . . . . . . . . . . 6 58 5.1. DL Time-Stamp Attributes . . . . . . . . . . . . . . . . 7 59 5.1.1. Response Status . . . . . . . . . . . . . . . . . . . 8 60 5.2. DL Time-Stamp Extensions . . . . . . . . . . . . . . . . 8 61 5.2.1. Response Status . . . . . . . . . . . . . . . . . . . 9 62 6. Security Considerations . . . . . . . . . . . . . . . . . . . 9 63 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 64 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 8.1. Normative References . . . . . . . . . . . . . . . . . . 10 66 8.2. Informative References . . . . . . . . . . . . . . . . . 11 67 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 12 69 1. Introduction 71 Attesting that a file existed prior to a specific point in time can 72 be useful - for example - to: 74 o prove when an agreement was signed, if it is disputed 76 o validate a signature after a revocation occurred 78 o prove the ownership for copyright 80 o grant record integrity 82 A Time-Stamp Token (TST) provided by a Time-Stamp Authority (TSA) 83 compliant with RFC 3161 [RFC3161] can be based on an accurate time 84 source linked to Coordinated Universal Time, and can be very precise 85 - it can prove the existence also at the second or less. It is such 86 a consolidated standard that - for example - the European Union 87 legally enforced its usage by eIDAS Regulation [eIDAS], European 88 Standards and Technical Specifications [ETSI.EN.319.422] 89 [ETSI.TS.101.861]. 91 In an in-deep appraisal of Time Stamping Schemes conducted in 2001 by 92 Masashi Une [IMES], PKI TSA was evaluated as one of the most 93 desirables in term of security against alteration of a time stamp. 95 The integrity of the timestamping process that is inevitably bound to 96 the integrity of the TSA gave rise to other proposals like ANSI X9.95 97 [ANSI.X9.95] and ISO/IEC 18014-4 [ISO.IEC.18014-4]. 99 Furthermore a TSA TST can be validated for a limited time - usually 100 no longer than 20 years for technical reasons such as the TSA 101 certificates expiration, or for economic reasons such as the cost of 102 providing the validation service by TSA. 104 This situation brought about some solutions [ETSI.TS.102.778-4] aimed 105 at mitigating the inconvenience by extending the validity of TSA 106 timestamps. 108 Security of a Distributed Ledger (def. in Section 2) is based on 109 hashes of data timestamped and widely published. Each timestamp 110 includes the previous timestamp in its hash, forming a chain, with 111 each additional timestamp reinforcing the ones before it. 113 The advantage of a Distributed Ledger Attestation (DLA) relies on the 114 resilience of the distributed system and the overall design whose aim 115 is the DL perpetual survival. 117 Based on a distributed trust scheme, a Distributed Ledger 118 significantly increases security as already noted by Haber and 119 Stornetta in 1991 [HaberStornetta]. 121 In the case of a permissioned DL, security is provided by an 122 authoritative network of trust [Hyperledger][NISTIR_8202], while in 123 the case of a permissionless DL security is provided by the economic 124 incentive for running full nodes [Nakamoto]. 126 On the other hand, a DLA is not yet a standard solution. 127 Furthermore, the bigger the network the less precise the DLA, because 128 distributed nodes need time to reach consensus. 130 Since a DLA turns out to be a complementary element providing long- 131 term validity to TST - the aim of this specification is to allow an 132 extension of the Time-Stamp Token for Distributed Ledger Attestations 133 (DLA). 135 2. Terms and Definitions 137 The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", 138 "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT 139 RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be 140 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only 141 when, they appear in all capitals, as shown here. 143 This document also refers to the following terms and definitions: 145 Public Key Infrastructure 146 As defined in RFC 5280 [RFC5280] 148 Trusted Third Party 149 As defined in RFC 3161 [RFC3161] 151 Time-Stamp Authority 152 As defined in RFC 3161 [RFC3161] 154 Time-Stamp Token 155 As defined in RFC 3161 [RFC3161] 157 Distributed Ledger 158 Various definitions of blockchain and distributed ledger 159 technology exist, and some of these stress different technical 160 features. Given the nature and scope of this document and the 161 lack of definitional consensus we chose to use the term as defined 162 by UK Government Chief Scientific Adviser [UK-GCSA] "A distributed 163 ledger is essentially an asset database that can be shared across 164 a network of multiple sites, geographies or institutions. All 165 participants within a network can have their own identical copy of 166 the ledger. Any changes to the ledger are reflected in all copies 167 in minutes, or in some cases, seconds. The assets can be 168 financial, legal, physical or electronic. The security and 169 accuracy of the assets stored in the ledger are maintained 170 cryptographically through the use of 'keys' and signatures to 171 control who can do what within the shared ledger. Entries can 172 also be updated by one, some or all of the participants, according 173 to rules agreed by the network". 175 Merkle Tree 176 As defined in [Merkle], [CrosbyWallach] and Section 2.1 of RFC 177 6962 [RFC6962] 179 Aggregation Server 180 A server providing the aggregation of digests to be timestamped in 181 a Merkle Tree. Digests submitted for aggregation are added to a 182 list periodically combined into a single Merkle Tree. Then the 183 digest at the root of that tree is timestamped on a Distributed 184 Ledger. 186 Distributed Ledger Attestation 187 A Distributed Ledger (Timestamping) Attestation is a proof or a 188 promise of timestamping in a precise Distributed Ledger. 190 Calendar 191 A calendar is simply a collection of Distributed Ledger 192 Attestations. 194 Calendar Server 195 A server providing remote access to a collection of Distributed 196 Ledger Attestations. 198 3. Symbols And Abbreviations 200 PKI 201 Public Key Infrastructure 203 TTP 204 Trusted Third Party 206 TSA 207 Time-Stamp Authority 209 TST 210 Time-Stamp Token 212 TSU 213 Time-Stamping Unit 215 DL 216 Distributed Ledger 218 DLA 219 Distributed Ledger Attestation 221 4. DL Attestation 223 A Digital Ledger can be seen as an untrusted logger - serving a 224 number of clients who wish to store their events in the log - kept 225 honest by a number of auditors who will challenge the logger to prove 226 its correct behaviour [CrosbyWallach]. 228 A Merkle Tree data structure accomplishes this in a very efficient 229 way by aggregating many requests and submitting periodically to the 230 log only the root digest of the tree. This log is built as a hash 231 chain (aka blockchain) of small blocks of data. Consequently, the 232 entire chain can be shared and maintained by a large number of nodes, 233 becoming a distributed system. 235 In a permissioned DL the number of nodes can be small enough to 236 permit a quick synchronization and reach consensus concerning the 237 state of the chain. In a permissionless DL the large number of nodes 238 introduces a relevant delay in order to reach consensus. 240 In the case of Bitcoin, consensus is reached statistically. Usually 241 in an average elapsed time of one hour six new blocks are added to 242 the chain. A block of data that was added before the last six 243 blocks, is considered to be practically immutable. This is due to 244 the high computational power that would be required to rewrite the 245 chain. 247 As a result of this scenario the elapsed time - from the request of 248 aggregation of a digest to the proof consolidated inside the DL, may 249 amount to one hour or more. 251 This is why we distinguish between a *promise* of attestation and a 252 *proof* of attestation. Generally, an Aggregation Server provides 253 only a promise to timestamp the client's digest in the DL. However, 254 when the aggregation is completed and the Merkle Tree root hash 255 recorded in a block within the chain, the promise has not yet been 256 confirmed. 258 Only after reaching consensus on that block can attestation be 259 considered as proof, and made available by the Calendar Server. 261 For the sake of simplicity, the Aggregation Server and the Calendar 262 Server can be implemented as a unique instance. In this document we 263 will generically refer to a Calendar Server indicating both services. 265 The DLA data structure is out of scope in this specification 266 document. Any Calendar Server can define his application protocol 267 and data structure. For this specification the DLA is considered as 268 pure data. 270 5. DL Time-Stamp Objects 272 The new objects MUST have the following root OID: 274 id-ce-dlts OBJECT IDENTIFIER ::= { id-ce TBD1 } 276 where id-ce identifies the root of standard extensions as described 277 in RFC 5280 [RFC5280]. 279 The ASN.1 structure of Promise type is as follows: 281 Promise ::= SEQUENCE { 282 version INTEGER, 283 calendarFormat UTF8String, 284 dlPromise DLPromise, 285 signerInfo issuerAndSerialNumber, 286 serialNumber INTEGER } 288 DLPromise ::= OCTET STRING 290 The ASN.1 structure of Proof type is as follows: 292 Proof ::= SEQUENCE { 293 version INTEGER, 294 calendarFormat UTF8String, 295 dlProof DLProof, 296 signerInfo issuerAndSerialNumber, 297 serialNumber INTEGER } 299 DLProof ::= OCTET STRING 301 The fields of Promise and Proof type have the following meanings: 303 o version is the syntax version number. It MUST always be 0. The 304 usage is as described in Section 1.3 of RFC 5652 [RFC5652] 306 o calendarFormat is the media type format of the DL attestation. It 307 MUST be a registered application media type, in accordance with 308 procedures laid out in RFC 6838 [RFC6838] 310 o dlProof and dlPromise are the proof and promise obtained from a 311 Calendar Server using as input value the value of the signature 312 field of the SignerInfo structure inside the digital signature of 313 the TimeStampToken, as described in Section 5.3 of RFC 5652 314 [RFC5652] 316 o signerInfo is an IssuerAndSerialNumber type that identifies the 317 TSU signing certificate as described in Section 10.2.4 of RFC 5652 318 [RFC5652] 320 o serialNumber is an integer assigned by the TSA to each 321 TimeStampToken as described in Section 2.4.2 of RFC 3161 [RFC3161] 323 5.1. DL Time-Stamp Attributes 325 A set of proofs or a set of promises, generated by a Calendar Server, 326 MAY be included in a TST, using an unsigned attribute of the per- 327 signer information. 329 To grant backward compatibility with any currently available software 330 the unsigned attribute MUST be compliant with the specifications 331 defined in Section 5.3 of RFC 5652 [RFC5652] for Attribute type. 333 Attributes including a set of promises and a set of proofs MUST be 334 unsigned attributes; they MUST NOT be signed attributes, 335 authenticated attributes, unauthenticated attributes, or unprotected 336 attributes. 338 The ASN.1 structure of attributes including a set of promises is as 339 follows: 341 id-ce-dlts-promises OBJECT IDENTIFIER ::= { id-ce-dlts 0 } 343 Promises SET OF Promise 345 The ASN.1 structure of attributes including a set of proofs is as 346 follows: 348 id-ce-dlts-proofs OBJECT IDENTIFIER ::= { id-ce-dlts 1 } 350 Proofs SET OF Proof 352 All the proofs and promises that have been returned MUST refer to the 353 same parent TimeStampToken issued at the time of the request. 355 5.1.1. Response Status 357 The response status code in the TimeStampResp MUST be compliant with 358 the specifications described in Section 2.4.2 of RFC 3161 [RFC3161] 359 and Section 5.2.3 of RFC 4210 [RFC4210]. 361 According to the TimeStamp policy, when the response contains only a 362 subset of the expected proofs, the status field SHOULD contain either 363 the value one (grantedWithMods) or the value two (rejection). 365 5.2. DL Time-Stamp Extensions 367 Upgrade from a set of promises to a set of proofs MAY be done 368 requesting a new TST including inside a non critical extension the 369 set of promises previously obtained in an unsigned attribute. 371 When the TSA receives a request which has a non critical extension 372 containing a set of promises, it MAY request the Calendar Server to 373 get the corresponding proof for each of them, and MAY include the set 374 of proofs in the TST response, using a non critical extension of the 375 TSTInfo sequence. 377 To grant backward compatibility with any currently available 378 software, request and response non critical extensions MUST be 379 compliant with the specifications described in Section 2.4 of RFC 380 3161 [RFC3161] and Section 4.2 of RFC 5280 [RFC5280]. 382 Conforming TSAs MUST mark these extensions as non-critical. 384 The ASN.1 structure of the proof request extension is as follows: 386 id-ce-dlts-promises OBJECT IDENTIFIER 388 Promises SET OF Promise 390 The ASN.1 structure of the proof response extension is as follows: 392 id-ce-dlts-proofs OBJECT IDENTIFIER 394 Proofs SET OF Proof 396 The proofs returned in the extensions by the TSA MUST NOT refer to 397 the TimeStampToken issued at the time of the request. Each Proof 398 MUST contain the explicit reference to the pointing TimeStampToken 399 with signerInfo (referring to the TSU certificate) and serialNumber 400 (referring to the time stamp serial number), which have been received 401 in the Promise structure of the proof request extension. 403 5.2.1. Response Status 405 The response status code in the TimeStampResp MUST be compliant with 406 the specifications described in Section 2.4.2 of RFC 3161 [RFC3161] 407 and Section 5.2.3 of RFC 4210 [RFC4210]. 409 Compliant servers SHOULD also use the status field as follows: 411 o according to TimeStamp policy, when the response contains only a 412 subset of the expected proofs, the status field SHOULD contain 413 either the value one (grantedWithMods) or two (rejection) 415 o when in the response no proof can be returned, the status field 416 SHOULD contain the value two (rejection) 418 o when all the received promises recognized by the Calendar Server 419 are pending, the status field SHOULD contain the value three 420 (waiting). 422 6. Security Considerations 424 Each security consideration described in Section 4 of RFC 3161 425 [RFC3161] SHALL be evaluated designing TSA services that include DL 426 Time-Stamp extensions. 428 When a TSA executes a request to a Calendar Server the use of a nonce 429 is RECOMMENDED because using a nonce always allows the client to 430 detect replays. 432 Safety and reliability of the DL proofs depends on the robustness of 433 the hash algorithms and on the stability of the DL, i.e. how 434 expensive or difficult it would be for an attacker to alter the DL. 436 7. IANA Considerations 438 This document does not require any action by IANA. 440 8. References 442 8.1. Normative References 444 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 445 Requirement Levels", BCP 14, RFC 2119, 446 DOI 10.17487/RFC2119, March 1997, 447 . 449 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 450 "Internet X.509 Public Key Infrastructure Time-Stamp 451 Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 452 2001, . 454 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 455 "Internet X.509 Public Key Infrastructure Certificate 456 Management Protocol (CMP)", RFC 4210, 457 DOI 10.17487/RFC4210, September 2005, 458 . 460 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 461 Housley, R., and W. Polk, "Internet X.509 Public Key 462 Infrastructure Certificate and Certificate Revocation List 463 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 464 . 466 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 467 RFC 5652, DOI 10.17487/RFC5652, September 2009, 468 . 470 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 471 Specifications and Registration Procedures", BCP 13, 472 RFC 6838, DOI 10.17487/RFC6838, January 2013, 473 . 475 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 476 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 477 May 2017, . 479 8.2. Informative References 481 [ANSI.X9.95] 482 American National Standards Institute (ANSI), "Trusted 483 Time Stamp Management And Security", 2005, 484 . 486 [CrosbyWallach] 487 Crosby, S. and D. Wallach, "Efficient Data Structures for 488 Tamper-Evident Logging", Proceedings of the 18th USENIX 489 Security Symposium, Montreal, August 2009, 490 . 493 [eIDAS] The European Parliament And The Council Of The European 494 Union, "Regulation (EU) No 910/2014", July 2014, 495 . 498 [ETSI.EN.319.422] 499 European Telecommunications Standards Institute, 500 "Electronic Signatures and Infrastructures (ESI); Time- 501 stamping protocol and time-stamp token profiles", March 502 2016, . 506 [ETSI.TS.101.861] 507 European Telecommunications Standards Institute, 508 "Electronic Signatures and Infrastructures (ESI); Time 509 stamping profile", July 2011, 510 . 514 [ETSI.TS.102.778-4] 515 European Telecommunications Standards Institute, 516 "Electronic Signatures and Infrastructures (ESI); PDF 517 Advanced Electronic Signature Profiles; Part 4: PAdES Long 518 Term - PAdES-LTV Profile", December 2009, 519 . 523 [HaberStornetta] 524 Haber, S. and W. S. Stornetta, "How to Time-Stamp a 525 Digital Document", 1991, 526 . 528 [Hyperledger] 529 The Linux Foundation, "Hyperledger Architecture, Volume 1: 530 Introduction to Hyperledger Business Blockchain Design 531 Philosophy and Consensus", August 2017, 532 . 535 [IMES] Une, M., "The Security Evaluation of Time Stamping 536 Schemes: The Present Situation and Studies (2001)", 2001, 537 . 540 [ISO.IEC.18014-4] 541 International Organization for Standardization, 542 "Information technology - Security techniques - Time- 543 stamping services - Part 4: Traceability of time sources", 544 April 2015, . 546 [Merkle] Merkle, R. C., "Secrecy, authentication, and public-key 547 systems - Technical Report No. 1979-1", June 1979, 548 . 550 [Nakamoto] 551 Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 552 System", October 2008, . 554 [NISTIR_8202] 555 Yaga, D., Mell, P., Roby, N., and K. Scarfone, "Blockchain 556 Technology Overview", October 2018, 557 . 559 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 560 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 561 . 563 [UK-GCSA] UK Government Chief Scientific Adviser, "Distributed 564 Ledger Technology: beyond block chain", January 2016, . 569 Authors' Addresses 570 Emanuele Cisbani 571 Intesi Group 572 Via Torino 48 573 Milano 20123 574 Italy 576 Phone: +39 026 760 641 577 Email: ecisbani@intesigroup.com 578 URI: https://www.intesigroup.com 580 Daniele Ribaudo 581 Intesi Group 582 Via Torino 48 583 Milano 20123 584 Italy 586 Phone: +39 026 760 641 587 Email: dribaudo@intesigroup.com 588 URI: https://www.intesigroup.com 590 Giuseppe Damiano 591 Intesi Group 592 Via Torino 48 593 Milano 20123 594 Italy 596 Phone: +39 026 760 641 597 Email: gdamiano@intesigroup.com 598 URI: https://www.intesigroup.com