hey @tobowers Tobowers - the DKMS work is in progress at Evernym and there will be a research report and functional demo release by the end of March 2018. All of the work will be open sourced and contributed to Hyperledger Indy (and by extension, built into Sovrin.

# Recommendations for Decentralized Key Management Systems
### by Michael Lodder
### Evernym, Inc.
## Abstract
---
A decentralized key management system (DKMS) aims to solve how consumers can manage their own keys and certificates without relying on a third-party provider having access or controls over the keys.. This method helps to ensure that no third-party can compromise the integrity and security of the system as a whole. Entities can use the system to safely authenticate each other and validate keys and certificates. Centralized key management systems (CKMS) manage key and certificate creation, signing, and validity. Specific problems arise when these authorities become unavailable, or the data they control becomes corrupted or known. Central authorities often become choice targets for attackers. This document proposes to meet these requirements with a decentralized blockchain ledger for providing an oracle of trust and leave control over all keys with end users. The use of a blockchain permits globally readable identifiers and public data to be shared in a secure manner that is not vulnerable to the man-in-the-middle attack or system wide compromise and permits consumers to be self-sovereign. This leaves consumers with the task of key management and protection. This document covers various ideas for how users may create, recover, backup, and revoke keys and provides recommended suggestions.
## 1 Introduction
---
In a typical centralized key management system, a third-party such as a certificate authority, kerberos, or enterprise deployment will maintain control over users keys and certificates. Systems will create keys on user's behalf, protect them from unauthorized use, rotate them as specified by best industry standards, and revoke them in the event of compromise. This simplifies the experience for users by abstracting away key management altogether. Security administrators like this setup as it leaves the difficulty with them. System administrators will typically harden the systems to prevent unauthorized access. Negatively this setup simplifies the target to one location for attackers. Also users may not have any degree of control over their keys and certificates. Instead they must notify their administrators if they suspect compromise or lose their secrets. Personal identifiable information (PII) is usually stored alongside these keys which makes the central authority even more valuable to attackers.
Key management can be a difficult task as it requires knowing what types to use, which crypto systems are more secure, how often they should be changed, how to distribute them to others in a secure manner, how to indicate which of them are no longer trusted, how to recover if they are lost or stolen, and how to protect them. Privacy is also a major concern as any information that can be correlated to them can potentially be used against them. DKMS should preserve privacy, allow endpoints to manage their own secrets, and provide a method for establishing trust for distributing public information in a secure manner. Endpoints can be implemented in the form of decentralized identifiers (DIDs) and any keys used by that DID in DID description objects (DDOs) which provide anonymity for identities and their keys. A DID is a globally unique identifier that is generated cryptographically and self-registered with the identity owner’s choice of a DID-compatible distributed ledger so it requires no central registration authority. Each DID points a DDO, a JSON-LD object containing the associated public key(s) and a pointer to off-ledger agent(s) supporting peer-to-peer interactions with the identity owner. From this baseline, trust between DID-identified peers can be built up in two ways:
1. Challenge/response messages for real-time verification of public keys.
2. Exchange of verifiable claims—claims about identity attributes that include digital signatures or other cryptographic proofs from other DID-identified trusted peers whose public keys or proofs can also be verified against the ledger.
This decentralized web of trust model leverages the security, immutability, and resiliency properties of distributed ledgers to provide highly scalable key distribution, verification, and recovery, finally making PKI accessible to everyone. However, because it does not depend on any centralized authorities, it also shifts some measure of responsibility for key management directly to each participating identity owner. This demands the decentralized equivalent of the centralized cryptographic key management systems (CKMS) that are the current best practice in most enterprises.

Hi @phil
I’ve a question to the revocation on Sovrin. I’ve read the paper “What goes on the Ledger” and “digital identites in the blockchain era” you have kindly provided. As far as i understand it claim issuers publish an encrypted revocation list (called validity tails in the second paper).
But isn’t it a privacy threat to publish claim revocations lists on a public accessible ledger?

No, it’s done with a cryptographic accumulator on the ledger. When the identity owner creates a proof from a claim, the ZKP process uses the accumulator to also prove that the claim hasn’t been revoked. So, it’s not something the claim inspector (relying party) has to check separately (and therefore they don’t need to be able to read it). Rather it comes along as part of the proof and is cryptographically sound.

After i studied the cryptographic accumumlator I came across another question.
Since Sovrin is also on a Web of Trust model where Users can Issue and sign Claims for each other, a User would possibly want to revoke a claim which was signed by him.
Is there a possibility for Users to revoce Claims they issued to another User? Does he need to maintain his own revocationlist and needs to update it each time he revokes a claim which was issued by him?