Papers

'UNIVERSAL IDENTIFIER THEORY! ‘Samuel M. Smith, Ph.D. v1.40 2025/09/14, Original 2020/10/20 Abstract—A universal theory for identifiers is presented. This theory is based on a unified model of identifiers that includes cryptographic autonomic identifiers (AIDs) and legitimized (autho- rized) human-meaningful identifiers (LIDs). This model provides truly decentralized trust bases each derived from the cryptographic root-of-trust of a given AID. An AID is based on a self-cer- tifying identifier (SCID) prefix. Self-certifying identifiers are not human-meaningful but have strong cryptographic properties. The assaciated sclf-certifying trust basis gives rise to a trust do- main for associated cryptographically verifiable non-repudiable statements. Every other type of identifier, including human-meaningful identifiers, may then be secured in this resultant trust do- main via an end-verifiable authorization. This authorization legitimizes the human meaningful identifier as an LID through its association with an AID. The result is a secured trust domain- specific identifier couplet of aid|/id. AIDs arc provided by the open standard key event receipt infrastructure (KERT) [42]. This unified, universal model provides a systematic methodology for designing and implementing secure, decentralized identifier systems that underpin decentralized trust bases and their associated ecosystems of interactions. Index Terms—Autonomic Identifier, AID, Autonomic Identity System, AIS, Autonomic Namespace. Decentralized, Key Management Infrstructure, DKMI, Key, Event, Receipt, Pr-rotation, Rotation, Event, Srcamin, KER, KERL, KEL, KA2CE, Post-Quantum Sccurity, Sclf-Sovercign Identity, SSI. 1 INTRODUCTION

A design goal for an identifier system is that it be secure, trustable, and universal. A system that is insecure may not be trusted, and a system that is neither secure nor trusted is not a viable candidate for universal use. Therefore security is of paramount importance. It is the foundation for any other useful property of the identifier system.

1.1 Unified Model of Identifiers

We use the term identifier system instead of identity system to emphasize that it is the proper- ties of the identifier that are first and foremost. The identifier properties imbue the associated identity system with its operative propertics. Indeed, we use a narrow definition of identity to crystallize our understanding of the associated system. We formally define a (digital) identity to be a (digital)

identifier plus attributes. The attributes themselves may include identifiers thereby enabling complex identities which may be represented by an identity graph. A subsct of a graph is a tree or a forest.

In general, we want to have a theory or model of how to design identifier systems with desir- able properties. As mentioned above, some desirable properties are security, trustworthiness, and universality. Historically, identifier systems have been designed without any unifying theory to guide the designers. This means that many identifier systems are largely bespoke to a given ap- plication. This may be problematic, especially when the identifier system does not have a well- defined approach to security. More recently, explicitly characterizing identifier propertics has gained some recognition as a prerequisite to identifier system design. For example, the well known Zooko's triangle or trilemma is based on recognizing a conflict between three different

1. https://keri.one

140

desirable properties for an identifier [61]. The three properties are human-meaningfil, secure, and decentralized. The trilemma states that an identifier may have any two of the three proper- ties by not all three. Some have claimed to have solved the trilemma by using a hybrid identifier system where human-meaningful but insecure identificrs may be registered on a distributed con- sensus ledger. The registration process itself uses identifiers that are secure and decentralized but not human-meaningful [50]. The fact that not one identifier but a combination of identifiers is needed to solve the trilemma hints that the identifier model therein employed is incomplete. A notional diagram of Zooko’s triangle is shown below: decentralized | ) Zooko's Triangle of v Igentife Properties . | e

Figure 1.1, Zooko’s Triangle

In our work, we have developed a unified universal model of identifiers (digital) called the autonomic identifier model (AID) [42]. This model takes a sccurity-first approach. The model is based on the recognition that all other propertics of an identifier are of lttle value if the identi- fier is not securely controlled. The AID model is based on a formal theory of identifiers that we have been developing for several years [9; 11; 35; 41-4649). All identifiers may now be classi- fied and described within the framework of this theory. This model provides a principled ap- proach to identifier system design. This may be used to inform and guide the design and devel- opment of any conerete implementation.

1.2 Identifier Control and Trust Basis

As mentioned above, the property that is of paramount importance to an identifier system is security. The dictionary definition of secure is free from or not exposed to danger or harm; safe. For identifiers, security typically means secure from exploit or compromise. More specifically, an identifier is secure with respect to an ensity if there is a mechanism by which that entity may prove it has control over the identifier. The entity with such provable control we call the con- iroller of the identifier. We may use sccure identifiers in an identity system security overlay to sccure other systems that do not have secure identifiers [42]. An important use case may be the Internet because the Internet Protocol (IP) has no sccurity mechanism for its IP addresses as identifiers. Likewise, any existing insecure identifier system may be secured by using a secure identificr system as a security overlay [42].

Th

e problem we face is how best to prove control over an identifier (digital). There arc many such mechanisms that have been used over the years. This begs the question: Is there one mecha- nism that is sufficiently superior that it may be used as the universal basis for identifier security? AID theory ansiwers that question with an unequivocal yes! That mechanism is rooted in a prop-

210

ety called self-certification. A self-certifying identifier (SCID) exhibits this property. Self-certi- fication s based on well-established asymmetric cryptographic operations for digital signatures, ‘where the identificr is uniquely derived using cryptographic one-way functions from a source of information entropy captured by the controller [19; 34; 36; 37; 42]. This property cryptographi- cally binds the identifier to the controlling asymmetric key-pair or key-pairs. This forms a secure cryptographic root-of-trust for the identifier.

A root-of-trust is some component of a system that is secure by design and it sccurity charac- teristics may be inherently trusted or relied upon by other components of the system. In a more general sense, the security of an identifier system is a function of its trust basis. A root-of-trust may form that trust basis. A self-certifying identifier is derived using cryptographic one-way functions with known cryptographic strength. For example, consider a basic SCID that is pre- fixed with a public key where that public key is derived from a private key. Suppose that the public key derivation algorithm (one-way function) has 128 bits of cryptographic strength. This means that as long as the private key remains private, an attacker has to perform something on the order of 2'** operations to brute force invert the derivation algorithm. This is practically in- feasible. Seceurity is then becomes a function of the protection of the secrecy of the private key. High sccurity may be ensured through best practices in key management.

The root-of-trust and hence the trust basis for a SCID is inherently decentralizable. Only the entity that captures sufficient random or pseudo-random entropy to gencrate the private key may derive and prove control over the resulting public key and therefore the resulting SCID. Thus, any cntity with a cryptographic strength pscudo-random number gencrator (c.g., a computer) may be the sole controller over the resulting SCID. The controller may choose to manage its keys in a non-decentralized way. But centralized key management is not necessary and is typi- cally less secure. The governance mechanism for the identifier is at the discretion of the con- troller. Thus, any position on a spectrum of centralization/decentralization is possible. Moreover, because the SCID includes the public key or some cryptographically derived material (a large pseudo-random string of characters), the identifier is universally

unique [2]. This SCID may then be used as a prefix for a namespace using a URL-like approach [54]. All identifiers in that name- space then share the same uniquely provable cryptographic root-of-trust. So a SCID comes with three very important propertics:

• Self-contained secure cryptographic root-of-trust
• Decentralized control via private key management
• Universally unique identifiers

But a SCID that does not support rotation of the underlying key-pairs is not sustainable as a persistently sccure identifier. Eventually, through exposure due to use, the key pairs may become ‘weakened. Advances in cryptographic exploits may also make them weak over time. Thus, a tru- Iy sceure system needs the ability to rotate the key pairs to new ones. SCIDs with this capability we call self-managing sclf-certifying identifiers or autonomic identifiers (ATDs). The meaning of the word autonomic is self-managing so an AID is a non-trivial SCID. This is explained in more detail in the next section. However, relevant here is that we may use an AID as the root of trust to form what we call an autonomic trust basis. This is diagrammed as follows:

340

