Re: "anybody can ledgerize" vulnerability

I accept Drummond's nomination.


> On 14 Oct 2019, at 13:16 , =Drummond Reed <drummond.reed@evernym.com> wrote:
> 
> I nominate Sam Smith if he's willing to open the issue because his answers on this thread have been spot on. I believe this issue should not only be in the Security Considerations section of the DID spec, but it's important enough to have its own subsection.
> 
> =Drummond 
> 
> On Mon, Oct 14, 2019 at 10:52 AM Brent Zundel <brent.zundel@evernym.com <mailto:brent.zundel@evernym.com>> wrote:
> 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 <mailto: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:
> 
> Resolving the DID to a DID Document according to its DID method specification.
> 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.
> 
> 
> 
> 


Samuel M. Smith Ph.D.   Founder
smith.sam@prosapien.com 
ProSapien LLC
242 East 600 North, Lindon Utah 84042-1662 USA
Office 1.801.768-2769
Mobile 1.801.592.8230
Skype: samuelmsmith
http://www.prosapien.com/ 

NOTICE: This electronic mail message, together with any attachments contains information
that may be copyrighted, confidential, proprietary, and/or legally privileged of and/or by 
ProSapien LLC. This  electronic mail message is intended solely for the use of
the individual or entity originally named as the intended recipient. If you are not the intended
recipient, and have received this message in error, please return immediately this message