Skip to content

Commit

Permalink
splitted spec.md into parts to be able to access terms-and-definition…
Browse files Browse the repository at this point in the history
… in a separate way

Signed-off-by: henkvancann <[email protected]>
  • Loading branch information
henkvancann committed May 31, 2024
1 parent cc37847 commit 23584f1
Show file tree
Hide file tree
Showing 13 changed files with 2,906 additions and 20 deletions.
1,017 changes: 1,017 additions & 0 deletions spec/annex-a.md

Large diffs are not rendered by default.

127 changes: 127 additions & 0 deletions spec/bibliography.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,127 @@
## Bibliography

[[spec]]

[1]. Samuel M. Smith, Composable Event Streaming Representation (CESR), 2022

[1]: https://github.com/trustoverip/tswg-cesr-specification

[2]. C. Bormann, P. Hoffman, Concise Binary Object Representation (CBOR), 2020

[2]: https://www.rfc-editor.org/rfc/rfc8949.html

[3]. Sadayuki Furuhashi, MessagePack, 2008

[3]: https://github.com/msgpack/msgpack/blob/master/spec.md

[4]. Samuel M. Smith, Key Event Receipt Infrstructue, 2021

[4]: https://arxiv.org/abs/1907.02143

[5]. Samuel M. Smith, Universay Identifier Theory, 2020

[5]: https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/IdentifierTheory_web.pdf

[6]. Samuel M. Smith, Decentralized Autonomic Data (DAD) and the three R's of Key Management, 2018

[6]: https://github.com/SmithSamuelM/Papers/blob/master/whitepapers/DecentralizedAutonomicData.pdf

[7]. David Wilkinson, Jorge F Willemsen, Invasion percolation: a new form of percolation theory, 1983

[7]: https://www.physics.purdue.edu/flow/MMproject/Wilkinson1983.pdf

[8]. Information-Theoretic and Perfect Security

[8]: https://en.wikipedia.org/wiki/Information-theoretic_security

[9]. Cryptographically-secure pseudorandom number generator

[9]: https://en.wikipedia.org/wiki/Cryptographically-secure_pseudorandom_number_generator

[10]. Information Theory

[10]: https://en.wikipedia.org/wiki/Information_theory

[11]. Cost analysis of hash collisions: Will quantum computers make SHARCS obsolete?

[11]: https://cr.yp.to/hash/collisioncost-20090823.pdf

[12]. Jean-Philippe Aumasson, Too Much Crypto, 2021

[12]: https://eprint.iacr.org/2019/1492.pdf

[13]. One-way Function

[13]: https://en.wikipedia.org/wiki/One-way_function

[14]. One-way Function

[14]: http://www.crypto-it.net/eng/theory/one-way-function.html

[15]. Public-key Cryptography

[15]: https://en.wikipedia.org/wiki/Public-key_cryptography

[16]. Marc Girault, Self-certified public keys

[16]: https://link.springer.com/content/pdf/10.1007%2F3-540-46416-6_42.pdf

[17]. M. Kaminsky, E. Banks, SFS-HTTP: Securing the Web with Self-Certifying URLs, 1999

[17]: https://pdos.csail.mit.edu/kaminsky/sfs-http.ps

[18]. David Mazieres, Self-certifying File System, 2000

[18]: https://pdos.csail.mit.edu/kaminsky/sfs-http.ps

[19]. David Mazieres, M. Kaashoek, Escaping the Evils of Centralized Control with self-certifying pathnames, 2000

[19]: https://dl.acm.org/doi/pdf/10.1145/319195.319213

[20]. Certificate Revocation List

[20]: https://en.wikipedia.org/wiki/Certificate_revocation_list

[21]. Verifiable Data Structures

[21]: https://github.com/google/trillian/blob/master/docs/papers/VerifiableDataStructures.pdf

[22]. Ricardian contract

[22]: https://en.wikipedia.org/wiki/Ricardian_contract

[23]. Namespace

[23]: https://en.wikipedia.org/wiki/Namespace