autonomic st basis contrller | U e i s oot A e Koy eventlog — NG s stony sy Sy s o . /S idat iy N\ [ vaator | bopar '+ gl ot Figure 1.2, Autonomic trust basis Two other trust bases are in common use for identifier systems. One we call algorithmic. An algorithmic trust basis relies on some network of nodes running some type of Byzantine fault- tolerant, totally ordering, distributed consensus algorithm for is root-of-trust. These networks are more commonly known as a shared ledger or blockchain, such as Bitcoin, Ethereum, or Sovrin [6-817; 47]. The primary exploit of a pool of nodes running such an algorithm s to sub- om or gain control of a majority of the nodes. Depending on the algorithm, such an exploit may not necessarily require inverting any cryptographic one-way functions. In a permissionless proof-of-work blockchain, for example, it may require capturing 51% of the hashing power of the nodes on the network. An algorithmic (blockchain) root-of-trust, however, may be very se- cure. Distributed consensus algorithms have well-known security properties [51]. The difference is that a network algorithmic root-of-trust is critically dependent on the network infrastructure (the ledger and nodes that wric to the ledger). This locks the identifiers to that specilfic instance of infrastructure. In other words the associated identifiers are not portable. Should the ledger go away, so does the root of trust. One may characterize a ledger as a centralized logical construct that is governed in a decentralized manner. Thus, the degree of decentralization is less than a self-certifying cryptographic root-of-trust (autonomic). In addition, ledgers tend to be relatively expensive, slow, and with low throughput. This makes using them as a root-of-trust much more constrained than a cryptographic root-of-trust. Thus, from a property point of view, a crypto- graphic root-of-trust (autonomic) is generally superior 1o a network algorithmic (blockchain) root-of-trust. An algorithmic trust basis is diagrammed below: algoihnic trust basis { controller | 5 gt st A ‘ shared ldger 4 A h arfes Sy s kN sy g x /- \ e valdator Key-pair -+ gperd ——+ _idenifer algorithm | w0

Figure 1.3, Algorithmic trust basis

The other commonly used trust basis in identifier systems is an administrative or organization- al trust basis, i.e., a trusted entity. It is difficul, if not pathologically so, to characterize the roots of trust of a trusted entity. Security may be dependent on something as nebulous as employee ‘morale. At it root, the Intemet Protocol (IP) was not designed with sccurity as a first-class prop- erty. Instead, Internet security is usually provided via a bolted-on identity system sccurity over- lay. The sceurity overlay in most widespread usc is the open hierarchical Domain Name System plus Certificate Authorities (DNS+CA) [13; 14]. The DNS Certificate Authority system trust ba- sis is administratively derived from the assumed "trusted” entities that are the certificate authori- ties. It uses the Transport Layer Sccurity (TLS) protocol and X.509 certificates [10; 53; 60]. As is well known, internet infrastructure based on DNS+CA continues to exhibit security vulnera- bilities even when organizations follow best practices for conventional security system design and exhibit high levels of operational integrity [1; 3-518; 23; 24; 29; 40; 48]. Given the history of continuing exploits of such a trust basis, it is decidedly inferior from a security perspective to cither cryptographic or network algorithm-derived trust bases. By comparison, identifiers issued in such a system with an administrative trust basis are neither secure nor decentralized. An ad- ‘ministrative trust basis is diagrammed below:

adminstrtive bustbasis controller genoraes - sourceotindh S datzbase / atlos s < \ ot - < . / Rt marsges | validator Key-pair | identiier administrator | Figure 1.4, Administrative trust basis 1.3 Sclf-Managing Sclf-Certifying Identificrs (AIDs)

Although a self-certifying identifier (SCID) employs a cryptographic root-of-trust, it by itself does not provide control over an identifier that may persist in spite of a compromise of the key- pai(s) used to derive the identifier. Persistent control in spite of key compromise is the hard problem of key management. The typical solution to this problem is a mechanism for key rota- tion. Key rotation involves the revocation and replacement of the current controlling set of key- pair(s) with a new set. We call identifiers in a self-certifying identifier system that includes a se- cure key rotation mechanism self-managing self-certifying identifiers. There are other key man- agement mechanism

s, such as delegation, that a system may also exhibit. As a shorthand, we call such & system an autonomic identifier system (AIS), and the associated identifiers are autonomic identifiers (AIDs). The meaning of the word autonomic is self-governing or self-managing and comes from the Greek auto-nomos or literally translated self-rule. Thus, autonomic identi- fiers (AIDs) are self-certifying identifiers (SCIDs) that may include other self-managing proper- ties such as key rotation. The Key Fvent Receipt Infrastructure (KERI) is an open standard

s

‘mechanism (protocol) for an autonomic identifier system (AIS) [11; 35; 42]. KERI provides sup- port for fully decentralized portable sccure key management operations on self-certifying identi- fiers. KERI relies on key event logs (KELS) of key management events such as rotation and del- cgation. These logs are cryptographically verifiable, hash-chained, and signed data structures. A KEL provides proof of control authority of a given set of keys over an AID. This proof of con- trol authority is end-verifiable by any verifier to the cryptographic root-of-trust of the AID. Its verifiability is not dependent on any intervening infrastructure or trusted entity. The details of KERI are beyond the scope of this paper but may be found here [11; 35; 42]

The function of KERI is to establish control authority over an identifier (AID) in a crypto- ‘graphically secure and verifiable way. Once that control authority has been established, a verifier may then sccurely verify any associated authorizations issued by the controller of the AID. ‘These authorizations have the form of a signed authorization statement, where the statement typ- ically includes the AID under which the authorization is issued. A verifier may then verify the authorization by verifying the attached signature using the keys that were authoritative at the time the authorization was issucd. These authorizations are seeure to the extent that the estab- lished control authority is secure. The authorizations inherit their security from their associated AID. The trust domain of an AID is the set of statements that may be securely verified as being issued by the controller of that AID (along with any associated transactions or interactions). Au- thorizations both inhabit and are protected by this trust domain. In other words the authoriza- tions are under the acgis of the AID (or equivalently the controller of the AID) that issued them.

Authorizations may take many forms. One form of particular interest is the W3C Verifiable Credential (VC) standard [35]. Verifiable credentials use the W3C Decentralized Identifier (DID) standard [57]. The DID standard provides name spacing syntax for decentralized identi- fiers that is evocative of URIs [54]. A given DID may be a type of AID but not all DIDs are AIDs. Furthermore, because AIDs may use other namespace syntax standards besides DIDs, not all AIDs are DIDs. KERI itself is name space agnostic, so may be used to support AIDs in any ‘name space that accepts pseu

do-random strings as an element 1.4 Legitimized Human Meaningful Identifiers (LIDs)

Given an AID, we may now unify the other desirable property of an identificr, that is, human ‘meaningfulness. In contrast, the cryptographic material in an AID makes it decidedly non-human ‘meaningful. The AID is represented succinetly by its cryptographic prefix. The prefix is a cryp- tographically derived pseudo-random sequence of characters. For example, a 32 character AID prefix may be as follows:

EXG5YgaL6L48pf0fu7IUhLOJRAU2 RxFPOALA3wYn148 (L1)

Such a long pseudo-random string of characters is the antithesis of human meaningfulness. In contrast, examples of human meaningfulness might be easily recognized words or names or some efficiently hicrarchically organized composition of characters. Human meaningfulness has two limiting characteristics. The first is scarcity, which exhibits itself in various undesirable ways, such as name squatting or race conditions to register or otherwise assert control. More im- portantly, there is no inherent scurity property of a human-meaningful identificr. This makes them insccure by default, Nevertheless, given the trust domain of an AID, any human meaning- ful identifier may be uniquely authorized, sanctioned, or legitimized within that trust domain. Because only the controller of the ATD may issue verifiable authorizations associated with that AID, that controller alone may authorize the use of any human-meaningful identifier under the aegis of its trust domain. The associated authorization statement legitimizes the use of that ‘human meaningful identifier within the trust domain. This gives rise to a new class of identifier, a legitimized or authorized human meaningful identificr, and uscs the acronym LID. The impor-

Iz

tant property of an LID s that it is verifiable with respect to a given AID. The pair forms a new identifier couplet that we may represent as follows:

aidlid 12 where aid represcnts the cryptographic identifier prefix of an AID, the vertical bar, |, represents the legitimizing authorization, and fid represents the legitimized human meaningful identifier. ‘This couplet may be diagrammed as follows:

Ao | Figure L5, AIDILID couplet

‘This coupling is a special type of name spacing. For example, conside an LID as a library Dewey Decimal code for a book such as:

625.127C125¢ w3

Using the AID prefix example from above, the full aid|lid couplet may be expressed as follows:

EXq5YGaLeLABpE0£uTIURLOTRAUZ RXFPOALA3w¥n148]625.127C1257 (1.4)

