Comparing KERI to Certificate Transparency

[stevetodd]

Wrote this while thinking about @csuwildcat comments from yesterday:

Comparing KERI to Certificate Transparency

I think one of the best ways to understand KERI is through comparing it to Certificate Transparency (CT)). Many of the same mechanisms used in CT are used in KERI to provide verifiability and detection of what CT calls suspicious behavior. In KERI, the focus is usually on duplicitous behavior—a controller that tries to spread conflicting key histories.

Consider the domain name system and some of its components and actors--the domain name, the owner, the domain registrar, key pairs, certificate authorities, certificates, and user agents (e.g., browsers). Add to that Certificate Transparency. Here's how they compare in KERI:

• Domain Name ≈ KERI prefix/identifier/name; cryptographically derived from the public key and a digest of the next key (and other configuration data); universally unique
• Domain Name Owner, Registrar, Certificate Authority, Private Keys Holder ≈ KERI Controller
• Certificate ≈ KERI event log, self-signed by the controller
• Certificate Transparency Loggers ≈ Witnesses
• Certificate Transparency Monitors ≈ Watchers
• User Agents/Web Browsers ≈ Verifiers

There are important distinctions that I want to highlight. In KERI, the prefix/identifier/name is cryptographically derived from the configuration of the identifier. This configuration includes the initial public key, a digest of the next key, the algorithms used, the witness identifiers (if the identifier is to be public, discussed later), and other pieces less relevant to this discussion. This configuration is signed using the initial public key. This configuration constitutes the inception log entry for the identifier. The identifier is the digest of the inception log entry (in the case of self-addressing prefixes). The controller can assert control of that identifier through the use of the private key. Unlike the certificate authority system that uses CAs to bind the domain name and the key pair, the controller binds their identifier to the key through the above cryptographically-based derivation process.

Later, if the controller included a digest of the next key in their inception, they can rotate the keys. The controller accomplishes this by creating a new log entry containing:

• A digest of the previous log entry
• The public key of the next key that was provided digested in the previous log entry
• Any changes to the witness set

The controller then signs the entry and sends it to the witnesses to disseminate. (aside to daniel: outside of witnesses, I think sidetree uses a similar mechanism)

For publicly resolvable and verifiable identifiers, KERI uses witnesses to publicize the identifier's log. These are analogous to the loggers in Certificate Transparency (CT). The controller creates the log entry, signs it, and sends it to the witnesses. Each witness signs a receipt and sends it to the other witnesses in the identifier's witness set. When a witness has received the required number of receipts, it appends the log entry to the witness's copy of the identifier's log that is shared with watchers and validators. Witnesses will never share another version of that log entry (identified by the sequence number in the log entry). When the witness shares the log entry, they also share all the receipts they have of that entry.

CT employs monitors to ensure that loggers never change their logs and to watch for suspicious activity. Likewise, KERI watchers retrieve the logs from witnesses to look for similar suspicious/duplicitous activity from witnesses and controllers. Watchers communicate among themselves about the logs they receive to prevent eclipse attacks. Any conflicting logs propagated by controllers or witnesses is therefore quickly detectable. What has been seen by witnesses and watchers can't be unseen.

User agents can verify identifiers by either contacting specialized verifiers or contacting watchers and examining the logs. The white paper discusses composing verifiers of a system of judges and jurors. Essentially, the watchers provide a verifier with all they need to obtain and verify an identifiers log to determine the current state and detect any duplicity.

At this point, the KERI identifier is similar in value to a certificate signed by Let's Encrypt—the controller can prove rightful control of the identifier by exercising the private key. If the controller wants to assert its identity as a person or organization, they can do so with verifiable credentials linked to the identifier.

Note: to highlight the relevant mechanisms, I have omitted some of the features of KERI, such as multi-sig, interaction events, and delegation.

[stevetodd]

Incidentally, I think that KERI needs a page like CT's How it Works somewhere. It's pretty well done.

[fimbault]

Thanks. "Witnesses will never share another version of that log entry" -> phrased like that, it assumes they're not adversarial (or that you own them). Ok I understand the watchers would detect unlawful changes, but still that makes the trust model blurry...

A big difference is that CT really need a transparent log of certificates, precisely to remedy the issue that there is no keri like authoritative controller in the loop. They indeed use an append only structure to avoid the mismatch betwen the CAs and the CT, and any authenticated data structure managed by a central authority would suffice here.

The other argument put forward in KERI is that it is the first seen that wins. So why do you need a witness layer, any consensus reached by watchers would be enough.

Could you clarify why you need witnesses? - this question refers also to "The controller then signs the entry and sends it to the witnesses to disseminate. (aside to daniel: outside of witnesses, I think sidetree uses a similar mechanism)"

I think that's something important to explain (for you) and understand (for me).

[SmithSamuelM]

@fabien Witnesses have nothing to do with duplicity detection at least to protect validators. Its probably the most confusing aspect of KERI and I am trying to figure out the best way to represent KERI so that role of witnesses doesn't get confused with watchers.

Witnesses primarily provide a secure discoverable highly available store and forward service for controllers. But witnesses do not provide duplicity detection. Secondarily witnesses help a validator determine how to resolve duplicity. Duplicity detection may work without witnesses, only the controller and watchers are needed. We could get rid of witnesses and duplicity detection still works. Anyone can get a key event log from a watcher. Witnesses just make it easier for the controller to publish its KEL and make that publication securely discoverable and highly available to the watchers. But the watchers also share KELs so they don't need witnesses per se, but just a publication from the controller. But controllers don't want to publish directly to watchers. They want a discoverable publication service acting on their behalf. Thus witnesses.

An honest controller wants a validator to be able to reconcile some types of duplicity so that the validator will resume trusting the controller. A validator uses its watcher network to collect evidence to reconcile that duplicity. Witnesses may make it easier to collect and resolve evidence.

There are two forms of reconcilable duplicity. 1) DEAD key compromise 1) LIVE but recoverable KEY compromise.

