Re: "anybody can ledgerize" vulnerability

"omeone may choose to add (not replace) additional roots of trust to the
use of the self-certifying identifier thereby encumbering but not removing
its self-certifiability.  But as long as they do the analysis to ensure
cryptographic security etc it may be just fine.  That encumbrance however
may be less secure as it sometimes the case when adding layers to
cryptographic systems so care must be taken.  (see Schneier).  "

We have too many root certificate authorities for SSL. SSL is now only a
minor guarantee that the attacker needs infrastructure access to read the
traffic. It can no longer certify domains. Schneider's comments were
accurate for his era, but we let things slide too far. The "encrypt
everything" was a good stance against the NSA, but we let the permission of
who was allowed to declare the encryption keys become too populated. If I
sound alarmist, it is because I have looked into the implications of utf8
domain names.

The problem being discussed here hasn't been heard by most respondents,
although I only read about 90% of the thread. The math does not protect the
integrity of the data, it only protects the payload. Garbage in, garbage
out, even if you encrypt the garbage. When anyone can encrypt garbage, we
end up with the "anyone can ledgerize" vulnerability.

There are no trustable trustless versions of identity. Even public key
signing groups among peers became suspect due to key signing parties.
Having government sponsorship for trusted identity may imply trusting all
government who participate. (And some are less informed than others, even
if they were honest.)

I think this discussion is a symptom of collective issues. I would like to
participate in a conference call but I am typically double booked, or I
free my calendar and then it is canceled. We need a focused group for this
I think.

On Mon, Oct 14, 2019, 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.
>>
>>
>>
>>
>>