‘The trust domain of an AID provides & context in which to interpret the appearance of any LID. The AID s implicd by the context. This means that the AID may not need to be prepended or appear with the LID. This allows the human meaningfulness of the LID to exhibit itsclf with- out being encumbered by the AID. Any verifier of the LID, however, knows from the given con- text how to cryptographically verify the legitimacy of the LID. This model of an aid|lid couplet unifies all desirable identifier properties into one identifier system model. The AID part provides the security infrastructure, while the LID part provides the application-specific human meaning- fulness. The connection between the two is provided by a legitimizing authorization represented by the |. With this model, there is no longer any global scarcity associated with a given LID be- cause cach AID may have s own copy of the LID. Scarcity only occurs within the trust domain of cach AID but is completely managed by the controller of that trust domain (AID).

To further explicate this concept, we may characterize any aidllid couplet as consisting of two classes of identifiers, primary and secondary. Primary identifiers are AIDs and are self-certify- ing to a cryptographic root-of-trust. Secondary identifiers are LIDs and are not self-certifying but are secured under the acgis of an associated primary identifier's trust domain. A fertiary class of identifier has no external security properties but may be useful within the confines of an ap- plication user interface or other local content. In other words, rertiary identifiers are unsecured and may only be used internally or where security is unimportant, whercas primary and scc- ondary identificrs may be used extern

ally. A primary may appear alone, but a secondary must ci- ther appear within the known context of primary or as a couplet with the primary ilsclt. This trust domin contextualization s shown n the following diagram:

TAD AID Trust Dorain [ uo || uo e [} Figure L6, LIDs within the context of an AID trust domain

“This unified model of primary, secondary, and tertiary identifiers may now be used to guide the design of any identificr system. The design of the primary AID may be tuned to the specific security, performance, and governance propertis of the application. The design of the sccondary

740

LID may be tuned to provide any other desirable human-meaningful properties of the identifier. And all other identifiers are tertiary. 1.5 Reputational Trust

In the context of an autonomic identifier system, trust has two distinct meanings or types. The firstis trust in the cryptographic sccurity of the root of trust for the AID and its associated verifi- able statements. The second s trust in the controlling entity of the private keys. The first type of trust s limited to the ability to cryptographically verify non-repudiable signed statements. These provide consistent, universal, secure attribution of any statement to the controller of the private keys. In other words, we may trust in who said something, and we may prove that what they say i consistent (non-duplicitous) or not. But we may not trust in the veracity of what was said. For this, we need the second type of trust. This second type of trust s often referred to as reputation- al trust. Tt is a trust that an entity will make accurate statements; that is, the entity is reputable. ‘The dictionary definition of reputable is held in good repute; honorable; respectable; estimable, considered 10 be good or acceptable usage; standard. The related word reputation is a noun meaning the estimation in which a person or thing is held, especially by the community or the public generally. Reputation is a measure of accumulated consistent behavior. It can be evaluat- ed at different levels of granularity. The root of reputation comes from the Latin word reputdre, which is equivalent to re +putdre, that s, to re-think or re-consider.

Identifier systems need both attributional trust and reputational trust. The first, derived from consistent attribution, enables us to trust that a statement was made by an entity (who), and the sccond, reputation, enables us to trust in what that entity said.

‘Taken together, these form @ trust balance. For example, a verifiable credential issued by an entity is only of value if we can trust both that the entity indeed issued it and that the contents, attributes, or claims of the credential are accurate. Cryptography allows us to verify that the is- suer truly ereated the credential, but we must trust the institutional, organizational, behavioral in- tegrity, or reputation of the issuer in order to trust in what the credential asserts. The latter re- quires reputational trust in the issucr of the credential. Another way of understanding this trust balance is that the primary val

ue in any issuance of information is dependent on the veracity of that information, and tha veracity is dependent on the credibility (reputation) of the issucr, but we may only securcly associate that reputation with that information if the authenticity of the is- suer is established. First, authenticity (AID), and then veracity (LID). This dependency is shown in the following diagram.

veracly ‘authenticity Figure 1.7. Veracity dependency on authenticity.

It is this reputational form of trust that makes a goveming organization that authorizes LIDs within the context of their AID so valuable to the associated ecosystem. The integity, consisten- cy, and repeatability of the organizational procedures used to issue authorizations for LIDs are essential to reputational trust.

80

‘The aid|lid coupling mirrors this trust balance. We rely on cryptography for the trustworthy es- tablishment of the control authority of the controller of the AID. And we rely on the reputational integrity of the controller to trust that a given LID has been authorized correctly.

A common use of reputation is as a considered evaluation of how someone has behaved in the past, providing an estimation of how they might behave in the future. In other words, reputation is a measure of past behavior that may be used to predict future behavior. The context of a repu- tation may also be important; that s, past behavior may be a better predictor of future behavior when applied to similar contexts. Reputation is based on proof of consistent behavior, which re- quires provably consistent atribution, which brings us full circle. Provable trust in the AID ‘mechanism enables provable trust in the entity behind the LID mechanism.

1.6 Root AID Establishment via e/ Known Reputational Association.

The aid]lid couplet is an example of a very short chain-of-rust. The anchor or root link to that chain is the AID. But in order for such an ATD to be usable, it must be universally recognized as the authoritative identifier for a given entity. Because an AID is self-certifying, the identifier it- self includes a universally unique pseudo-random string of characters. So there may be only one. But the problem is knowing which identifier is the one and only one authoritative identificr. As described previously, such strings are not human-meaningful. Therefore, they are not easily rec- ognized as the authoritative identifier. The process that establishes an AID as the root identifier with an organization may be called a well-known reputational association. Once this connection between root AID and organization becomes common knowledge, then it is secure.

To claborate, an AID prefix s cryptographic material. Best practice is to derive it via crypto- graphic one-way functions that maintain 128 bits of information-theoretic entropy. Given this recognition, such a self-certifying identifier may practically be used as the root-of-trust for all other activity associated with the entity that controls the identificr. Control is established by virtue of possession of the private keys from which the identifier was derived. This enables a se- cure bootsirap mechanism whereby the controller may securely issue other identifiers or authorizations,

Because the identifier is not human-meaningfu

l, it may not be casily recognized as the authori- tative root identifier (AID). Consequently, the identifier must first become well-known as author- itative for that entity. This association becomes secure once it has become sufficienty well known that an attacker may not fool any verifier into recognizing a different identifier as the au- thoritative root identifier. In other words, the association between the AID and the entity must become common knowledge.

The process of clevating an identifier to well-known (i.e., common knowledge) status may leverage several other already well-known URLS or registration mechanisms that verifiably as- sociate the AID with the entity [38]. These well-known mechanisms may employ some vetting process to accept a registration. Or they may consist of already well-known resources under the control of the entity, wherein the entity provides a statement that links the enity to the new AID. ‘The strength of the well-known establishment is multiplied by the number of such associations, i.e., it provides a reputational source of trust.

Any verifier may thereby check multiple redundant well-known resources or registries to con- firm that indeed the entity has declared the identifier as its authoritative AID. Once the authorita- tive status of the root AID is cstablished via this well-known process, then any other identifier's authoritative status may be established merely via signed statements using the authoritative con- trolling key-pairs of the root AID. Because the root ATD is self-certifying and self-managing, the

90

public keys from the set of authoritative key pairs may be extracted from the identifier itself or, if rotatable, from its unique, verifiable key event log (KEL).

