SmithSamuelM
commented
5 years ago I think this arises from a ledger focus without understanding what self-certifying means. It’s a common misconception that even those that should know better make as their focus is on preserving integrity of the did doc not preserving the root of trust in the origination of the identifier. The did doc is authoritative for events after origination but cannot be authoritative for origination itself. The genesis of the DID Doc is too late. It occurs after origination of the public/private key pair. The ledgerization attack is one example of what happens when the root of trust for origination is skipped. One reason for this misconception is that crypto textbooks (indeed much of crypto practice) assume that there is some authority that originates public private key pairs and therefore origination is a given. But this is inherently centralized. But in decentralized systems there is no UNIQUE origination authority. So its a bootstrap problem and self-certifying identifiers ( which are not mentioned in most crypto textbooks) elegantly solve the bootstrap origination authority problem by including the public key in the identifier. This means only the creator of the public key is uniquely able to certify as the origination authority via the associated private key and as importantly any entity may likewise be the only verifiable origination authority for any sufficiently collision resistant key pair they create ( assuming sufficient entropy for universal collision resistance). The authority is derived from the vanishingly small probability and any other entity could create the same public private key pair. Any namespacing (identifier) system that does not include the public key in the identifier opens new avenues of exploit because the identifier is no longer self-certifiable and hence dependent on some external origination authority and the linkage between that external origination of a public/private key pair and its association with the identifier is now open to exploit. Protecting the genesis of the DID Doc is too late. The origination event of the public private key pair and its association with the identifier is not protected.
The root of trust is that a public private key pair origination event when performed with a seed of sufficient entropy and a sufficiently strong digital signature cypher-suite is universally collision resistant. The origination event therefore unduplicatable and therefore self-authorizing.
To further elaborate. Much of modern PKI crypto assumes that users are incapable of managing their own private keys. This is still a widely held assumption by many expert practitioners in the field. As a result some external entity must therefore manage the key-pairs on the user’s behalf. This management authority may then create public-private keys pairs. This management authority derives its authority via the same self-authorizing capability of the public/private key pairs it creates. However it now may authoritatively associate those keys pairs with any identifier namespace it controls. The identifiers may not be self-certifying and don’t have to be because the managing entity has control over a namespace. Or a context that implies a namespace. It’s authority over the namespace allows it to make the association between public/private key pair and identifier. But now the managing authorities servers are a target of exploit. Making the managing authority a permissionless blockchain means that the association must be defined by an algorithm such as first to register. But even then participants (nodes and entities) derive their authority for participating from self-certifying identifiers (aka blockchain addresses which are encoded public keys from a public private keys pair). The root of trust in all decentralized systems is ultimately self-certifying identifiers derived from the public key of a public private key pair. Trying to mask this just gets us into trouble.
Sent from my iPad
On Sep 17, 2019, at 16:07, Daniel Hardman notifications@github.com wrote:
Originally, the peer DID spec required the peer DID value to be derived from "the public key". However, at IIW last spring, Christian Lundkvist convinced me that the did should derive from a hash of the genesis version of the DID Doc instead. Since that includes one or more public keys, it has much the same protections. But it doesn't have a protection against the abuse case I described in the preceding paragraph.
dhh1128
A discussion thread on this vulnerability was started in the W3C CCG. Here's a quick summary of it for background:
Now I'd like to reason about how this applies to peer DIDs. Here's how it could play out there: Alice's agent 1 creates a DID doc for a relationship with Bob, naming keys for agent 2 and agent 3 as also authorized. Then Alice's agent 2 (which may have been hacked without Alice realizing it) can take that DID doc and send it to Carol, using the agent 2 key to sign. The rogue agent thus "registers" the DID doc in a way and with a party that the DID owner did not intend. This is basically the "anybody can ledgerize" attack.
Originally, the peer DID spec required the peer DID value to be derived from "the public key". However, at IIW last spring, Christian Lundkvist convinced me that the did should derive from a hash of the genesis version of the DID Doc instead. Since that includes one or more public keys, it has much the same protections. But it doesn't have a protection against the abuse case I described in the preceding paragraph.
At first glance, there seemed to be 3 possible answers:
Start the DID Doc with one public key; this is "the public key" from which the DID value derives, granting authority to all others. Require that the other 3 keys be added in subsequent operation(s).
Allow the DID Doc to be created with multiple keys, but make one of the keys special (e.g., the first key, or the key tagged as "prime" or some such); this is the one that must authorize creation.
Technique 1 might seem better from the perspective of self-certification purity, but it has a different cybersecurity problem, which is that such a strategy requires that you operate without checks and balances, and without backups, for some period of time early in the lifespan of every DID. We therefore discarded it; we wanted to be able to say, even in the genesis state, that a given DID is guarded by M-of-N signature policies, for example.
Right now the peer DID spec takes a weakened form of approach 2. It simply requires that the genesis DID doc be associated with (not necessarily signed by) one of the keys in its genesis state. Besides direct signing, "associated with" could mean that the genesis DID doc is streamed over DIDComm channels that authencrypt with one of the keys in question.
There is option 3:
This eliminates the "anybody can ledgerize" risk, but it may be unacceptably inconvenient. I might create several keys that I store in vaults, offline, and that I never want to pull out when I'm creating new relationships--yet I might want to name those keys in the genesis versions of my pairwise DID Docs.
@SmithSamuelM suggested my current preferred option, which is to use pre-rotation. Basically we start a peer DID with only 1 key, and then we immediately create a delta that adds the other keys, before we even share the DID Doc at all. This is easily done and satisfies the convenience and strong security requirements. Its only drawback is that we need to modify the connection protocol (Aries RFC 0023) so it's possible to send a delta along with the initial version of a DID Doc that's exchanged when building a connection.