Witnesses allow a controller to make a guarantee about its KEL publication service and to allow the controller to provide a reliable service despite compromise of a minority of the witnesses. The witnesses are not the controller. They don't have the controller's keys, witnesses have their own keys. If a witness is compromised then it may choose to delete logs. So a pool of witnesses makes it hard for an attacker to block the controller from publishing its events and logs. This is a good thing for controllers but it has nothing to do with duplicity detection. Witnesses and witness receipts on published events gives evidence to validators to help decide which type of duplicity needs to be resolved. A set of watchers that a validator trusts helps that validator resolve or reconcile DEAD key compromise. Witnesses help make it clear if it DEAD or LIVE key compromise so a validator knows how to reconcile or resolve. Thus witnesses allow the controller to better protect itself.

To clarify: The validators don't need witnesses they need watchers to protect themselves. Witnesses protect the controller from external attack. Watchers protect validators from duplicity.

Duplicity has two sources, Either controller key compromise or a malicious controller. Both exhibit as controller duplicity to a validator. So there are two steps in KERI security for validators (not controllers). (public indirect mode)

1) Duplicity Detection via watchers. First sign of duplicity validator stops trusting.
2) Duplicity reconciliation (resolution) examine the duplicity and see if it can be reconciled.

To reconcile first determine what type of key compromise is it DEAD or LiIVE.

A) If it's DEAD then use watcher consensus of first seen wins. If there is sufficient consensus of which log is first seen then the DEAD duplicity is reconciled if not then its not and that controller is un-trustable. By definition a DEAD compromise of any keys may only happen after a that event has been published and its keys used to sign the event have been exposed. Thus the event only need enough time to be first seen by the watcher network for it to be immune to DEAD attack. A good watcher network should only need milliseconds or are at worst seconds for full dissemination of that first seen event after which that watcher network is immune from unreconcilable duplicity due to DEAD key compromise.

B) If it's LIVE then it may be reconcilable via a verifiable key compromise recovery operation in the event log (ie a key rotation). When there are witnesses the first seen rule becomes first seen fully witnessed event. This enables better reconciliation in the event of duplicity with recovery. As non-fully witnessed events are not seen by validators. Requiring the events be witnessed allows a controller to better detect when it is under attack via a compromise of its signing keys. An attacker can't publish events signed with a compromised signing key directly to watchers without first getting them witnessed (ie signed by the witnesses). The act of publishing the compromised events to witnesses under the control of the controller allows the controller to detect an exploit in progress and to know where in the event log to perform a recovery rotation. It slows down the attack and limits the number of compromised events before a controller detects it. Witnesses provide attack detection to the controller about its own events. Witnesses do not protect the validators directly but enable the validators to better reconcile duplicity after a controller has issued a recovery rotation event.

Reconciled duplicity allows the validator to again resume trusting the controller in spite of duplicity should that duplicity be reconciled to the validator's satisfaction. Unreconciled duplicity means the validator remains in a state of don't trust.

But witnesses and watcher are only needed for indirect or public mode. In private direct mode the controller publishes its events directly to the validator and the validator is its own watcher. Its self-sufficient and does its duplicity detection and reconciliation solely based on its own copy of the KEL it received directly from the controller. The validator's first seen version always wins for DEAD attacks.

In public indirect mode, controllers don't want to be online continuously but they need a discoverable service to publish their events to all the validators and validator trusted watchers. This service is a highly available pool of witnesses. The witnesses are discoverable because they are designated in the key event log. This is their main purpose. To be a discoverable, highly available key event publication service for the controller. Now any validator or watcher anywhere can know where to go to get a copy of the key event log given key state because key state includes the designated witnesses. This protects discovery from exploit. This secure discovery is protecting the controller.

[fimbault]

@SmithSamuelM Thanks a lot for the answer.

Let me rephrase with my own words : witnesses provide a publishing service that's helpful against attacks. Case B (live attack) is well explained. Indeed since events need to go through witnesses first, and since their number is limited, it's easier to spot than if the KEL was gossiped to all.

So now let me try an analogy, the Roman history is always a good source of potential attacks ;-)

So in that play: the controller = the emperor / the witnesses = his personal guard / the watchers = the senate.

As we know, the senate is always comploting. The emperor likes to have an eye on them and make sure they behave (an ancient version of PBFT). Most often, senators do what they are compelled to do by the emperor, but their level of distrust is high. If they can they'll take the opportunity to overthrow him. And the best way to do that is to convince the personal guard or closest allies that the emperor should be killed. Versions of that killed nearly every Roman emperor (Caesar, Calligulla, etc.).

Back to KERI, I understand the security of the witness part is linked to the controller choosing them. But then the quickest attack path is to make sure you can collude the witnesses. As any good plot, this can only happen once, because then the controller notices the treason and acts immediately. But too late, because his deniability in the matter is very low. We can notice that Forensic support is a hot topic these days ;-)

I guess KERI's answer is related to KAACE, but I'd be interested to know how this relates to state of the art algorithms. And more generally speaking about the hypotheses and guarantees provided by the witness - watcher network (ex respective size of witness set vs watcher set?). Also what about alternatives such as Casanova, specially designed around no total ordering? Its attestation to consensus model could work quite well.

[SmithSamuelM]

Witnesses protect live attacks on signing keys. Any compromise on signing keys is recoverable by a rotation with the pre-rotated keys. So a complete mutiny of the witnesses is recoverable with a rotation. Just replace the witnesses.

[SmithSamuelM]

You can layer extra authentication requirements on the witnesses for accepting new events for the KEL they are designated witnesses for. Thus making mere compromise of the signing keys insufficient to get the witnesses to witness. But ultimately compromise is recoverable via a rotation to new keys and new witnesses. If the pre-rotated keys are compromised then KERI itself has no recovery or protection. Unless they are for delegated identifiers. Eventually any system built on PKI fails if enough keys are compromised. The goal is to make the likelihood of such a sufficient compromise sufficiently difficult given your risk profile. If you have enough non-common mode failure paths for key compromise then attack becomes exponentially difficult.

[SmithSamuelM]

The goal is to start with secure mechanisms and then multiply difficulty of those secure mechanisms with threshold structures. So multi-factor auth, multi-sig, distributed consensus are all threshold structures. An attacker has to simultaneously compromise a majority of the elements in each structure in order to successfully compromise. KERI provides multiple threshold structures so one can tune the degree of difficulty. So to protect pre-rotated keys three mechanisms are used. The first is that pre-rotated keys are not exposed. So attacks are limited to attacks on key storage. The second is multi-sig so if the key storage is in separate locations then the attack must attack multiple locations. The third is delegation which layers on some other identifiers pre-rotated protection mechanisms.