When the AID is expressed as a W3C DID (decentralized identifier), the associated DID:Doc may use the following draft specification to provide references to verifiable credentials (VCs) that link the identifier to well-known URLS (domains) [38; 58]. The process of establishing the authoritative nature of an identifier using well-known locations (URLS) is standardized in IETF RFC-8615 [38]. The RFC-8615 approach reserves a specific path component /.well- xnown/ of a URL in cach DNS domain that provides well-known metadata about some other resource. Consequently, metadata about an AID may be provided by the entity that controls the DNS domain, an authoritative association between the AID and the controlling entity or some other entiy.

This well-known path prefix, /.well-known, is reserved in HTTP, HTTPS, WebSacket (WS), and Secure WebSocket (WSS) URIs for these well-known locations. For example, the URL prefix myentity.com/zoot-identifer/.well-known/ could retum a docu- ‘ment that specifies the actual AID as being the root self-certifying identifier for the entity that controls the domain name myentity. com.

The concept of well-known or common knowledge associations is similar to the concept of rich presentation of verifiable credentials [12]. A rich presentation makes the likelihood of the interseetion of all the credentials by any but the true controller vanishingly small. Likewise, as- sociations provided by multiple well-known locations may establish with high likelihood the au- thoritative nature of a given AID. Consistent common knowledge s the root of reputational trust by which the credibility of an association may be established. One need merely establish with sufficient redundancy a given association to be trustworthy.

In summary, because AIDs are self-certifying, they have a secure primary cryptographic root- of-trust that is end-verifiable. The well-known establishment process deseribed above may se- cure the connection between the entity and the first link in this chain. Given a sufficient degree of common knowledge that a given AID is the first link in the verifiable chain-of-trust for an entity, then any subsequent links in the chain may be established by cryptographically verifiable attestation via the preceding link. Given this chain of trust, other items of data, such as verif

iable credentials or LIDs, may be securely associated with the chain. Any subsequent attestations may extend the chain-of-trust in a sccure manner. Any subscquent links are not vulnerable because they may be cryptographically verifiably authorized by a chain-of-trust back to the root-of-trust, which s the AD itsclf.

1.7 Examples of LIDs

Various standards bodies or industry organizations act as reputable body that authorizes or le- gitimizes the issuance of LIDs for a given industry. These LIDs are human-meaningful in the sense that they follow a structured syntax that is not cryptographic. Although they may not be human-friendly, they are still human-meaningful from their structure. Usually, the issuance of an LID uses an administrative trust basis.

One example of an industry LID would be the GLEIF legal entity identifiers (LEI) [31-33] Another example is the set of GS1 GTIN or SGTIN electronic product identifiers (eP1) [15; 16; 25; 26; 28; 30; 56]. By making the issuance a verifiable authorization via a VC from an AID with a cryptographic root of trust, these identifier systems may inherit the security of the AID in the form of a couplet.

100

For example, GLEIF's Legal Entity Identifier (LEI) may be viewed as a type of LID (legit- imized human meaningful identifier) [31-33]. An LEI code specifically is a hierarchically struc- tured 20-character string. An example LEI may be expressed as follows:

2543000PPUB4GMB3MG36 (L5) GLEIF may create a trust domain based on GLEIF's sole control over a root AID . Lets call this root AID the GLEIF AID or GID for short. The GID is uniquely represented by its cryptographic prefix. Suppose this s given by: EXg5Yqal6L48pf0fu7IUhLO0JRaU2_RxFPOALA3wYn148 (1.6) ‘The resultant gid]lei couplet may be represented as follows: EXq5YqaLeL4Bp<0 £uT IURLOIRAUZ_RXkFEOALAIunL4E |2543000P2U8AGHEINGIS (1.T)

Within the GLEIF GID trust domain, GLEIF may issue authorizations that legitimize any number of LIDs in the form of LEIs. The authorizations make the LEI verifiable to the root-of- trust of the GID. Thus, these may be called verifiable LEIs. The entities that participate in the GLEIF ecosystem may have their own trust domains protected by their own AIDs. They may re- ceive authority to issue LEIS against their verifiable AID. But this enables the ccosystem sccuri- ty to be based on sceure eryptographic roots-of-trust, not merely administrative roots-of-trust,

As a further example, a GS1 SGTIN is a hierarchically structured 23-character string [15; 16; 25,26, 28, 30; 56]. An example SGTIN may be expressed as follows:

4815061414100073431459 (1.8) As described previously, a trust domain is based on some entity's sole control over a root AID. Let’s call this root AID the GS1 AID or GID for short. The GID is uniquely represented by its cryptographic prefix. Suppose this is given by: EXq5YqaL6L4BpE0fuTIUhLOJRAU2_RxFPOALL3uYn148 19 ‘The resultant gidsgtin couplet may be represented as follows: EX5YqaLELASp£0£uTIVALOIRAUZ RXFPOALA Y148 14815061414100073432459 (1.10)

Within the GS1 trust domain of its AID, GS1 may issue authorizations in the form of VCs that legitimize any number of LIDs expressed as SGTINs. The authorization makes the associated SGTIN verifiable to the root-of-trust of the GS1 AID. Thus, these may be called verifiable SGTINS. Entities participating in the GS1 ecosystem may have their own trust domains protect- d by their own AIDs. They may receive authority to issue SGTINS against their verifiable AID. But this enables the ccosystem security to be based on secure cryptographic roots-of-trust not ‘merely organizational or administrative roots-of-trust.

Anothe

r LID example is the GS1 GLN for global location number. A GLN is a hierarchically structured 13-character string. GLNs may be used to identify physical locations, operational lo- cations, and legal entities [20-2226; 27]. An example GLN may be expressed as follows:

4567123489098 (1.11)

Given the same GID and associated trust domain for GS1 as above, the resultant gid|gln couplet may be represented as follows:

EXq5YqL6L48p£0£uT TUNLOJRAV2_RRFPOALA3wYn148 4567123185098 12

An ecosystem participant might use a combination of LIDs of different types from multiple trust domains. But any other participant will be able to end-verify the authorization status of that combination to the associated cryptographic roots-of-trust of each of the LIDs.

1140

1.8 Identifier System Security Overlay Propertics

Any identifier system security overlay may have some degree of any combination of the fol- lowing three properties: privacy, authenticity, and confidentiality (PAC), but not all three com- pletely. Specifically, one can get two of the three at the highest level, but not all three. One must ‘make a trade. This is a trilemma for identifier system security overlays.

KERI is designed to provide the highest level of authenticity. Because KERI provides com- plete authenticity, according to the trilemma, KERI may not therefore also provide both com- plete privacy and complete confidentiality. One has to choose. The best choice is complete au- thenticity and confidentiality becausc this best protects all participants from impersonation fraud. Likewise, a system that provides both complete privacy and complete confidentiality may not also provide complete authenticity.

The reason a system may not provide all three completely is that no single cryptographic oper- ation provides all three propertics. As a result, any cryptographic system must layer the opera- tions. But layering exposes weaknesses duc to the separation between the layers. Because no sin- gle layer can exhibit all three properties, one must pick one or two properties for the bottom layer and then layer on top the remaining property or properties on one or more layers.

KERI employs non-repudiable signatures, which provide the highest degree of authenticity in a practical cryptographic operation. However, verifiable, non-repudiable signatures serve as cor- relation points for the associated identifier. This makes privacy incomplete. Alternatively, a Diffie-Hellman key exchange provides encryption keys for confidentialiy but does not provide ‘non-repudiation, thus not providing complete authenticity. Without going into detail here, careful examination of any cryptographic operation exposcs a similar tradeoff. This triangle is dia- ‘grammed below:

/" authentiiy | : Smit's Triangle ) of /. ieniter Sysem Properties "\ /o opivaey | confidentiality .| Figure 1.8, PAC Trilemma 2 SEPARABLE RoOTS-OF-TRUST

KERI supports separable control over shared data. This separation of control is between the controller and the validator. The controller controls the generation and promulgation of key events for the controller's AID and the validator controls the confirmation network that verifies the key events

12640

2.1 Root-of-Trust for Controllers

