Lately, I’ve been thinking a lot about use cases for self-sovereign identity. This series of blog posts discusses how Sovrin can be used in different industries. In this article I discuss Sovrin and GPG.

As I read I’m throwing in the towel on PGP, and I work in security from Filippo Valsorda, I couldn't help but think that it illustrates a real problem that Sovrin solves. Valdorda says:

But the real issues, I realized, are more subtle. I never felt confident in the security of my long-term keys. The more time passed, the more I would feel uneasy about any specific key. Yubikeys would get exposed to hotel rooms. Offline keys would sit in a far away drawer or safe. Vulnerabilities would be announced. USB devices would get plugged in.

A long-term key is as secure as the minimum common denominator of your security practices over its lifetime. It's the weak link.

To see how Sovrin can help, let's talk about DIDs and DDOs.

DIDs and DDOs

A distributed ledger like Sovrin is a key-value store with entries that are temporally ordered and immutable. Decentralized Identifiers (DIDs) are intended to be one kind of key for a ledger. A DID is similar to a URN (universal resource name) and has a similar syntax. Here's an example DID:

did:sov:21tDAKCERh95uGgKbJNHYp

The ternary structure includes a schema identifier (did), a namespace identifier (sov in this case) and an identifier within that namespace (21tDAKCERh95uGgKbJNHYp) separated by colons. DIDs are meant to be permanently assigned and not reused. DIDs can be used to identify anything: person, organization, place, thing, or even concept.

DIDs point to DDOs, or DID Descriptor Objects. A DDO is a JSON-LD-formatted data structure that links the DID to public keys, signatures, and service endpoints. We can use the signatures to validate that the DDO has not been tampered with, the service endpoint to discover more information about the DID, and the public key to secure communication with the entity identified by the DID.

Sovrin is designed to support a different key pair for each DID. Consequently, a DID represents an identifier that can be specific to a particular relationship. Say I give 20 DIDs to friends I want to communicate with. Each associated DDO would contain a public key that I generated just for that relationship. I would sign these with a key that is well known and associated with social media and other well known online personas I maintain.¹

The keys associated with these DIDs can be rotated as frequently as necessary since people never store my key, they only store the DID I give them for communicating with me. The ledger ensures that the most recent public key for a given DID can always be validated by checking the signature against the key associated with my well known DID.

Of course, I've also stored DIDs for my friends and can check communications from them in the same way.

These features, taken together, do away with the need for long-term keys and ease the burden of knowing the public key for someone you want to communicate with. So long as you know DID for the person, you can encrypt messages they can read. ²

A Proposal: GPG and Sovrin

Which brings me to my proposal. Sometime in the first part of 2017, the Sovrin identity network will go live. The sandbox is available now. Many of the most advanced features of Sovrin will not be available in the MVP, but DIDs, DDOs, and public-private key pairs will be.

Could GPG be modified to perform as a Sovrin Client? I believe the following would be required:

1. Create DIDs with valid public keys on the Sovrin ledger³
2. Store and manage the private keys associated with those public keys
3. Store DIDs and associate them with contacts on the user's computer
4. Look up the DDO and public key for a given DID on the Sovrin ledger
5. Check signatures on the DDOs
6. Use the keys in the DDO for cryptographic operations

I'll admit to being a naive user of GPG, so perhaps there are problems in what I'm proposing that I can't see. Please let me know. But if GPG could be made to work with Sovrin, it would seem to solve some of the problems that have long plagued PGP-based message exchange and present a great use case for the Sovrin ledger.

1. This feature makes DID-based public keys superior to other solutions where the users is identified everywhere by a single identifier (say a phone number) since it prevents correlation.
2. I recognize that this proposal doesn't solve the very real issue of private key management on the client.
3. Key creation would be aided by a agency run by the Sovrin Foundation to save GPG from having to do the heavy lifting.

Photo credit: The Enigma Machine from j. (CC BY 2.0)