idnits 2.17.1 draft-intesigroup-dlts-03.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 (25 November 2021) is 876 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) ** Downref: Normative reference to an Informational RFC: RFC 3628 -- Obsolete informational reference (is this intentional?): RFC 6962 (Obsoleted by RFC 9162) Summary: 1 error (**), 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 Intesi Group 5 Expires: 29 May 2022 G. Damiano 6 Entrust 7 25 November 2021 9 Distributed Ledger Time-Stamp 10 draft-intesigroup-dlts-03 12 Abstract 14 This document defines a standard to extend Time Stamp Tokens with 15 Time Attestations recorded on Distributed Ledgers. 17 The aim is to provide long-term validity to Time Stamp Tokens, 18 backward compatible with currently available software. 20 Status of This Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at https://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on 29 May 2022. 37 Copyright Notice 39 Copyright (c) 2021 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal 43 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 44 license-info) in effect on the date of publication of this document. 45 Please review these documents carefully, as they describe your rights 46 and restrictions with respect to this document. Code Components 47 extracted from this document must include Revised BSD License text as 48 described in Section 4.e of the Trust Legal Provisions and are 49 provided without warranty as described in the Revised BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 2. Terms and Definitions . . . . . . . . . . . . . . . . . . . . 4 55 3. Symbols And Abbreviations . . . . . . . . . . . . . . . . . . 5 56 4. DL Attestation . . . . . . . . . . . . . . . . . . . . . . . 6 57 5. DL Time-Stamp Objects . . . . . . . . . . . . . . . . . . . . 7 58 5.1. DL Time-Stamp Attributes . . . . . . . . . . . . . . . . 8 59 5.1.1. Response Status . . . . . . . . . . . . . . . . . . . 8 60 5.2. DL Time-Stamp Extensions . . . . . . . . . . . . . . . . 9 61 5.2.1. Response Status . . . . . . . . . . . . . . . . . . . 10 62 5.3. Use case . . . . . . . . . . . . . . . . . . . . . . . . 10 63 5.3.1. Promises . . . . . . . . . . . . . . . . . . . . . . 10 64 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 65 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 66 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 67 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 68 8.2. Informative References . . . . . . . . . . . . . . . . . 13 69 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 71 1. Introduction 73 Attesting that a file existed prior to a specific point in time can 74 be useful - for example - to: 76 * prove when an agreement was signed, if it is disputed 78 * validate a signature after a revocation occurred 80 * prove the ownership for copyright 82 * grant record integrity 83 A Time-Stamp Token (TST) provided by a Time-Stamp Authority (TSA) 84 compliant with RFC 3161 [RFC3161] can be based on an accurate time 85 source linked to Coordinated Universal Time, and can be very precise 86 - it can prove the existence also at the second or less. It is such 87 a consolidated standard that - for example - the European Union 88 legally enforced its usage by eIDAS Regulation [eIDAS], European 89 Standards and Technical Specifications [ETSI.EN.319.422] 90 [ETSI.TS.101.861]. 92 In an in-deep appraisal of Time Stamping Schemes conducted in 2001 by 93 Masashi Une [IMES], PKI TSA was evaluated as one of the most 94 desirables in term of security against alteration of a time stamp. 96 The integrity of the timestamping process that is inevitably bound to 97 the integrity of the TSA gave rise to other proposals like ANSI X9.95 98 [ANSI.X9.95] and ISO/IEC 18014-4 [ISO.IEC.18014-4]. 100 Furthermore a TSA TST can be validated for a limited time - usually 101 no longer than 20 years for technical reasons such as the TSA 102 certificates expiration, or for economic reasons such as the cost of 103 providing the validation service by TSA. 105 This situation brought about some solutions [ETSI.TS.102.778-4] aimed 106 at mitigating the inconvenience by extending the validity of TSA 107 timestamps. 109 Security of a Distributed Ledger (def. in Section 2) is based on 110 hashes of data timestamped and widely published. Each timestamp 111 includes the previous timestamp in its hash, forming a chain, with 112 each additional timestamp reinforcing the ones before it. 114 The advantage of a Distributed Ledger Attestation (DLA) relies on the 115 resilience of the distributed system and the overall design whose aim 116 is the DL perpetual survival. 118 Based on a distributed trust scheme, a Distributed Ledger 119 significantly increases security as already noted by Haber and 120 Stornetta in 1991 [HaberStornetta]. 122 In the case of a permissioned DL, security is provided by an 123 authoritative network of trust [Hyperledger][NISTIR_8202], while in 124 the case of a permissionless DL security is provided by the economic 125 incentive for running full nodes [Nakamoto]. 127 On the other hand, a DLA is not yet a standard solution. 128 Furthermore, the bigger the network the less precise the DLA, because 129 distributed nodes need time to reach consensus. 131 Since a DLA turns out to be a complementary element providing long- 132 term validity to TST - the aim of this specification is to allow an 133 extension of the Time-Stamp Token for Distributed Ledger Attestations 134 (DLA). 136 2. Terms and Definitions 138 The key words "*MUST*", "*MUST NOT*", "*REQUIRED*", "*SHALL*", 139 "*SHALL NOT*", "*SHOULD*", "*SHOULD NOT*", "*RECOMMENDED*", "*NOT 140 RECOMMENDED*", "*MAY*", and "*OPTIONAL*" in this document are to be 141 interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only 142 when, they appear in all capitals, as shown here. 144 This document also refers to the following terms and definitions: 146 Public Key Infrastructure 147 As defined in [RFC5280] 149 Trusted Third Party 150 As defined in [RFC3161] 152 Time-Stamping Authority 153 As defined in [RFC3161] 155 Time-Stamp Token 156 As defined in [RFC3161] 158 Time-Stamping Unit 159 As defined in [RFC3628] 161 Distributed Ledger 162 Various definitions of blockchain and distributed ledger 163 technology exist, and some of these stress different technical 164 features. Given the nature and scope of this document and the 165 lack of definitional consensus we chose to use the term as defined 166 by UK Government Chief Scientific Adviser [UK-GCSA] "A distributed 167 ledger is essentially an asset database that can be shared across 168 a network of multiple sites, geographies or institutions. All 169 participants within a network can have their own identical copy of 170 the ledger. Any changes to the ledger are reflected in all copies 171 in minutes, or in some cases, seconds. The assets can be 172 financial, legal, physical or electronic. The security and 173 accuracy of the assets stored in the ledger are maintained 174 cryptographically through the use of 'keys' and signatures to 175 control who can do what within the shared ledger. Entries can 176 also be updated by one, some or all of the participants, according 177 to rules agreed by the network". 179 Merkle Tree 180 As defined in [Merkle], [CrosbyWallach] and Section 2.1 of 181 [RFC6962] 183 Aggregation Server 184 A server providing the aggregation of digests to be timestamped in 185 a Merkle Tree. Digests submitted for aggregation are added to a 186 list periodically combined into a single Merkle Tree. Then the 187 digest at the root of that tree is timestamped on a Distributed 188 Ledger. 190 Distributed Ledger Attestation 191 A Distributed Ledger (Timestamping) Attestation is a proof or a 192 promise of timestamping in a precise Distributed Ledger. 194 Calendar 195 A calendar is simply a collection of Distributed Ledger 196 Attestations. 198 Calendar Server 199 A server providing remote access to a collection of Distributed 200 Ledger Attestations. 202 3. Symbols And Abbreviations 204 PKI 205 Public Key Infrastructure 207 TTP 208 Trusted Third Party 210 TSA 211 Time-Stamping Authority 213 TST 214 Time-Stamp Token 216 TSU 217 Time-Stamping Unit 219 DL 220 Distributed Ledger 222 DLA 223 Distributed Ledger Attestation 225 4. DL Attestation 227 A Digital Ledger can be seen as an untrusted logger - serving a 228 number of clients who wish to store their events in the log - kept 229 honest by a number of auditors who will challenge the logger to prove 230 its correct behaviour [CrosbyWallach]. 232 A Merkle Tree data structure accomplishes this in a very efficient 233 way by aggregating many requests and submitting periodically to the 234 log only the root digest of the tree. This log is built as a hash 235 chain (aka blockchain) of small blocks of data. Consequently, the 236 entire chain can be shared and maintained by a large number of nodes, 237 becoming a distributed system. 239 In a permissioned DL the number of nodes can be small enough to 240 permit a quick synchronization and reach consensus concerning the 241 state of the chain. In a permissionless DL the large number of nodes 242 introduces a relevant delay in order to reach consensus. 244 In the case of Bitcoin, for example, consensus is reached 245 statistically. Usually in an average elapsed time of one hour six 246 new blocks are added to the chain. A block of data that was added 247 before the last six blocks, is considered to be practically 248 immutable. This is due to the high computational power that would be 249 required to rewrite the chain. 251 As a result of this scenario the elapsed time - from the request of 252 aggregation of a digest to the proof consolidated inside the DL, may 253 amount to one hour or more. 255 This is why we distinguish between a *promise* of attestation and a 256 *proof* of attestation. Generally, an Aggregation Server provides 257 only a promise to timestamp the client's digest in the DL. However, 258 when the aggregation is completed and the Merkle Tree root hash 259 recorded in a block within the chain, the promise has not yet been 260 confirmed. 262 Only after reaching consensus on that block can attestation be 263 considered as proof, and made available by the Calendar Server. 265 For the sake of simplicity, the Aggregation Server and the Calendar 266 Server can be implemented as a unique instance. In this document we 267 will generically refer to a Calendar Server indicating both services. 269 The DLA data structure is out of scope in this specification 270 document. Any Calendar Server can define his application protocol 271 and data structure. For this specification the DLA is considered as 272 pure data. 274 5. DL Time-Stamp Objects 276 The ASN.1 structure of Promise type is as follows: 278 Promise ::= SEQUENCE { 279 version INTEGER, 280 calendarFormat UTF8String, 281 dlPromise DLPromise, 282 signerIdentifier issuerAndSerialNumber, 283 serialNumber INTEGER } 285 DLPromise ::= OCTET STRING 287 The ASN.1 structure of Proof type is as follows: 289 Proof ::= SEQUENCE { 290 version INTEGER, 291 calendarFormat UTF8String, 292 dlProof DLProof, 293 signerIdentifier issuerAndSerialNumber, 294 serialNumber INTEGER } 296 DLProof ::= OCTET STRING 298 The fields of Promise and Proof type have the following meanings: 300 * version is the syntax version number. It MUST always be 0. The 301 usage is as described in Section 1.3 of [RFC5652] 303 * calendarFormat is the media type format of the DL attestation. It 304 MUST be a registered application media type, in accordance with 305 procedures laid out in [RFC6838] - for example, if you wanted to 306 use the [OpenTimestamps] format, the calendarFormat value would be 307 the string "application/vnd.opentimestamps.ots" (without quotes) 308 that is the IANA registered Media Type [OTS] 310 * 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 [RFC5652] 315 * signerIdentifier is an IssuerAndSerialNumber type that identifies 316 the TSU signing certificate as described in Section 10.2.4 of 317 [RFC5652] 319 * serialNumber is an integer assigned by the TSA to each 320 TimeStampToken as described in Section 2.4.2 of [RFC3161] 322 5.1. DL Time-Stamp Attributes 324 A set of proofs or a set of promises, generated by a Calendar Server, 325 MAY be included in a TST, using an unsigned attribute of the per- 326 signer information. 328 To grant backward compatibility with any currently available software 329 the unsigned attribute MUST be compliant with the specifications 330 defined in Section 5.3 of [RFC5652] for Attribute type. 332 Attributes including a set of promises and a set of proofs MUST be 333 unsigned attributes; they MUST NOT be signed attributes, 334 authenticated attributes, unauthenticated attributes, or unprotected 335 attributes. 337 The new objects MUST have the following OIDs where id-ce identifies 338 the root of standard extensions as described in [RFC5280]. 340 The ASN.1 structure of attributes including a set of promises is as 341 follows: 343 id-ce-dltsPromises OBJECT IDENTIFIER ::= { id-ce TBD1 } 345 Promises SET OF Promise 347 The ASN.1 structure of attributes including a set of proofs is as 348 follows: 350 id-ce-dltsProofs OBJECT IDENTIFIER ::= { id-ce TBD2 } 352 Proofs SET OF Proof 354 All the proofs and promises that have been returned MUST refer to the 355 same parent TimeStampToken issued at the time of the request. 357 Note that a TSA can return a set of proofs and promises for the same 358 input value as it can use calendar servers operating on different 359 Distributed Ledgers. 361 5.1.1. Response Status 363 The response status code in the TimeStampResp MUST be compliant with 364 the specifications described in Section 2.4.2 of [RFC3161] and 365 Section 5.2.3 of [RFC4210]. 367 According to the TimeStamp policy, when the response contains only a 368 subset of the expected proofs and promises, the status field SHOULD 369 contain either the value one (grantedWithMods) or the value two 370 (rejection). 372 5.2. DL Time-Stamp Extensions 374 Upgrade from a set of promises to a set of proofs MAY be done 375 requesting a new TST including inside a non critical extension the 376 set of promises previously obtained in an unsigned attribute. 378 When the TSA receives a request which has a non critical extension 379 containing a set of promises, it MAY request the Calendar Server to 380 get the corresponding proof for each of them, and MAY include the set 381 of proofs in the TST response, using a non critical extension of the 382 TSTInfo sequence. 384 To grant backward compatibility with any currently available 385 software, request and response non critical extensions MUST be 386 compliant with the specifications described in Section 2.4 of 387 [RFC3161] and Section 4.2 of [RFC5280]. 389 Conforming TSAs MUST mark these extensions as non-critical. 391 The ASN.1 structure of the proof request extension is as follows: 393 id-ce-dltsPromises OBJECT IDENTIFIER 395 Promises SET OF Promise 397 The ASN.1 structure of the proof response extension is as follows: 399 id-ce-dltsProofs OBJECT IDENTIFIER 401 Proofs SET OF Proof 403 The proofs returned in the extensions by the TSA MUST NOT refer to 404 the TimeStampToken issued at the time of the request. Each Proof 405 MUST contain the explicit reference to the pointing TimeStampToken 406 with signerIdentifier (referring to the TSU certificate) and 407 serialNumber (referring to the time stamp serial number), which have 408 been received in the Promise structure of the proof request 409 extension. 411 5.2.1. Response Status 413 The response status code in the TimeStampResp MUST be compliant with 414 the specifications described in Section 2.4.2 of [RFC3161] and 415 Section 5.2.3 of [RFC4210]. 417 Compliant servers SHOULD also use the status field as follows: 419 * according to TimeStamp policy, when the response contains only a 420 subset of the expected proofs, the status field SHOULD contain 421 either the value one (grantedWithMods) or two (rejection) 423 * when in the response no proof can be returned, the status field 424 SHOULD contain the value two (rejection) 426 * when all the received promises recognized by the Calendar Server 427 are pending, the status field SHOULD contain the value three 428 (waiting). 430 5.3. Use case 432 In order to clarify the use of the objects thus defined, the case of 433 a subscription made by two actors at different times, using distinct 434 time stamps, is illustrated below. 436 5.3.1. Promises 438 Since each signer applies a time stamp to his signature, the 439 structure will be presented according to the following simplified 440 scheme, in which each promise is inserted as an unsigned attribute of 441 the time stamp to which it refers. 443 signature-1 444 +--- timestampToken 445 |--- signerIdentifier 446 |--- serialNumber-1 447 +--- id-ce-dltsPromises 448 +--- Promise 449 |--- version 450 |--- calendarFormat 451 |--- dlPromise 452 |--- signerIdentifier 453 +--- serialNumber-1 454 signature-2 455 +--- timestampToken 456 |--- signerIdentifier 457 |--- serialNumber-2 458 +--- id-ce-dltsPromises 459 +--- Promise 460 |--- version 461 |--- calendarFormat 462 |--- dlPromise 463 |--- signerIdentifier 464 +--- serialNumber-2 466 Figure 1: Figure 1 468 Although replicating the signerIdentifier and serialNumber 469 information may seem redundant in the case of a single timestamp, it 470 can never be ruled out that a second signature with a new timestamp 471 will be added later. 473 When you also want to obtain the proof of attestation on the DL, the 474 application will be able to collect the two promises and include them 475 as extensions in a new timestamp request. The result would have the 476 following structure: 478 +--- timestampToken 479 |--- signerIdentifier 480 |--- serialNumber-3 481 +--- id-ce-dltsPromises 482 +--- Proof 483 |--- version 484 |--- calendarFormat 485 |--- dlPromise 486 |--- signerIdentifier 487 +--- serialNumber-1 488 +--- Proof 489 |--- version 490 |--- calendarFormat 491 |--- dlPromise 492 |--- signerIdentifier 493 +--- serialNumber-2 495 Figure 2: Figure 2 497 From this example it is evident that the signerIdentifier and 498 serialNumber pair is necessary to uniquely identify the 499 TimestampToken to which each Proof obtained refers. 501 It is up to the application to choose whether the new timestamp, 502 containing the evidence, will be saved within the same document, 503 containing the promises, or stored separately. 505 6. Security Considerations 507 Each security consideration described in Section 4 of [RFC3161] SHALL 508 be evaluated designing TSA services that include DL Time-Stamp 509 extensions. 511 When a TSA executes a request to a Calendar Server the use of a nonce 512 is RECOMMENDED because using a nonce always allows the client to 513 detect replays. 515 Safety and reliability of the DL proofs depends on the robustness of 516 the hash algorithms and on the stability of the DL, i.e. how 517 expensive or difficult it would be for an attacker to alter the DL. 519 7. IANA Considerations 521 This document does not require any action by IANA. 523 8. References 525 8.1. Normative References 527 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 528 Requirement Levels", BCP 14, RFC 2119, 529 DOI 10.17487/RFC2119, March 1997, 530 . 532 [RFC3161] Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, 533 "Internet X.509 Public Key Infrastructure Time-Stamp 534 Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 535 2001, . 537 [RFC3628] Pinkas, D., Pope, N., and J. Ross, "Policy Requirements 538 for Time-Stamping Authorities (TSAs)", RFC 3628, 539 DOI 10.17487/RFC3628, November 2003, 540 . 542 [RFC4210] Adams, C., Farrell, S., Kause, T., and T. Mononen, 543 "Internet X.509 Public Key Infrastructure Certificate 544 Management Protocol (CMP)", RFC 4210, 545 DOI 10.17487/RFC4210, September 2005, 546 . 548 [RFC5280] Cooper, D., Santesson, S., Farrell, S., Boeyen, S., 549 Housley, R., and W. Polk, "Internet X.509 Public Key 550 Infrastructure Certificate and Certificate Revocation List 551 (CRL) Profile", RFC 5280, DOI 10.17487/RFC5280, May 2008, 552 . 554 [RFC5652] Housley, R., "Cryptographic Message Syntax (CMS)", STD 70, 555 RFC 5652, DOI 10.17487/RFC5652, September 2009, 556 . 558 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 559 Specifications and Registration Procedures", BCP 13, 560 RFC 6838, DOI 10.17487/RFC6838, January 2013, 561 . 563 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 564 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 565 May 2017, . 567 8.2. Informative References 569 [ANSI.X9.95] 570 American National Standards Institute (ANSI), "Trusted 571 Time Stamp Management And Security", 2005, 572 . 574 [CrosbyWallach] 575 Crosby, S. and D. Wallach, "Efficient Data Structures for 576 Tamper-Evident Logging", Proceedings of the 18th USENIX 577 Security Symposium, Montreal, August 2009, 578 . 581 [eIDAS] The European Parliament And The Council Of The European 582 Union, "Regulation (EU) No 910/2014", 23 July 2014, 583 . 586 [ETSI.EN.319.422] 587 European Telecommunications Standards Institute, 588 "Electronic Signatures and Infrastructures (ESI); Time- 589 stamping protocol and time-stamp token profiles", March 590 2016, . 594 [ETSI.TS.101.861] 595 European Telecommunications Standards Institute, 596 "Electronic Signatures and Infrastructures (ESI); Time 597 stamping profile", July 2011, 598 . 602 [ETSI.TS.102.778-4] 603 European Telecommunications Standards Institute, 604 "Electronic Signatures and Infrastructures (ESI); PDF 605 Advanced Electronic Signature Profiles; Part 4: PAdES Long 606 Term - PAdES-LTV Profile", December 2009, 607 . 611 [HaberStornetta] 612 Haber, S. and W. S. Stornetta, "How to Time-Stamp a 613 Digital Document", 1991, 614 . 616 [Hyperledger] 617 The Linux Foundation, "Hyperledger Architecture, Volume 1: 618 Introduction to Hyperledger Business Blockchain Design 619 Philosophy and Consensus", August 2017, 620 . 623 [IMES] Une, M., "The Security Evaluation of Time Stamping 624 Schemes: The Present Situation and Studies (2001)", 2001, 625 . 628 [ISO.IEC.18014-4] 629 International Organization for Standardization, 630 "Information technology - Security techniques - Time- 631 stamping services - Part 4: Traceability of time sources", 632 April 2015, . 634 [Merkle] Merkle, R. C., "Secrecy, authentication, and public-key 635 systems - Technical Report No. 1979-1", June 1979, 636 . 638 [Nakamoto] Nakamoto, S., "Bitcoin: A Peer-to-Peer Electronic Cash 639 System", 31 October 2008, 640 . 642 [NISTIR_8202] 643 Yaga, D., Mell, P., Roby, N., and K. Scarfone, "Blockchain 644 Technology Overview", October 2018, 645 . 647 [OpenTimestamps] 648 Todd, P., "OpenTimestamps: Scalable, Trust-Minimized, 649 Distributed Timestamping with Bitcoin", 15 September 2016, 650 . 652 [OTS] Cisbani, E., "IANA registered OpenTimestamps Media Type", 653 24 June 2021, . 656 [RFC6962] Laurie, B., Langley, A., and E. Kasper, "Certificate 657 Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, 658 . 660 [UK-GCSA] UK Government Chief Scientific Adviser, "Distributed 661 Ledger Technology: beyond block chain", January 2016, . 666 Authors' Addresses 668 Emanuele Cisbani 669 Intesi Group 670 Via Torino 48 671 20123 Milano 672 Italy 674 Phone: +39 026 760 641 675 Email: ecisbani@intesigroup.com 676 URI: https://www.intesigroup.com 678 Daniele Ribaudo 679 Intesi Group 680 Via Torino 48 681 20123 Milano 682 Italy 684 Phone: +39 026 760 641 685 Email: dribaudo@intesigroup.com 686 URI: https://www.intesigroup.com 688 Giuseppe Damiano 689 Entrust 690 One Station Square 691 Cambridge 692 CB1 2GA 693 United Kingdom 695 Email: giuseppe.damiano@entrust.com 696 URI: https://www.entrust.com