‘The KERT white paper goes to some length to describe the trust basis for the controller of an identifier including specifically the cryptographic root-of-trust that AIDs derive from SCIDs (self-certifying identifiers) [42; 59]. This root-of-trust is protected by the controller's key man- agement infrastructure. In KERI parlance the authoritative cryptographic material is called the identifier prefix. This is the a cryptographically strong string of characters that is derived via one-way functions from a pseudo-random string of characters that represents the information en- tropy captured by the controller. In addition to the key and event generation and signing infra- structure, when the associated AID is public, the controller also declares an event promulgation network of witnesses. A network of witnesses provide high availability of the associated key event log (KEL) for the AID. The controller may protect its key genration, key storage, and cvent signing infrastructure by running it inside a trusted execution environment (TEE) such as SGX, TrustZone, an HSM, a TPM, or other similarly protected hardware/software/firmware se- curity system. This protects the cryptographic strength of the root-of-trust. The controller can then make the claim, that, with KERI, as long as its secrets remain secret then the rest of the controller's key management and event signing infrastructure may be as secure as the crypto- graphic strength of the one-way functions used to derive the identifier prefix. How the controller protects its secrets is application dependent

Similarly the controller may protect its witnesses by running them inside some TEE like pro- tection system. However, the witness construct allows the controller to use a threshold structure o protect the witnesses even when not using some form of a TEE. Threshold structures are de- fined below [51]. The following diagram shows the promulgation network for a controller of the identifier prefix of a KERI AID.

130

Ky Evnt PromigatonSario Indirect Replay Mode s ]| - EventVerlfer | | | e Winess. H Contlorof st ‘ o A G | Toowse || ] T : ‘ 7 4 KERLofA - KELKERLofA : KERLOfA — | < EventVerlier | | | e Witness B e ] || 4 KeRLA Designated by Cortroller | Figure 2.1. Controller’s promulgation network 2.2 Root-of-Trust for Validators

‘The KERI white paper, however, does not o into length on the trust basis for the validator. ‘The validator's essential task is to perform cryptographic signature verification o the events it receives cither dircctly from the controller o indirectly from the controller’s promulgation net- work. Should the software/firmware that runs the validator's signature verification become com- promised then the validator may not know that the key events sourced by the controller are themselves compromised. The validator needs to protect its verification software.

One approach to protection is to run signature verification inside a TEE or special purpose HSM. This is the dual operation to the controller running signafure generation inside a TEE or HSM. Signature verification is a simple process that may leverage well known software li- brarics. Because the verifier may use any host or device to run the verification software it may be difficult for an attacker to know which hosts or devices to attack. Nonctheless protecting the verifier(s) is important. The root-of-trust for the validator is the security of its verifying devices. It s not cryptographic per se, but depends on the protection of the cryptographic operations that perform the verification. From an end-to-end system's perspective the signature verification soft- ware/firmware needs to be as secure with respect of the validator as is the root-of-irust the signa- ture generation softwarc/firmware is with respect to the conroller.

In addition to or instcad of TEEs, a validator may also use the threshold structure of KERI to enable secure verification. Similar to controller, a validator may employ a confirmation net- work of watcher (verifier) nodes. Indeed, KERI was designed specifically so that a pool of

1440