[fimbault]

Ok but "just replace the witnesses" is easy only if you control them somehow (feasible in a corporate setting) or have a public estimate of the trust you can put into them. Otherwise I can hope for the best, choose randomly (supposing they're discoverable) and rerotate if needed, but what if I want more assurances? The question is how do you pick them? how many ? what's the economic model for witnesses?

[SmithSamuelM]

@fimbault Those are all good questions. They will be answered in due time. The innovation of KERI is that each controller gets to pick. Unlike ledgers KERI doesn't pick for them. But if one is happy with a ledger for a witness and likes the economic model of the ledger then they may choose it. I expect that there will be bespoke witness services that will be stood up to address each market segment. Because the witnesses do not need to totally order, their distributed consensus (KAACE) is much simpler and any cloud cluster can be used. This makes the economic model much less expensive than a total ordering ledger. I anticipate docker containers that anyone can spin up on their cloud host of choice. But this is not for KERI do decide but merely for KERI to enable. The hourglass theorem of thin layers for a stack is a maximally adoptive strategy because you get interoperability via the stack, but open choice for market forces to provide solutions at each layer. The one thick layer approach of ledger economics is a one size fits all model which means its a most fits poorly model. The purpose of KERI is not to answer all those questions but to enable answers to those questions and let the market decide. The adoption of decentralized identity has been stymied by ledger wars which IMHO stems from the fact that no ledger fits all segments well. So unless you have one ledger to rule them all (not gonna happen), you end of with a morass of non-interoperable non-portable identifiers. To use a Roman analogy, there is no Pax Romana because no ledger is well suited to be Rome. What we have now instead is the post Roman, Dark ages (ironically a Byzantine mess of ledgers using Byzantine fault tolerant algorithms). What KERI is aiming for looks more like the British Commonwealth.

[csuwildcat]

I'm interested in a very terse explanation of this: I am not clear on the exact roles of Watchers, Witnesses, and Validators (and generally curious what requires 3 actors in addition to the Controller), but I want to provide a simple test case, wherein the game theoretical assumption is that the Watcher/Witness nodes tend toward centralized operation, and most people pick a couple of the top 5 tech company's nodes to act as those entities for them. If a person's ability to have their next rotation and swap of those actors relies in any way on those actors, I want to understand a case where the trusted parties the user picks choose to simply deaden a Controller's ability to rotate, not because the next rotation key is compromised, but because the threshold of required counterparties are now your active adversaries. Hopefully this isn't viewed as far fetched, given we just witnessed almost all major cloud and social media companies literally collude in the middle of the night to cut off all records, access, capabilities, and interaction for millions of people. (not to mention a place like China, where they would push a button and all the trusted parties would do whatever they want)

Additional question: if only the Controller had any log of their state transition lineage and was the only one serving that lineage, could the Controller still operate flawlessly, without any of the other trusted counterparty nodes?

[csuwildcat]

Would it be possible to create a version of KERI where there was just one Watcher/Witness that was so awesome and trustworthy that a controller would never need more than that one node, and even if literally no one else on the planet hosted their log data but them, they could still have their DID resolved with absolute trust that the resulting state was accurate? How might one construct a version of KERI with those attributes?

[SmithSamuelM]

@csuwildcat You have to walk back a little. Given our current internet, if enough parties collude today , there is no publicly addressed distributed system than can not be taken down. Most internet traffic flows through only a handful of backbone networks (autonomous networks). If those handful of entities decided to block traffic to any public address (we are not talking about private encrypted onion routed traffic) then they can do it. But If you assume that the internet remains free of such collusion such that if a public IP is routable, then KERI allows any entity to be a root-of-trust on the internet exposed through such routable public IPs and that root is portable across hosting infrastructure. At least as much as it can be. A KERI rotation does not just rotates keys but also rotates witnesses. So if my web host shuts down my witnesses. I just publish to the watcher network a new rotation with new witnesses stood up on some other web host. As long as I have a DHT for discovery then it would be difficult for any web host to stop me from promulgating that rotation event with my replacement witnesses to the watcher network. Or directly to any validator that wants to access my new witnesses.

So if you want to be private then in KERI you do not need witnesses. You just use direct mode etc etc. Witnesses are for public one-to-any identifiers. But KERI security is about key management. So if you have really good really secure key management using best in class TPMs or TEEs then you don't need multiple witnesses for security you only need them for load balancing and availability. If you are using post quantum secure signatures with best class TPMs and TEEs and multi-sig then the likelihood of key compromise now and in the immediate future is remote. This is how the big boys protect their private keys. KERI just allows the little guys to do it to with an open interoperable protocol. So we can mutually verify.

[fimbault]

The way I see it is that there will be 2 use cases :

• for peer to peer / direct mode, KERI isn't very different to existing KMS in spirit (more or less automated and secure depending on the technology used)
• for public networks, controllers belonging to natural persons are likely to either publish directly (i.e. no witness) or pick their witnesses through an existing social network (or maybe a purposely built DHT), while I would expect corporations to pick witnesses under their own control to enable high availability thanks to a few edge devices / watchers have their own dynamics which is hard to predict, it really depends on the characteristics of the network

[csuwildcat]

I'm definitely talking about 1-to-any IDs. In that context, what you said above makes no sense to me, because you seemed to indicate that you now don't even need any witness at all for secure resolution of those IDs. If a verifier doesn't need to consult with any source of truth about the correct state of the event history they are given from a person who claims to be an ID's Controller, how would they ever know you aren't an attacker who constructed some fork of the lineage based on use of long-discarded or compromised keys? Seems like you'd need at least one rock solid source of truth that resolving parties consult with to ensure a potential Controller is the rightful entity presenting the correct event history.

[SmithSamuelM]

@fimbault Yes. GLEIF is a good example of an enterprise that wants to be a strong reputable root of trust for their identifiers so that stand up a public network to support their public identifiers. Whereas some mom and pop business may just use a service provider. Most web hosts provide DNS servers for free. I expect that most web hosts will provide witness and watcher services.

[SmithSamuelM]

@csuwildcat

The watcher network is how one detects duplicity. I think I explained that in detail above. Not sure what parts you missed. First seen for any watcher is the rock sold event history for that watcher. A validator gets to decide if its watcher network has consensus about first seen. If not then there is no reconcilable history. The validator does not trust. Keri does not guarantee that all duplicity is reconcilable to any validator's satisfaction. Only that a validator is protected from acting on duplicitous information. So if an honest controller has rock solid key management that cannot be compromised because they are using best practices TEE TPM Post Quantum crypto, then there is no duplicity possible so every watcher sees the one and only one version the controller promulgated.

If in spite of best practices key management some time in the future a controller's dead keys become compromised then for a reasonably well connected watcher network, all the watchers would have already first seen the original version of those dead events with the dead keys. So any reasonable consensus of those watchers would be able to resolve to the correct one. But if the watchers can't come to consensus then they can't. An they don't reconcile. They don't trust. Its the controller's loss not the validator's at that point.

Given duplicity there is no guarantee that that duplicity is reconcilable. This protects validators from both compromised and malicious controllers.

Consequently, an honest controller is highly motivated because any unreconciled duplicity might cause all validators to stop trusting that controller. Therefore the honest controller is highly motivated to not ever exhibit any duplicity. And the only way for an attacker of the controller to exhibit duplicity is to compromise keys.

If the only key compromise is DEAD keys some time in the future, then there is ample time for the publication of those long dead events to have propagated to all watchers world wide so that the only version of the events the watchers will ever see is the long dead version. Ever Ever Ever. This is what an immutable event log means. Its immutable in that the first seen version is the only seen version entered into the log. So the only way for a dead attack to succeed is to attack the watcher network not the witness network or the controller or anything to do with the controller. Once an event has been published to the watcher network it is immutable fixed as the one and only for any honest watcher. So any entity gets to pick and design their watcher network and either they have consensus and they trust one version of the event log or they trust NO version.

[SmithSamuelM]

@csuwildcat

"Seems like you'd need at least one rock solid source of truth that resolving parties consult with to ensure a potential Controller is the rightful entity presenting the correct event history."

They consult each other's copy of the key event log. If they the validators (resolving parties) can come to mutual consensus on a copy then they trust. If they can not come to consensus then there is no consensus and there is no rightful controller as far as they are concerned. No rightful controller is better for the validators than trusting the wrong controller. So KERI errs on the side of safety instead of liveness. In the event of no rightful controller given no consensus on event log version, the validators would have to resort to some other mechanism to resolve. Their governance framework for the particular transaction for example. Poorly managed controllers might have unreconcilable duplicity that causes them to abandon an identifier. Its ok there are a virtually infinite number of pseudo random identifiers. They then have to reestablish and republish and make association that this new identifier is the one for them. Its painful but with KERI a well managed controller can make identifier abandonment a rare or almost never occurrence.

[SmithSamuelM]

Attacks on the watcher network are similar to attacks on the Bitcoin peer-to-peer network. There is NO single universal rock solid source of truth if an eclipse attack prevents you form seeing it and instead presents a different version. But unlike KERI which uses immutability of first seen, any bitcoin node revises its rock solid version of the source of truth every time it sees a longer version of the chain than it has. In keri there is no revision. First seen, always seen, never unseen! No revision ever. So an eclipse attack has to ensure first seen. And if the compromise happens sometime after a key is dead then it's orders of magnitude harder to ensure first seen. So a controller just needs to publish first seen before key compromise. Thus in the one place where one has to attack KERI, that is the watchers, its first seen rule makes it much harder to attack than something like Bitcoin' peer network which allows revision by longest chain. With bitcoin one merely has to manufacture a longer chain and an honest bitcoin node (watcher equivalent to KERI) will accept the revised forged faked longer chain. In KERI that watcher won't accept any other chain that is inconsistent with the one it has. So any earlier fork from a dead compromised key won't be accepted by that watcher in KERI, ever ever ever. Thats what immutable log means. I don't know how many times I have to repeat that for it to sink in.

[SmithSamuelM]

KERI trades off liveness for safety and portability. Its a reasonable tradeoff when you are talking about identifiers not crypto-currencies. An identifier is dead (not live anymore) when one has to abandon it. Trading off liveness for anything is an unreasonable trade off for a crypto currency. Thus In KERI at some point one may have to abandon an identifier and spin up a new one. Pseudo random identifiers are plentiful and abandonment can be made very rare. And spin up is not too painful especially if its rare. So use Ledgers for cryptocurrencies. Use KERI for identifiers.

[csuwildcat]

I don't know how many times I have to repeat that for it to sink in.

I was already pretty confident about how I was assessing and factoring in the concepts and assumptions of various DID approaches (inclusive of things like KERI), but these last replies here really validated and locked in the keystone assumptions that remain true across the entire spectrum of DID approaches: the simplest, most trustworthy, most durable, most deterministically verifiable 'Watcher/Witness' options (in general, not just KERI) with the strongest guarantees afforded to resolving/verifying parties will be the ones they gravitate towards. General economic game theory and technical complexity theory predicts all parties will naturally try to limit set size, resource spend, and maintenance of their trusted witness/watcher selection relative to the greatest number, quality, and utility of features they deliver. They will also tend to coalesce on a shared handful to maximize overlap of successful trusted interactions with DID owners and verifiers. This is exactly the concrete set of statements I was looking for to be absolutely sure the same assumptions I had been standing on from the very beginning, through every thread and conversation, held true - thank you for helping me confirm they were accurate.

[fimbault]

@SmithSamuelM Yet you could make different choices. The problem also is that the arguments are very qualitative in nature. If you look at the casanova paper, you have proof of safety and liveness (at the expense of portability).

[SmithSamuelM]

@fimbault Hopefully you might be motivated to explore some of the qualitative statements and contribute some quantitative analysis. KERI makes the choice that practical universality of solving the secure attribution problem demands safety and portability but does not demand liveness of pseudo random identifiers. Hence the tradeoff. If you want to solve other problems besides universal secure attribution then other tradeoffs may be better.

[SmithSamuelM]

In KERI an identifier is safe and portable while its alive. If an identifier is locked to a ledger then the only way to be portable is to kill it first on the old ledger and then create a new identifier on a new ledger. If an identifier in KERI dies then you create a new safe and portable identifier that hopefully lives forever but may not. But if it lives a long time then one benefits from the network effects of portability while its alive. An oh one can inherit value from any old dead identifiers via the spin up process of associating the controlling entity with the new identifier. Atoms are still atoms and real world physical entities still are alive even if keys controlling their identifiers become compromised. So an identifier is just an identifier it is not the entity itself. So a dead identifier is not a dead entity. KERI allows one to keep identifiers alive much longer through key rotation mechanisms that are more secure than mere assertions from trusted entities (CAs). The CA system is universal but broken. KERI means to fix that. It doesn't want to give up on universality so it doesn't want to be locked to any ledger.

[csuwildcat]

In KERI an identifier is safe and portable while its alive. If an identifier is locked to a ledger then the only way to be portable is to kill it first on the old ledger

Just want to note that this isn't true for Sidetree-based implementations on ledgers. Not sure about other types of approaches, but it's an important point, imo, given your statement seemed general in nature.

[SmithSamuelM]

@csuwildcat When asked if you could port sidetree identifiers between ethereum and bitcoin, your answer I believe was its possible but not yet supported. Did I get that wrong? But its one thing to be live on two ledgers at the same time vs serially live on two ledger at different times.

[fimbault]

@SmithSamuelM I generally think much safer to get beyond common sense in large scale distributed networks, and try to get proofs under reasonable assumptions. That's really the downside of the approach taken by KERI ("this is not a mammal" etc.). Nothing wrong with innovation but the chance to get it wrong is higher if you change many things at once. Especially when the network involves many entities with their own objectives, unanticipated behaviors (selfish and attack) might occur.

About portability, I'm not sure the practical advantage it's providing. Even if I had to kill the ledger and start again, it's not very different from having to recreate an identifier in KERI. Plus implementations based on blockchain are usually standard enough that you can transparently switch from one to another without too much trouble (for instance, IBC). Or did I miss something?

[fimbault]

Although there was this GDPR argument which seemed interesting, but I don't remember exactly what it was.

[SmithSamuelM]

@fimbault I guess my practical observation and participation in the decentralized identity community over the last few years and working with the various standards and wallets and players lends me to believe that ledger lock and ledger wars and method proliferation are big problems that have severely hurt the community and adoption. So and I think many will agree with me that more convenient portability has many very attractive practical advantages. Not the least of which is GDPR. But if you want to use a ledger with KERI you can but then you may have GDPR problems as has already been a problem for identity specific ledgers. But I appreciate your feedback. KERI may not be for you.

[SmithSamuelM]

What often gets lost in these discussions are apples to apples comparisons of key management security. Because KERI is essentially nothing but key management, ( it's called a DKMI for a reason), It's easy to forget that that all ledgers rely on key management and most of them employ much weaker key management than does KERI. So if the same vulnerability to key compromise that is assumed when criticizing KERI is applied to ledgers many of the ledger guarantees of security similarly vanish if not more so. Recognizing that the weak link is almost always key management in any distributed system is one of the prime motivations for KERI's approach because if I want to manage any system and my security is based on key management then I want to employ best practices key management. That is KERi. Given that then it becomes possible to ask another question, that is, do I need anything more than key management. And for some applications where I might employ self-certifying identifiers the answer is no, all I need is key management. Now could it be done another way. Yes. But first examine the key management of the other way and if its weaker than KERI and similar assumed attacks on key compromise are more easily done with devastating effect then all the purported advantages of the other way are not true given the assumed key compromises.

For example an Ethereum smart contract may be used to manage an identifier and manage its keys and make key rotations. How does one control that Ethereum smart contract? By one or more ethereum addresses which are essentially public keys. So if only one Ethereum address controls the smart contract then only one key compromise is required to completely capture the smart contract. All the other benefits of Ethetreum don't matter because a single key compromise was all it took to capture control of the smart contract and hence the identifier and the keys controlling that identifier via the smart contract. (note these are two different sets of keys, access keys are not the identifier's keys) If I control the smart contract then I control the identifier because I can change the identifier's keys by posting transactions to the smart contract given I control the access keys .

If instead that smart contract is controlled with a multi-sig set of access identifiers using a multi-sig wallet like gnosis wallet (not parity which was compromised) then ALL I need is to compromise a majority of those keys to capture control of the contract and the identifier. Now most people would be aghast that I just assumed away a multi-sig compromise. But throughout these discussions on KERI it is regularly assumed away. So if my KERI identifier is protected by multi-sig then that same level of compromise of a majority of keys would not be enough to capture control. Because in KERI I would have to also compromise the multi-sig set of pre-rotated keys that have never been exposed or used to sign anything. Not merely the current signing keys. So if one assumes one can compromise KERIs signing keys then they have already assumed the equivalent of zero security for any ethereum smart contract protected by a multi-sig wallet. But KERI allows one to recover from a compromise of a majority of its signing keys via a rotation to the pre-rotated keys. And if the identifier is delegated then even a compromise of its pre-rotated keys is recoverable via a rotation from the delegator.

Now could someone also implement KERI like pre-rotation in an ethereum multi-sig wallet. Yes. But it would not be portable. Similar arguments about identifiers controlled by bitcoin addresses apply. If you think keys are hard to compromise then you should like KERI. If you think keys are easy to compromise then you should like KERI even more. Because in either case KERI is best of breed key management. The only way you don't like KERI is if you are not using PKI. And since every ledger I know of uses PKI for access then they should care.

To clarify. Its not the keys of the identifier being managed by the ledger that is the weak link. Its the keys of the access identifiers that put transactions on the ledger that is the weak link. In KERI they are one and the same, so its weakest link is also its strongest link. Each KERI identifier has its own KEL that replaces a ledger. But almost all ledger access identifiers use much weaker key management than KERI provides. To restate, if you compromise the ledger access identifier keys you may then compromise the keys of the identifier managed by that ledger. So if the key management of the ledger access identifier keys is less than KERI class its less secure than KERI. Moreover, if you depend solely on the ledger as the rock solid source of truth then you won't detect any compromise when it happens. Whereas with KERI, duplicity detection gives you a signal that compromise has occurred and you need to resolve it.

So it matters little if every validator trusts the ledger to provide the key state for an identifier managed by that ledger if the ledger access addresses have been compromised. The key state on the ledger is garbage. Garbage in Garbage out. Its a zombie identifier. It looks like its LIVE because the ledger says it is but it's not controlled by the rightful party. It should be killed or abandoned only there is no signal to tell you its a zombie and needs to be killed. Zombies indistinguishable from non-zombies are much more dangerous than zombies that are clearly zombies.

If you are not verifying all steps contributing to key state changes you have no security and access identifiers are part of those steps. Ledgers like Bitcoin and Ethereum provide no visibility into the key compromise state of their access identifiers . Whereas KERI goes to great lengths to provide a signal via duplicity detection into the potential key compromise state of its identifiers.

[fimbault]

Sure I agree with that, and tbh that's why I'm looking at KERI

[fimbault]

Plus some meta arguments as well https://fimbault.medium.com/the-ethical-dilemma-posed-by-decentralized-identity-f8328b655544

[csuwildcat]

When asked if you could port sidetree identifiers between ethereum and bitcoin, your answer I believe was its possible but not yet supported. Did I get that wrong? But its one thing to be live on two ledgers at the same time vs serially live on two ledger at different times.

It would not be hard to set up a Sidetree implementation that runs across multiple ledgers (or other trust substrates), it's just that no one had cared to do so. Such an implementation would simply digest/process DID ops from 1 + N ledger/trust substrates, and users could anchor (in your parlance: 'witness') ops across any of them. Again, the protocol can absolutely be applied this way, it's just not been something the current set of implementers had been interested in - until now, with Orb (the thing the SecureKey folks are working on)

[SmithSamuelM]

@but the root of trust is not sidetree nor sidetree's entries on a ledger is the original DID method's root-of-trust. So you don't really have portability with SideTree in the same sense that KERI defines it.

[csuwildcat]

Not the least of which is GDPR. But if you want to use a ledger with KERI you can but then you may have GDPR problems as has already been a problem for identity specific ledgers. But I appreciate your feedback. KERI may not be for you.

We will soon publish a post that discusses this overarching topic, per the determinations of our counsel (multiple sources, both outside and in-house), which concludes:

1. Decentralized deterministic systems are very different from permissioned ledgers and federated/trusted entity networks, as it pertains to this issue.
2. With truly decentralized deterministic protocol, node operators are not Controllers.
3. For truly decentralized deterministic systems where there are no trusted parties, utilization of immutability features is something that is up to the user, which deterministic protocols faithfully, mechanically execute.

It's going to be great for the whole community, because a solid company and trusted source in the identity space is finally going to wipe away a ton of dubious FUD and clarify this for the industry.

[SmithSamuelM]

Sidetree is an oracle of another root-of-trust (the did method's root-of-trust) it doesn't replace the DID method's root-of-trust. So the side tree oracle may be portable but the root-of-trust never moves. Its not portable so the identifier's root-of-trust is still locked to its ledger, regardless of side-tree. If the root of trust is portable then its not the ledger but some other mechanism. If that mechanism is a self contained hash chained data structure, then thats KERI and if you modify sidetree to do that then great you just copied KERI.

[SmithSamuelM]

I certainly welcome any legal clarity on GDPR. There has been very little forthcoming from the regulators.

[csuwildcat]

Sidetree is an oracle of another root-of-trust (the did method's root-of-trust) it doesn't replace the DID method's root-of-trust. So the side tree oracle may be portable but the root-of-trust never moves. Its not portable so the identifier's root-of-trust is still locked to its ledger, regardless of side-tree.

You're not really using the same technical language I typically do here, so I am not 100% sure, but I don't think this statement is correct (if I am reading you right - apologies if not). If a Sidetree method was implemented to include multiple underlying trust substrates, DIDs users create aren't inherently bound to any one, you just need to be able to trace their 'witnessed' log across them (seems the same as hopping 'witnesses/watchers' in KERI), and it would still resolve to one deterministic state.

[csuwildcat]

I certainly welcome any legal clarity on GDPR. There has been very little forthcoming from the regulators.

I agree, and I think our folks stepping in to take a position will help everyone, and get a lot more discussion going!

[SmithSamuelM]

@csuwildcat See my edit of my prior comment. In KERI the root-fo-trust is a KEL. It may be hosted by any substrate. That is portability. Witnesses are not the root-of-trust in KERI. They are just reliable store and forward services. So having multiple fixed substrates is not portability in the KERI sense. In KERI the KEL moves across any substrate. Whereas in sidetree the substrates are the KEL and may not move. This may be a source of your confusion about KERI. A primary root-of-trust is irreplaceable in KERI parlance. A KEL is irreplaceable. A witness hosting a KEL is eminently replaceable. Whereas in sidetree if the anchors on bitcoin go away, what is there to trust? Now you could cross anchor to multiple ledgers but then you are not porting between substrates your are just locking your root of trust to multiple substrates. Sidetree is clearly a hybrid. You could adapt SideTree to give it full KERI level portability. So for example if you want to verify your key state back to the root of trust and you are hopping event anchors from one ledger to another then if that ledger goes away, you lose those hops and no longer have a verifiable data structure. The KEL is a hash chained integral data structure. Any copy will do. It doesn't matter what substrates it uses and if the substrate goes away no loss because the only thing a substrate does in keri is provide a store and forward service. This service contributes nothing to the verifiability of the contents of the KEL. Given a verifiable KEL obtained from any source or substrate (because in KERI sources don't really have to be all that firm) all that remains is that one has to ascertain if its the only KEL or if there are duplicitous KELs and if there are duplicitous KELS then resolve them if possible. So portability in the KERI sense is not possible with any locked down substrate with anchored transactions that are part of the key state history because then the substrate is a primary root-of-trust that can't be replaced. I hope this is starting to become clear. It seems that there are some very fundamental concepts about portability as developed in the KERI white paper that I assumed were understandable from reading the white paper.

[SmithSamuelM]

One more attempt.

In keri there are no access keys only the keys that control the identifier. The self certifying derivation of an identifier from private keys and other inception information contained in the incept event for that identifier provides a cryptographic root of trust. Its self-certifying that a signature on that event is verifiable given the event. This starts the chain of trust. A rotation event signed by the inception keys may change to a new set of keys. The key state determines which keys are authoritative to make any change in key state. So each event is hash chained to the previous event and signed. This makes a cryptographic backwards facing commitment to all the prior events. All one needs is the KEL log to verify it all the way back. Because all the keys and all the signatures are in the log to verify key state at each step. So the log itself is the root-of-trust not any substrate or witness or service or anchor. Where it gets confusing is that witnesses are designated in the log and witness signatures (receipts) may be attached to events in the log in addition to the signatures from the controlling keys. The purpose of the witness signatures is help with discovery protection and to help the controller protect it signing keys by requiring an attacker to get the witnesses to sign a forged event. But once an event is witnessed and added to any watchers dopy of the log the witnesses no longer provide any value. The witness keys are in the log so any one can verify their signatures. on the log with nothing but the log itself. Its all self contained.

Given this KEL or KERL (with witnessed signatures = receipts) then presentation of the KEL to anyone is a proof of control authority over the identifier as of the last event in the log. Do I trust the proof? Depends on the promises made by the presenter and provable controller of the latest keys in that log and the transaction.

If I am in a private one-to-one conversation then the first log given to me I trust and if any event shows up that is duplicitous (inconsistent with that log) then I throw it out or decide not to trust. Because any duplicity is evidence of key compromise. If the compromise is of a key long dead then I might decide to ignore it. If its a compromise of the current signing key then I expect a recovery rotation event to recover and then I can trust after recovery. If it is a total compromise and therefore unrecoverable then I expect that the controller will abandon the identifier complete compromise still has duplicity and the original controller can increase its own duplicity to signal it should be abandoned.

If I am talking to a public entity who has promised that it will only ever create one version of its KEL and if its keys are ever compromised resulting in duplicitous copies of the log, then I need to resolve that compromise. One way to resolve it is to compare notes with others I trust who are also talking to that public entity. if they also can attest that they see the same version of events that I see then I can trust in what I see. This is how certificate transparency works. This is how one protects oneself from eclipse attacks on the peer-to-peer bitcoin or ethereum networks.

The difference with KERI is that all the keys and all the signatures used to evaluate key state are self contained. Key compromise exhibits as detectable duplicity so I want to track that. I have visibility into not just key state but key compromise. I don't have comparable visibility into key compromise for access identifiers to a ledger.

[csuwildcat]

I think there may still be some really fundamental misconceptions:

In KERI the root-fo-trust is a KEL

In Sidetree, the root of trust are your DID operations - let's call it a 'SEL', just so we can stop imagining KELs as somehow magically different, because the two are identical in every technically functional way.

The KEL is a hash chained integral data structure.

In Sidetree, your 'SEL' is a hash/sig-linked series of mutations from a genesis create operation - literally the exact same thing in different words. Sidetree has a mechanism to publish those in a scalable way, to any N + 1 substrates an implementation trusts to operate on.

It doesn't matter what substrates it uses and if the substrate goes away no loss because the only thing a substrate does in KERI is provide a store and forward service. This service contributes nothing to the verifiability of the contents of the KEL.

Much like KERI, Sidetree-based DIDs don't fail if a substrate fails, if you assume - just like KERI - that the user never lost root control of their root key lineage at any time. The substrates are only to empirically, deterministically provide oracle-strength conclusively that no loss of control ever took place, with the added bonus of a unified pipeline for 'duplicity detection'.

The purpose of the witness signatures is help with discovery protection and to help the controller protect it signing keys by requiring an attacker to get the witnesses to sign a forged event.

Yeah, a 'witness' would just be another substrate to Sidetree - if you just replace in your mind the word ledger with 'witness', it's the same. Most of the current implementations happen to use a large public blockchain for this function, but the protocol itself is not bound to that in any way.

[SmithSamuelM]

In Sidetree, the root of trust are your DID operations

Actually this is a huge difference because KERI's security and semantics are independent of any namespacing layer like DIDs. The DID method is a root-of-trust so you are making some security assumptions about those DID operations that KERI does not ever need to make. The same KEL works for any namespace that includes the KERI identifier prefix.

But the DID method is a portability constraint.

The SEL is not a KEL. Because the operations on a KEL are self contained without reference to any namespace layer above. Whereas DID methods have different ways of securing their DID operations. This makes SideTree much more complex to analyze from a key security perspective. You may need ledgers with SideTree if for no other reason than DID crud methods operations typically have key security problems.

So if you move SideTree down to the KERI prefix layer and get rid of DID methods then you have the portability equivalent of KERI. But as long as you have DID methods then you may get close to KERI portability but never reach it.

So yes if you got rid of did methods and operated at the next layer

Much like KERI, Sidetree-based DIDs don't fail if a substrate fails, if you assume - just like KERI - that the user never lost root control of their root key lineage at any time. The substrates are only to empirically, deterministically provide oracle-strength conclusively that no loss of control ever took place, with the added bonus of a unified pipeline for 'duplicity detection'.

But thats my point. With KERI you know if they lost control. You don't assume it with KERI. With SideTree you assume it and you have know way of knowing if they lost it.

SideTree is not portable key management its dependent on someone else's key management a DID method's key management.

There are lots of similarities between KERI and SideTree as @OR13 likes to point out. I know you have changed some stuff in sidetree based on my past comments. But its does not do the community any favors to state that there are no fundamental differences. You claims mask some very important distinctions. So to be fair you could make some changes to SideTree to make it virtually identical to KERI. The idea of encapsulating DID operations into a SideTree hash chained data structure superficially looks like a KEL. No doubt. But KERI was designed to provide its security properties without utilizing the crutch of a ledger. Sidetree in all its literature assumes that crutch. So I would be reluctant to claim that absent a ledger that any given did method operations that are designed for a given ledger, have similar security properties in side tree but without that ledger designed for that DID method. If so then why isn't that in the SideTree specification?

[SmithSamuelM]

I would be surprised that a BTCR based DID method can be verifiably secured without Bitcoin as a substrate but merely with a Sidetree SEL absent any substrate.

[SmithSamuelM]

The SideTree spec is replete with ledger specific requirements such as:

§ Transaction Anchoring

Once an Core Index File, Provisional Index File, and associated Chunk Files have been assembled for a given set of operations, a reference to the Core Index File must be embedded within the target ledger to enter the set of operations into the Sidetree implementation’s global state. The following process:

Generate a transaction for the underlying ledger Generate and include the following value, herein referred to as the Anchor String, within the transaction: Generate a numerical string ('732') that represents the total number of operations present in the Core Index File and Provisional Index File, herein referred to as the Operation Count. Using the CAS_URI_ALGORITHM, generate a CID for the Core Index File, herein referred to as the Core Index File CAS URI. Join the Operation Count and Core Index File CAS URI with a . as follows: "10000" + "." + "QmWd5PH6vyRH5kMdzZRPBnf952dbR4av3Bd7B2wBqMaAcf" Embed the Anchor String in the transaction such that it can be located and parsed by any party that traverses the history of the target ledger. If the implementation implements a per-op fee, ensure the transaction includes the fee amount required for the number of operations being anchored. Encode the transaction with any other data or values required for inclusion by the target ledger, and broadcast it.

Regardless of the ledger system an implementer chooses, the implementer MUST be able to sequence Sidetree-specific transactions within it in a deterministic order, such that any observer can derive the same order if the same logic is applied. The implementer MUST, either at the native transaction level or by some means of logical evaluation, assign Sidetree-specific transactions a Transaction Number. Transaction Numbers MUST be assigned to all Sidetree-specific transactions present in the underlying ledger after GENESIS_TIME, regardless of whether or not they are valid.

Now I certainly don't understand SideTree anywhere near what you do. But most of your statements comparing SideTree to KERI are asserting that the two are essentially the same and SideTree works just fine without ledgers are in my opinion strongly inconsistent with the SideTree specification. So maybe your comments are aspirational. I can't tell but I think that this is not a good forum for that. This issue was to help users and implementers of KERI understand its features not be a forum for you to advertise SideTree as the same as KERI. But I welcome you to open an issue on the SideTree repo and explain to the world in detail how to implement KERI in SideTree and then I can comment on any security issues I see as a result.

[csuwildcat]

I would be surprised that a BTCR based DID method can be verifiably secured without Bitcoin as a substrate but merely with a Sidetree SEL absent any substrate.

Question:

1. What does any of this have to do with BTCR? (hopefully no one thinks that is related to Sidetree somehow, because it's not in any way)
2. Yes, a 'SEL' is a hash-and-sig-linked progression of DID operations (you can call it a log, list, set, etc.) that start with a deterministic entirely independently verifiable creation event (your initial state that binds the start of your key-lineage), and progresses via subsequent events, wherein all events form a chain of commit/reveal links to pre-rotated keys that cryptographically transition the DID from one state to the next. If you never anchored those events to a substrate, they are absolutely verifiably secure as presented, and you can resolve right through each state change. Now, the reason you would project them to some substrate(s) is precisely because you might want to know the holder isn't using different branches from that genesis event, or that there has been any root key loss (basically, anchoring provides nuclear bomb-proof deterministic 'duplicity detection')

The fundamental technical approach and assumptions between the two (KEL/'SEL') are literally identical.

[csuwildcat]

The SideTree spec is replete with ledger specific requirements such as:

Sam, no it isn't - I am literally going to replace the word ledger in the spec just so you stop saying this. Wherever it says 'ledger', the common term that most implementers used for referencing the 'witness/watcher' layer, just think 'witness/watcher layer'.

[csuwildcat]

I will also point out that you linked to the part of the specification that deals with the batched file structures that include the DID events in an efficient, scalable manner, which is separate from the actual individual events and their hash-and-sig-linked event lineages that exist independently. Basically, Sidetree defines the same thing for KEL and the events that make it up, then goes on to define an optimal file structure for aggregation of those events in the case you want to apply them to a ledger/witness/watcher/oracle/cabal/DHT/foo/bar-substrate for all the added benefits that you get from doing so.

[SmithSamuelM]

The fundamental technical approach and assumptions between the two (KEL/'SEL') are literally identical.

They are both hash chained data structures. The are not literally identical because the operations in SideTree are at the DID layer. If you removed DIDs and all the did related stuff in SideTree and only operated at the identifier prefix layer then they would be close. But SideTree does not make commitments to its witnesses as part of key rotation so it wouldn't have similar security properties to KERi until it does. That SideTree copied other features of KERI like pre-rotation is a good thing. But as you understand more of KERI it seems you want to emulate it more. Thats a good thing. But let's let KERI be KERi and SideTree be SideTree.

[SmithSamuelM]

One of the important nuances of KERI is providing evidence and mechanisms to help resolve or reconcile duplicity without having a ledger as a crutch. Those nuances are not yet in SideTree at least as far as I can tell from reading the spec. A hash chained data structure of key operations requires more than just the data structure to be reconcilable in the event of key compromise. It requires a set of rules and operations for verifying what they mean that matter. And I see no evidence of comparable rules in the SideTree spec. Its those things that were designed into KERI to make it ledger agnostic not bolted on as an afterthought . So please provide a DID free specification for SideTree with the logic for a ledger free reconciliation of duplicity and key compromise recovery and then it would be a good useful discussion. Otherwise it serves no purpose to claim they are the same when they are not. They have similarities as I have acknowledged but also important differences.

[csuwildcat]

SideTree does not make commitments to its witnesses

Can you explain what you mean by this? I was under the impression KERI did not need a ledger/witness layer to have a KEL be deterministically evaluated, assuming you don't care about the other features you get from doing so. In that sense, it's the same as Sidetree. Sidetree implementations can be created to make commitments to any type/set of witnesses you want, because, like I reiterated above, the word 'ledger' used in the spec is just a term that stands for 'anything you want to witness your events', which just happened to be the thing most people used as their witness/watcher layer. However, I will definitely change the term used given the confusion it seems to have caused. (I guess it's true that it's overloading a word that means specific things to people, so it's probably for the best)