Re: "anybody can ledgerize" vulnerability

Sam,

Thank you for your explanation. And thanks to everyone for this discussion.
As the DID Specification work moves forward, I would like to make sure we
don't lose track of this concern.
Would someone be willing to open an issue about it in the working group
github repo <https://github.com/w3c/did-spec/issues>? That way the DID WG
can try to address it.

On Thu, Sep 19, 2019 at 12:11 PM ProSapien Sam Smith <sam@prosapien.com>
wrote:

>
> Some additional comments:
>
>
> The problem is that the DID Spec in its current form is sufficiently
> ambiguous that it does not require self-certifiability but implies
> (dangerously so) that complying with the spec without self-certifiability
> is sufficient.
>
> Proving control of a DID, i.e., the binding between the DID and the DID
> Document that describes it, requires a two step process:
>
>    1. Resolving the DID to a DID Document according to its DID method
>    specification.
>    2. Verifying that the id property of the resulting DID Document
>    matches the DID that was resolved.
>
>
>
> This issue came up because the did:peer method  was designed to be
> private and not put on a ledger, however, the current formulation of the
> did:peer method suffers from the "anyone can ledgerize" vulnerability
> precisely because it is not self-certifying.  So the ambiguity in the spec
> is a problem.
>
> For example Veres one goes beyond the specification by ensuring that a
> fingerprint of the verifiying key pair is in the DID itself. (ie is
> self-certifiable)
> Quoting Dave Longely:
> "Veres One (v1) protects against this by requiring the DID itself to be
> derived from key material. A Veres One "nym" (short for cryptonym) DID
> must be derived from one of the `capabilityInvocation` keys expressed in
> its associated DID Document. The act of registering the DID requires
> that the DID Document itself be invoked as a capability
> ("self-registration"). This invocation can only be performed by whomever
> controls the private key material associated with a
> `capabilityInvocation` key, and specifically, the DID itself must have a
> fingerprint (or full public key material) that matches that key.
> "
>
> A reasonable interpretation of the spec language allows one to NOT include
> a fingerprint of the public key from the public/private key pair used to
> sign the did document in the DID itself.
> Merely that the id property matches the did  but the id property could be
> anything and does not have to be cryptographically linked to the signing
> key material provided in the did doc .
>
> This creates a race condition. As anyone can create key material and
> register the DID (create method) with a DID resolver. Because DID resolvers
> are decentralized it is up to the did resolver to decide which DID docs to
> cache and which to not and if one wants to make sure one's did doc is
> discoverable one has to register it it widely.  So a malicious party could
> observe the registration of a DID at one resolver change the key material
> in the did: doc and then register the same did but with different did doc
> at  another resolver.  This is just another form of the anyone can
> ledgerize attack. Its the anyone can spoof a did to a given did resolver.
>
>
> Now  one way to stop the spoofing would be to add a ledger as a root of
> trust in the did method where the DID method requires that in order to
> CREATE a did at a resolver the resolver must first find the did on the
> ledger with its did:doc.
>
> But now the DID is not portable across ledgers as the root of trust is
> also the ledger not merely the controller of some private key.
>
> Fundamentally the mix of non-self-certifiability and decentralized control
> is problematic.  It is possible to build a did method on other roots of
> trust besides or in addition to self certifiability but its way more
> complicated.
>
> The main value of a decentralized identifier standard is to enable any
> entity to assert control over a namespace  without dependence on some other
> entity in an interoperable way.  The infrastructure of DIDs DID Documents
> and DID resolvers is to support than value.  But when the infrastructure is
> also decentralized it becomes problematic when there is not a consistent
> root of trust over the whole interoperable infrastructure.
>
>
> When the key material used to verify a did doc is not linked to the did
> itself then anyone can create a did doc for that did and use different key
> material. That is the problem.  When that happens there is no unique
> controller of the DID unless some other root of trust or authority
> specified in the DID method is invoked to determine the unique controller.
>
>
> Because DID specification punts the control of DID methods and DID method
> namespaces to a "market solution" removing self-certifiability opens up
> another lurking problem.   Frankly the market solution  may be the best
> we can do for now.  What this means is that DID resolvers get to decide
> which did methods for which did method names they will support. Different
> resolvers could decide to support a different method for the same method
> name given two different entities that wish to control the same method
> namespace. One hopes that the cost of maintaining a method name space makes
> method name squatting a rarity. One hopes that resolvers will have
> reputations that enable users to pick credible resolvers.
>
> But realistically :)
>
> There is incentive for a malicious entity to  confuse the did method and
> did method name from the standpoint of the user wishing to resolve a did at
> a given resolver.
>
> 1) A malicious attacker could substitute a malicious method into a local
> resolver.
>
> 2)  A universal resolver that allows automatic registration of DID methods
> would be a target for malicious did methods.
>
> 3) A business dispute between partners who have created a method namespace
> where there is no legal basis for who gets to control the method namespace.
> So the partners each spam new resolvers with a different version of the
> method.
>
> BUT in any case if the DID itself is self-certifying then attacks on
> methods at resolvers are limited because the user can always independently
> verify the root of trust in the did doc.  Removing that root of trust just
> opens a can of worms. Putting the root of trust solely  in the DID method
> does not close the can.
>
>
>
>
>