watchers may be employed for the validator function. When a pool of watchers is employed then that pool may be designed to be as secure as needed using a threshold structure (with or without using TEEs). Morcover, because KERI splits the system into two sides, cach side has two dis- tinct roots-of-trust, each of a different kind. Because the validator side is the easiest to manage, the KERI WP does not spend much time on it. The security considerations of both hardware and software on both sides should be addressed. The following diagram shows both a promulgation network of witnesses and a confirmation network of watchers. Ky Evnt PromigtonSario o Event Confmation Sarico Indirect Replay Mode Wivess ! L e ]! T S R S— p—— kR kA e wiess | | VU e | Contlerof e I : ! o ok [t || Eeteer v Govaor - Bttt | | | ‘ : : { et vadaor | T N | | | 7 e keRA e ke KELKERL oA L——T} =T KERLIA Wiress | | U e |} < Eventverfer | | | - EventVerier | | H . i — . 4 KERLOTA - ‘ i KERLOIA = : s | e | EvenVerer | || e EventVerier | . S— i — { e L ke o Designated by Contollr | 1 Dasigate by Vol | Figure 2.2. Controller’s promulgation network with validator’s confirmation network To elaborate, the promulgation side (the controller) uses a root-of-trust that is a SCID and the security is rooted in the cryptographic strength of the controller’s private keys and the degree of protection of its key management infrastructure. The confirmation side (the validator) has a dif- ferent root-of-trust which is based on the degree of protection of its event signature verification software/firmware. The validator's root-of-trust is independent of the controller's. It is not a function of the key management of the controller. 2.3 Threshold Structure Security vs. TEE Security This early influential paper by Nick Szabo describes the concept of a "threshold structure”, which underlies the ideas in the security guarantees of multi-signatures, distributed consensus, and multi-factor authorization (MFA) to name a few [51]. KERI itself employs threshold struc- tures namely, multi-sig and distributed consensus, and assumes that the key management is us- ing best practices such as MFA. Threshold structures may be employed in a complementary 15740

‘manner to trusted execution environments (TEE) for security. Szabo's paper does a good job of explaining why the two types of security are complementary and that the whole may be greater than the sum of its parts.

What a threshold structure for seeurity docs for us is that we can have weaker key manage- ment or execution environment infrastructure individually but use a threshold structure to achieve greater overall security by multiplying the number of attack surfaces that an attacker must overcome to compromise our system. In other words, with threshold structures, overall se- curity may be greater than the security of any of the individual parts. For example, in MFA the combination of two factors, something you have and something you know, may be much more secure than either of the factors by themselves.

As is well known, a distributed consensus algorithm is a provable algorithm using a set of nodes where the algorithm provides a security guarantee that is greater than the security guaran- tee of any of its constituent nodes. It makes a guarantee that in spite of a compromise of F of the 3F+1 nodes, that the ledger written by the pool as a whole is still secure [6-8]. So it's improving sccurity by multiplying the number of attack surfaces that must be simultaneously overcome: ‘This may be more or less complex depending on how one defines complexity. To restate, the value of Byzantine Fault Tolerant algorithms is that one can arbitrarily increase the degree of difficulty to an attacker by multiplying the atack surfaces using a distributed network of nodes with sufficient non-common mode failure vulnerabilities [6-8].

‘This applies to KERI as well. The witnesses and watchers independently multiply the attack surfaces of the promulgation and the confirmation networks such that each witness or watcher respectively may be relatively insecure but the system as a whole may be highly secure. Numer- ous papers discuss how secure a distributed consensus pool may be [8]. But when comparing ap- ples (key management and trusted exccution environment approach to security) to oranges (dis- tributed consensus approach to security) its hard to say that the security of a distributed consensus algorithm is necessarily less secure than the key management infra-structure root-of- trust of any of its nodes. Although as a general rule, in an apples to apples comparison, more complex is less secure.

With KERI's design, we can make the following claim:

Through threshold s

tructures, KERI enables the promulgator (controller) to make its sys- tem no less secure than the security of s secrets and enables the confirmer (validator) fo make ifs security at least as secure as the security of the promulgator

Obviously, in resource-constrained applications, there are limits to the application of distrib- uted consensus for security. Nonetheless, the point of KERI is to capture the goodness of distrib- uted consensus without the cost, latency, and throughput limitations of conventional blockchain distributed consensus algorithms used for cryptocurrencies. The most important feature of a cryptocurrency is that it must be double-spend proof. Because KERI's key event operations are idempotent, they do not need to be double-spend proof, so we can greatly simplify the distrib- uted consensus algorithm in KERI. This makes KERI relatively more attractive for many appli- cations, including IoT applications, by comparison.

2.4 Separated Control

As a result of the relaxation of double-spend proofing, KERI is able to break the distributed consensus algorithm into two halves and simplify it in the process. As mentioned above, the two halves are the promulgation half and the confirmation half.

‘The promulgation half is under the control of the controller of the private keys. The controller is solely responsible for the security guarantees of its signed key events as well as the promulga-

1640

tion of those events. The controller is not dependent on any other entity for its security. The con- troller is fiee to make its promulgation system (witness set) arbitrarily as secure as it desires. Al- though there is no point in making it more secure than its root-of-trust in its key management. The promulgation infrastructure verifies signatures on events already signed by the controller and then generates signafures on those cvents as receipts. The receipted events are then broad- cast. No attacker can forge any signed event or receipt without compromising the signing infra- structure of the associated component. When using multi-sig, this means compromising K of the N signatories. Moreover, no attacker can compromise the receipting infrastructure without com- promising more than F of the witnesses. The worst an attacker can do without compromising the Teceipting infrastructure of F witnesses, is to DDOS or delete the broadcast. This is a well-de- limited and well-understood type of attack with well-understood mitigation.

‘The confirmation half is under the control of the validator. The validator is solely responsible for the security guarantees of its confirmation network. This network is verifying signatures on events promulgated by the controller and/or its witnesses. The validator is free to design and im- plement its confirmation network of watchers as secure as it needs, and it is not dependent on any external entity for that. Because verification happens at the edge, an attacker must attack and overcome a multitude of edge verifiers (watchers) with litle net gain per individual exploit. This ‘multiplies the attack surfaces that the attacker must overcome. Mitigation mechanisms for at- tacks on verifier firmware are also well known. Because verification is largely a fixed operation in software, the verification software may be deployed by the validator in a manner that may not be predictable by any attacker. Once deployed, the attacker must individually find, target, and exploit each edge verifier (watcher). By multiplying the attack surfaces with multiple watchers, cach validator may arbitrarily increase the difficulty of an attack without having to use TEEs for its watchers.

KERI's design enables the validator to make a trade-off. A given watcher under the acgis of the validator may be secured by using a verifiable attestable hardware scourity module (HSM) (a type of TEE) to perform the end verification operations on the KERI events. This ap

proach may provide assurance to the validator that the cryptographic signatures are verified correctly and that the verification software/firmware on the watcher has not been tampered with. Or the val- idator may choose to use a threshold structure to secure the signature verifications of its watch- ers through a distributed consensus pool of confirming nodes that each perform the signature verification and then compare resuls. Or the validator may choose to use a combination of both, where each watcher uses an HSM/TEE to protect its signafure verification, so that fewer watch- ers are needed because each watcher is correspondingly more secure.

Likewise, the promulgation (controller) can make similar trade-offs for its witnesses. More witnesses without HSM/TEE for signature verification and receipt generation or fewer with HSM/TEE. But most importantly, the separation of control via the splitting up of promulgation and confirmation enables each to design and implement according to their desired guarantees of security.

In summary, by splitting the attack surfaces into two independent sides. The controller (pro- ‘mulgation side) and the validator (confirmation side) each may independently set their security Levels by multiplying their own attack surfaces separately.

Nonetheless, in the special case when the signature verification is performed on a single device (a single watcher), then that watcher/verifier may very well benefit from using a TEE in order to have the same degree of security as the controller when the controller is using a TEE. But if the validator is using a pool of watchers, then the watchers as a pool may be as secure as a con- troller's TEE without any of the watchers using a TEE.

17140

KERI by design puts verification at the edge. The weakest case is an application where there is only one verifier/watcher. One example of this is a mobile device under the physical control of the validator. But even in this case, verification at the edge means the attacker is fighting an asymmetric war where the asymmetry is in favor of the validator. In spite of a lot of effort, an at- tacker may only compromise one device at a time. This assumes non-common mode exploits, such as exploiting the crypto library on GitHub that sources the verifier's software.

In other use cases where the device is not under the physical control of the validator, such as a remote payment card reader, or some other application where the sole verifier is a known high- value target, then the verifying device may benefit greatly from using a TEE.

As a use casc, the end verifiability of KERI opens up an opportunity for HSMs for signature verification. Typically, mobile phone devices could be used as a type of general-purpose HSM for KERI event signature verification, but a dedicated device that only does verification may provide a better security for cost trade-off. Currently, there are many low-cost hardware devices (HSMs) such as a Ledger Nano, UbiKey, Trezor, etc. that provide signature generation. But not so for signature verification. With KERI, there may be applications where verifiable atiestable HSMs may be used for event signature verification. The Trusted Platform Module (TPM) group recently released a standard for low-cost HSM chips that would be applicable to HSM for signa- ture verification for end verifiers [52]. This may be used in combination with the IETF standard for remote attestation [39]. Together, a validator could implement an HSM for end verification, where it could query the HSM and be assured via a signed attestation from the HSM that its signature verification firmware has not been tampered with 2.5 Assumptions about Verifiers

KERI makes some assumptions about a verifier.

• The software/firmware that is doing the signature verification is under the control of the validator.

• The verification hardware/software is not dependent on any external infrastructure to do the verification at the time of verification, other than to receive a copy of the events.

• The softwarc/hardware that is verifying signatures has not been compromised. Single, when only one watcher, or multiple, above a threshold, when using multiple watchers.

If the verification softwar

e/firmware has been compromised, then no cryptographic operations run by the verifier may be trusted by the validator. But given the three assumptions above, the worst that an external attacker can do when attacking a verifier is a DDOS or delete attack to prevent the verifier from sceing the events. An attacker may not forge cvents to deceive a verifier.

Duplicity detection, which protects, not against an external attacker, but against a malicious controller, does require access to watchers that are also recording duplicitous events. So this may be viewed as a dependence on external infrastructure, but its dependence is generic. Further- more, the goal is to make duplicity detection ambient such that a malicious controller may be easily detected.

2.6 Zero Trust Computing

KERIs separable control design allows the controller and each validator to independently de- sign their infrastructure. Because KERI is not dependent on a shared public ledger, each may im- plement its KERI components using off-the-shelf cloud computing infrasiructure. Best practices for_implementation should follow zero-trust computing principles. These principles are de- scribed at more length elsewhere, but may be summarized as follows [9]:

18040

1. Network Hostility. The network is always hostile, internally & externally; Locality is not trustworthy. Solutions must provide means to mitigate network layer security vulnerabilities (man-in-the-middle, DNS hijacking, BGP atiacks).

2. E2E Security. Inter-host communication must be end-to-cnd signed/encrypted and data must be stored signed/encrypted. Data is signed/encrypted in motion and at rest.

3. E2E Provenance. Data flow transformations must be end-to-end provenanced using verifiable data items (ver- ifiable data chains or VCs). Every change shall be provenanced.

4. Verify every time for everything. Every network interaction or data flow must be authenticated and authorized using best prac- tice cryptography.

5. Authorization is hehavioral. Policies for authentication and authorization must be dynamically modified based on behay- ior (reputation).

6. No single point of trust. Policies for authentication and authorization must be governed by an end-verified, diffuse- trust, distributed consensus. Policy is protected by diffuse trust.

7. Hosts locked down. Hosts or host components executing any of the logic mentioned above must be locked down. Any changes to the host execution logic or behavior must be fully security tested and vali- dated over the respective possible combinations of hardware and software platform. This in- volves scouring key management and cryptographic operations on the devices. This includes key generation and storage, as well as signature generation and signatur verification. These ‘may benefit from the use of some form of trusted exccution environment (TEE) cither gener- ally or specially as in a trusted platform module (TPM) or a hardware security module (HSM). In addition to key management and cryptographic operations, special security measures must be implemented regarding secure execution of the application logic (¢.g. code inection, inscoure object references, cross-site/service request forgery, cross-service script- ing, etc.).

3 SECURITY SUMMARY

One useful way to describe KERI s as a decentralized key management infrastructure (DKMI) based on key change events, which supports attestable key events and consensus-based verifica- tion of key events.

With KERI, security becomes largely a function of a given participant's infrastructure, rather than relying on another entity's “trusted” internet infrastructure. Each controller of an identifier gets (o pick their own infrastructure, and each validator gets to pick the

ir own infrastructure. ‘This i a big advantage as it does away with the whole house of cards that are the “trusted enti- ties” in DNS/CA.

It much easier 1o secure one's own keys well than 1o secure everyone else’s internet computing infrastructure well. 19640

4 KeY ROTATION AND STATEMENT REVOCATION

‘The term revocation has two completely different meanings in the identity space. In key man- agement, one may speak of revoking keys. With statement issuance, authorization issuance, or credential issuance, one may speak of revoking an authorization statement, a token, or a credential.

‘This becomes confusing when the act of revoking keys also implicitly revokes the authoriza- tion of statements signed with those keys. Any statement may be cffectively authorized by virtue of the attached signature(s) made with a set of authoritative keys. The statement itself may be authorizing some other function in the system. So, the verification of the signature on an autho- rizing statement is essential to determining the authoritativeness of the associated authorized function. To clarify when an authorization is conveyed via a signed statement, the signature acts to authorize the statement. The meaning (semantics) of the statement may merely be data that thereby becomes authoritative. Or the meaning (semantics) of the statement may be to convey an authorization for some other function. In either case revoking the authorization of the statement revokes the authoritativeness of the semantics of the statement

KERI terminology usually avoids that confusion between rotation and revocation because a key rotation operation is the cquivalent of a key revocation operation followed by a key replace- ment operation. So one operation, rotate, is implemented instead of two operations (revoke and replace). A bare key revocation is indicated by replacement with a mull key. So only one opera- tion is needed, that is, rotate, where a special case of rotation is to rotate to a null key.

Given the KERI definition of rotate as applied to keys, revocation is usually unambiguously applied to mean revocation of the authorization of a signed statement. Otherwise, when not clear from the context, one may simply use the modifier key revocation vs. statement revocation.

To clarify, the authority of a signed statement is imbued by the attached signature(s) created with a set of authoritative keys. This begs the question: is a signed statement authoritative/autho- rized after the keys used to sign it have been rotated? If not, then the statement is effectively re- voked as no longer being an authoritative/authorized statement. If the statement is still authorita- tive/authorized after the keys used to sign it have been rotated, then the statement is

not effectively revoked by the rotation itsclf but requires a scparate signed revocation statement that rescinds/revokes its authoritative/authorized status. This revocation statement may be signed by a different sct of authoritative keys than the keys used to sign the statement being revoked.

4.1 Authorization Models

Given that key rotation and statement authorization are two distinct operations, a given identi- fier system needs to define the model of how 1o verify the authoritative state of a given autho- tized statement when the keys used to sign that statement have been rotated. There are several ‘models for determining the status of an authorized statement afier a rotation of the keys used to sign that statement. Each authorization model has an associated verification rule.

• Rule I: Persistent Authorization Model Any signed statement that is signed with the set of authoritative keys at the time of its signing is valid until revoked (rescinded) with another signed statement that is signed with the set of authoritative keys at the time of the signing of the revocation statement.

‘This means that merely rotating keys docs not revoke or rescind the validity of prior signed statements. Otherwise, every time one rotates keys, onc would have to reaffirm (rcissuc) every prior signed statement that used the now obsolete keys. This is the model most compatible with the issuer-holder-verifier model of VCs. A VC is a type of signed statement. In this case, the ver-

2040

ifier does not need to communicate with the issuer, but needs only to communicate with the holder and a verifiable data registry (VDR) to determine the revocation state of the VC. This tri- partite model enables more privacy for the holder because the issuer is not able to track cach presentation of a VC by a holder to a verifier. KERI may be used to support this model because the key event log (KEL) may be used as a VDR to anchor both issuance and revocation statements. * Rule 2: Ephemeral Authorization Model All statements signed with the set of authoritative keys at the time of their signing are automatically revoked when that set of authoritative keys are rotated.

‘This model of mandatory revocation of all signed statements is most commonly used in token- based security systems where all tokens issued under a given set of keys are automatically re- voked when those keys are rotated. A given signed statement is authoritative only if it verifies against the current set of keys. This simplifies the system because no VDR is required. However, this means that whenever the keys are rotated, any continuing authorizations require reissuance of new signed statements using the new keys. This may be problematic when using the tripartite VC model of issuer-holder-verifier. The issuer must push out new VCs to all the holders cach time it rotates keys.

‘Typically, the ephemeral authorization model works best in a bipartite VC model where the verifier requests verification from the issuer directly. In this case, the holder does not actually hold a VC but merely a reference to a VC held on its behalf by the issuer. Aliernatively, the identifiers in the VC are dynamic references that resolve to service endpoints. In cither case the holder presents the references to the verificr who contaets the issucr dircetly to determine autho- rization status. Thercfore, when rotating keys, the issuer docs not have to re-issue a VC but merely tracks the authorized state of cach VC internally. This bipartite approach is less privacy- preserving than the tripartite approach because the issuer may now track all presentation re- quests by the holder. KERI also supports this model in the sense that an issuer may use the KEL for only tracking key rotations and not signed statements.

• Rule 3: Some Authorizations are Persistent, and Some are Ephemeral (Hybrid) Model

Any presentation of a signed statement with persistent authorization must include a refer- ence to its location in the VD

R (log) fo determine the authoritative keys at the time (loca- tion) in the VDR when the statement was signed. The signed statement is authorized until revoked (rescinded) with another signed statement that is signed with the set of authori- tative keys at the time of the signing of the revocation statement. If the VDR location ref- erence is absent in the presentation, then the authorization is assumed to be ephemeral, and the verifier uses the current authoritative keys to verify the authorization status of the signed statement.

‘This is a hybrid of Rule 1 and Rule 2. In this model, only logged signed statements use rule 1), and all other signed statements use rule 2). Because Rule 3) requires a log for the persistently au- thorized signed statements, it may still be privacy preserving relative to a Rule 2 implementation without a log. In this case, the verifier needs only to reference the log (VDR) to get the authori- tative keys instead of making a presentation dircctly to the verifier. KERI supports Rule 3 be- cause it provides both the key state and may also provide any anchored signed statement state.