[24]. Eclipse Attack

[24]: https://www.gemini.com/cryptopedia/eclipse-attacks-defense-bitcoin

[25]. Percolation Theory

[25]: https://en.wikipedia.org/wiki/Percolation_theory

[26]. First Passage Percolation

[26]: https://en.wikipedia.org/wiki/First_passage_percolation

[27]. Invasion Percolation

[27]: https://www.physics.purdue.edu/flow/MMproject/Wilkinson1983.pdf

[28]. Uniform Resource Locator

[28]: https://en.wikipedia.org/wiki/URL

[29]. QR Code

[29]: https://en.wikipedia.org/wiki/QR_code

[30]. Data Matrix

[30]: https://en.wikipedia.org/wiki/Data_Matrix

[31]. Concise Binary Opbject Representation

[31]: https://en.wikipedia.org/wiki/CBOR
27 changes: 27 additions & 0 deletions spec/foreword.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,27 @@
## Foreword

This publicly available specification was approved by the ToIP Foundation Steering Committee on [dd month yyyy must match date in subtitle above]. The ToIP permalink for this document is:

[permalink for this deliverable: see instructions on this [wiki page](https://wiki.trustoverip.org/display/HOME/File+Names+and+Permalinks)]

The mission of the Trust over IP (ToIP) Foundation is to define a complete architecture for Internet-scale digital trust that combines cryptographic assurance at the machine layer with human accountability at the business, legal, and social layers. Founded in May 2020 as a non-profit hosted by the Linux Foundation, the ToIP Foundation has over 400 organizational and 100 individual members from around the world.

Any trade name used in this document is information given for the convenience of users and does not constitute an endorsement.

This document was prepared by the ToIP Technical Stack Working Group.

Any feedback or questions on this document should be directed to https://github.com/trustoverip/tswg-keri-specification/issues

THESE MATERIALS ARE PROVIDED “AS IS.” The Trust Over IP Foundation, established as the Joint Development Foundation Projects, LLC, Trust Over IP Foundation Series ("ToIP"), and its members and contributors (each of ToIP, its members and contributors, a "ToIP Party") expressly disclaim any warranties (express, implied, or otherwise), including implied warranties of merchantability, non-infringement, fitness for a particular purpose, or title, related to the materials. The entire risk as to implementing or otherwise using the materials is assumed by the implementer and user.
IN NO EVENT WILL ANY ToIP PARTY BE LIABLE TO ANY OTHER PARTY FOR LOST PROFITS OR ANY FORM OF INDIRECT, SPECIAL, INCIDENTAL, OR CONSEQUENTIAL DAMAGES OF ANY CHARACTER FROM ANY CAUSES OF ACTION OF ANY KIND WITH RESPECT TO THESE MATERIALS, ANY DELIVERABLE OR THE ToIP GOVERNING AGREEMENT, WHETHER BASED ON BREACH OF CONTRACT, TORT (INCLUDING NEGLIGENCE), OR OTHERWISE, AND WHETHER OR NOT THE OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.


::: issue
https://github.com/trustoverip/tswg-keri-specification/issues/47
:::

[//]: # (:::)

[//]: # (\newpage)

[//]: # (::: introtitle)
33 changes: 33 additions & 0 deletions spec/header.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,33 @@
Key Event Receipt Infrastructure (KERI)
==================

**Specification Status**: v1.0 Draft

**Latest Draft:**

[https://github.com/trustoverip/tswg-keri-specification](https://github.com/trustoverip/tswg-keri-specification)

**Author:**

- [Samuel Smith](https://github.com/SmithSamuelM), [Prosapien](https://prosapien.com/)

**Editors:**

- [Kevin Griffin](https://github.com/m00sey), [GLEIF](https://gleif.org/)

**Contributors:**

**Participate:**

~ [GitHub repo](https://github.com/trustoverip/tswg-keri-specification)
~ [Commit history](https://github.com/trustoverip/tswg-keri-specification/commits/main)

[//]: # (\maketitle)

[//]: # (\newpage)

[//]: # (\toc)

[//]: # (\newpage)

[//]: # (::: forewordtitle)
17 changes: 17 additions & 0 deletions spec/introduction.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,17 @@
## Introduction

[//]: # (:::)

The original design of the Internet Protocol (IP) has no security layer(s) [[spec: RFC0791]], providing no built-in mechanism for secure attribution to the source of an IP packet. Anyone, including any intermediary, can forge an IP packet, and a recipient may not be able to ascertain when or if the packet was sent by an imposter. This means that secure attribution mechanisms for the Internet must be overlaid. This documents presents an identifier system security overlay, called the Key Event Receipt Infrastructure (KERI) protocol, that serves as a trust spanning layer for the Internet. This overlay includes a primary root-of-trust in a Self-certifying identifier (SCID) that provides a formalism for Autonomic identifiers (AIDs), Autonomic namespaces (ANs), and the basis for a universal Autonomic Identity System (AIS).

The KERI protocol provides verifiable authorship (authenticity) of any message or data item via secure cryptographically verifiable attribution to a SCID as a primary root-of-trust [[ref: SCID]] [[4]] [[16]] [[18]] [[19]] [[17]] [[15]]. This root-of-trust is cryptographic, not administrative, because it does not rely on any trusted third-party administrative process but may be established with cryptographically verifiable data structures. This cryptographic root-of-trust enables end-verifiability where every data item may be cryptographically attributable to its source by any recipient verifier without reliance on any infrastructure not under the verifier's ultimate control. Therefore, KERI has no security dependency on any other infrastructure and does not rely on security guarantees that may or may not be provided by the traditional internet infrastructure. This makes intervening operational infrastructure replaceable, enabling ambient verifiability (Verifiable by anyone, anywhere, at any time).

A SCID is strongly bound at inception to a cryptographic keypair that is self-contained unless control over the SCID needs to be transferred to a new keypair. The KERI protocol provides end-verifiable control provenance over a variant of SCID, called an Autonomic identifier (AID), via signed transfer statements in an append-only chained Key event log (KEL). The key management operation for tansferring control over an AID is implemented via a novel key [pre-rotation](#key-rotationpre-rotation) scheme [[6]]. With pre-rotation, a control over an AID can be re-established by rotating to a one-time use set of unexposed but pre-committed rotation keypairs. This approach fixes the foundational flaw in traditional Public key infrastructure (PKI), which is insecure key rotation. KERI enables decentralized public key infrastructure (DPKI) that is more secure and more portable. KERI may be viewed as a viable reboot of the Web-of-Trust concept for DPKI because KERI fixes the hard problem of DPKI which is key rotation.

Two primary trust modalities motivated the design of the KERI protocol, namely a direct (one-to-one) mode and an indirect (one-to-any) mode. In the direct mode, two entities establish trust over AIDs via a direct exchange of their counterparts' verified signatures. In the indirect mode, trust over AIDs depends on witnessed Key event receipt logs (KERLs) as a secondary root-of-trust for validating key events. The security and accountability guarantees of indirect mode are provided by KERI’s Algorithm for Witness Agreement (KAWA) among a set of key event Witnesses. The KAWA approach may be much more performant and scalable than more complex approaches that depend on a total ordering distributed consensus ledger. Nevertheless, KERI may employ a distributed consensus ledger when other considerations make it the best choice.

The KERI approach to Decentralized key management infrastructure (DKMI) allows for more granular composition. Moreover, because KERI is event streamed, it enables DKMI to operate in-stride with data events streaming applications such as web 3.0, IoT, and others where performance and scalability are more important. The core KERI engine is identifier namespace independent. This makes KERI a candidate for a universal portable DKMI. This system uses the design principle of minimally sufficient means for appropriate levels of security, performance, and adoptability to be a viable candidate as the DKMI that underpins a trust-spanning layer for the Internet.

[//]: # (\mainmatter)

[//]: # (\doctitle)
Loading

0 comments on commit 23584f1

Please sign in to comment.