Re: "anybody can ledgerize" vulnerability

Thanks Sam—you da man.

On Mon, Oct 14, 2019 at 4:41 PM ProSapien Sam Smith <sam@prosapien.com>
wrote:

> 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>
> 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>
>> 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.
>>>
>>>
>>>
>>>
>>>
>
> 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
>
>
>
>
>
>
>
>
>
>
>