To elaborate, for Rule 1 or 3 to be practically implemented, one must maintain a verifiable data registry (VDR), such as cither a log of signed statements or a cryptographic commitment (di- gest) to those statements (via a Merkle tree or hash-chained data structure). With a VDR, one can verify that a persistently authorized statement was signed with the authoritative st of keys

2140

at the time of signing, Verification is always with respect to the set of signing keys used to create the signature at the time the statement was signed. This means the verifier must have a way of determining the history or lineage of control authority via a log or ledger of the key rotation his- tory to know that a persistently authorized statement was signed with the authoritative set of keys at the time of signing. This means that the log or ledger must not only log the lincage of keys (key rotation history), but also the statements (or at least a digest of the statements) signed by those keys. Otherwise, a compromise of the current signing keys (which rofation protects from) would allow an exploit to create forged but verifiable supposedly authorized siatements afier the keys have been rotated.

‘The log itself allows the controller to anchor cryptographic digests of any other data to the log at a specific place in the log. One may use the KERI KEL as a hash chain clock. The log pro- vides a point in the hash chain time for any anchored data item. That anchor is a cryptographic commitment to that data. The ordering of all anchored statements may then be verifiable like a fedger, but without needing a "ledger", as the KEL is effectively a "micro ledger”. This means that, with KERI, one may use the KEL s a clock for determining both the issuance and later re- vocation time for any anchored statements associated with VCs.

If the use of a VDR (log or ledger) is not practical, then only Rule 2 is feasible. This is one reason why token-based authorization systems such as OIDC and JWT only use Rule 2. This ‘means that when the keys used to sign the token have been rotated, the token’s authorization is automatically revoked; effectively, the token is always verified by the current set of signing keys, so it will fail verification after key rotation.

When leveraging authorization tooling to implement VCs, one should carcfully consider how much is gained or lost by using tools built for differcnt authorization models.

• Rule 4: Rotate the Identifier, not the Keys Model A signed statement's authorization is persistent until the ephemeral identifier associated fwith the authoritative keys has been rotated. Rotation of the identifier effectively rotates the authoritative keys.

‘This model addresses the case where the keys controlling an identifier are not rotatable. This is more common than one might expeet (for example, an Ethereum or Bitcoin address). In this

case, any signed statement may mof be revoked by merely rotating keys because the keys cannot be rotated. Instead, one might be tempted to use a revocation registry to determine if a given signed statement has been revoked by a later revocation statement. This approach is problematic, from a security perspective, because signing keys may eventually become compromised due to exposure, at which point an exploiter may then corrupt the revocation registry, rendering the reg- istry unrecoverable.

In KERI, an AID or SCID prefix may be declared as non-transferable at inception (which means one may not rotate the AID's or SCID's controlling keys). This means no key event log (KEL) is ever needed. Furthermore, in KERI, an identificr that is declared as transforable at in- ception (i.¢., supports key rotation) may later be retired by rotating to a null key, afier which no Trther events are accepted into its log.

By definition, a new SCID has a new, unique set of controlling keys. Therefore, a practical so- Iution for signed statement revocation of statements issucd by SCIDs with non-rotatable keys is 10 rotate the SCID itself 1o a new SCID. In this case, one may then use Rule 2 to verify any signed statements made with the old identifiers (SCID) keys vis-a-vis the new identifiers (SCID) keys

2240

‘The complication to this solution is keeping track of the fact that the identifier has indeed been rotated. Therefore, one still needs a VDR (log or ledger) to track which identifier is authoritative for a given function that relies on signed statements for authorization. So, Rule 4 is yet another hybrid. The hybrid is that a VDR (log or ledger) used o track key rotation and signed statements for one SCID with rotatable keys may also be used to track the state of other ephemeral identi- fiers with non-rotatable keys, where those ephemeral identifiers are authorized by the one rotat- able identifier. The advantage of Rule 4 is that one VDR (log, ledger) that is in the trust domain of one AID (SCID) may be used to track ephemeral identifiers (AIDs), not simply ephemeral keys. The advantage of ephemeral identifiers is that they are discoverable, whereas bare ephemeral keys are not.

4.1.1 Ephemeral Identifier Rotation using Rule 4

KERI employs the model of Rule 4 for witnesses. Witnesses use ephemeral (non-transferable) identifiers, where non-transferable means non-rotatable controlling keys. This greatly simplifies the establishment of control authority for the witnesses. As mentioned above, an ephemeral (non-transferable) identifier needs no event log to establish its control authority. Therefore, veri- fiers do not need to retrieve key event logs (o establish the control authority of a given witness in order to verify witness receipts on events. Should a witness become compromised, then the con- troller of the identifier to which the witness is acting as a witness (ot the witness's own identifi- er) rotates out the compromised witness in a key rotation event and rotates in a new witness with anew identifier.

‘This same strategy may be applied to any management domain where one transferable identifi- er uses its KEL to track the verifiable authorizing declarations of other ephemeral identifiers. ‘These "authorized” identifiers may be ephemeral because the authorizing declaration statements anchored in their KEL allow the non-ephemeral identifier to track the rotations of the authorized ephemeral identifiers themselves instead of tracking the rotation of the keys for the authorized ephemeral identifiers.

Another example is an loT application where a marshal maintains a template of the network configuration with a mapping between IoT device identifiers and network addresses. The Mar- shal may benefit from a transferable identifier, but the ToT devices nee

d only use ephemeral (non-transferable) identifiers because, should they ever be compromised, the Marshal may re- place their entry in the template with a new identifier (and associated keys).

5 MuLTi-VALENT KEY MANAGEMENT INFRASTRUCTURE FOR AN ENTITY

‘The root-of-trust for an AID-based trust domain in KERI is the self-certifying identifier prefix for that AID. The security of that root-of-trust is essentially the security of the private key(s) that control that identifier prefix. More generally, this is the security of the key management of the associated private keys. Recall that in KERI, the keys being managed for the control authori- ty are cryptographic signing keys. The essential management functions we call the three R's of key management. These are key reproduction (key pair generation and storage), key recovery, and key rotation. Key rotation depends on the reproduction function for new key generation and storage, and key recovery provides redundancy in the key storage or recreation. In addition to these management functions, other important relevant operations include event generation and event signing using those private keys. A useful way of viewing key management is that there are two infrastructures. One is the key-pair generation and storage infrastructure, and the other is the key event generation and signing infrastructure. This is shown in the figure below.

23040

AD ey Managenent Infasictre Keypair Generaton & Sirage Infasirctre ] £ LI Koy Evant Ganerston & Signing Infasitctre Figure 5.1, Univalent key management infrastructure

‘The fundamental security principle is that secrets (random seeds or private keys) must remain secret, There are various mechanisms and best practices to protect both the key generation and storage, as well as the event signing infrastructure. Key pairs (public, private) are created in the key-pair generation and storage infrastructure and then may be moved to the key event genera- tion and signing infrastructure in order to sign events. The movement of keys, especially private keys, poses a sccurity risk. The signing operation potentially exposes the private key 10 a side- channel attack, exposed by either the movement of private keys from the generation infrastruc- ture to the signing infrastructure or in the signing computing infrastructure itself. Consequently, a given protection mechanism may co-locate both infrastructures. In this case, we may refer to this combined infrastructure as a univalent key management infrastructure. A more secure, albeit less convenient or performant, univalent key management infrastructure may use special com- puting devices or components 1o store private keys and/or create signatures. These may include one or more of a sccure enclave, a hardware sceurity module (HSM), a trusted platform module (TPM) or some other type of trusted exceution environment (TEE). The degree of protection typically necessitates a trade-off among seeurity, cost, and performance. Typically, key gencra- tion happens relatively infrequently compared to event signing. But highly sceure key generation ‘may not support highly performant signing. This creates an architecture trade-off problem.

‘The way KERI addresses this security-cost-performance architecture trade-off s via the dele- gation of identifier prefixes. Delegation includes a delegator and a delegate. For this reason, we call this a cooperative delegation. This is a somewhat novel form of delegation. A major advan- tage of cooperative delegation is that the delegator’s key management protects the delegate’s via recovery by the delegator. With cooperative delegation, any exploiter that compromises only the delegate’s authoritative keys may not capture control authority of the delegate. Any exploit of the delegate only is recoverable via cooperation with the delegator. A successful exploiter must also compromise the delegator’

s authoritative keys. A nested set of layered delegations in a dele- gation tree wraps each layer with compromise recovery protection of the next higher layer. This ‘maintains the security of the root layer for compromise recovery all the way out to the leaves, despite the leaves using less secure key management methods.

To elaborate, in a cooperative delegation, the key generation and storage functions of the dele- gator and delegate, in terms of the controlling private keys, may be completely isolated from cach other. This means that cach may use its own independent key management infrastructure with no movement of private keys befween the two infrastructures. We refer to this as a bivalent key management infrastructure. This is shown in the following diagram

2040

DolgalorAD Key Nanagerent asncure Delegaio AD Keypal Key Nanagerent Gensrston & Sorage nasncure nasncurs B Keypal 2 g Gensraton & Sorage 1 3|f nasncure § -8 o P F Key Event. H 5 Garersion & Sgring § -|f ntasmcurs . : ey Evnt Gaorsion & Sgring nascure Odogan v Figure 5.2. Bivalent delegated key management infrastructure ‘The only data that needs to be transferred between the two infrastructures (delegator and dele- gate) originates from the associated key cvents in the delegations. The movement of signed event data does not pose a sccurity risk in any meaningful sense. A signed event is a verifiable statement that contains no secrets, and given sufficient cryptographic strength of the underlying one-way functions, may not be forged by any practical means. The important feature of a dele- gated identifier prefix is that recovery from a compromise of the private keys of the delegate ‘may be performed via a rotation event authorized by the delegator. This allows a beneficial sepa- ration of concerns where the delegator's key management infrastructure may be much more se- cure but less performant, while the delegate's key management infrastructure may be less secure but much more performant. The delegate’s infrastructure is still protected by recovery via the more secure delegator's infrastructure. In a bivalent sctup, the delegator needs only to authorize delegation events, which happen relatively infrequently, so that high performance is not necded. Conversely, the delegate may need to sign at scale other statements for various application inter- actions. The following diagram shows the key event streams for a delegation 2540