Re: "anybody can ledgerize" vulnerability

Lucas,

The problem is that non-self-certifying identifiers are vulnerable to exploit because anyone can create key material for these identifiers as a result of the fact that the identifier is not linked to the key material by definition.  This means non self-certifying identifiers require some other root of trust for authorizing actions on the identifier. But this lack of well defined root of trust is a security vulnerability that must be analyzed. This decoupling of the identifier from the key material that authorizes its use may induce race conditions that are avenues of exploit.


Ledgerization is merely one such activity that may be unauthorized and makes a somewhat private identifier less private.   Suppose someone creates an identifier and they don't want it to be on the ledger. How do they prevent someone else from publicizing the identifier? They can't.  When the identifier is not self certifying then anyone can create key material for the identifier and immutably publicize it by being the first to put it on the ledger.  Not all identifiers are meant to be on ledgers.

A related problem is name squatting. Human friendly identifiers are not self-certifying but may be rare and valuable.  This means the DID method has to figure out how to prevent name squatting which may not be trivial.  So for example who gets to decide to publish a human friendly DID to a ledger. Is it the first one to register it now controls it because they created the key material. 


> On 18 Sep 2019, at 10:48 , Lucas Tétreault <lucas@vivvo.com> wrote:
> 
> I don't really understand what the vulnerability is to be honest... If it's a DID document that should be on a ledger, then it will have been published to the ledger before being shared. If it's a pairwise DID / DID document then presumably the DID indicates as much e.g.: did:peer:... vs. did:v1:... Or is that not something people are doing in practice? 
> 
> I think that the DID being derived from key material is an interesting property for DIDs that are not rooted in a blockchain but I don't really see that as necessary for all DID methods.
> 
>   
> Lucas Tétreault
> VP Research & Development
> 300A - 2221 Cornwall Street
> Regina, SK. S4P 2L1
> (306) 541-311 <tel:(306) 541-3116>5 ・  <http://www.vivvo.com/> ・  <https://github.com/lucastetreault>  <https://www.linkedin.com/in/lucas-t%C3%A9treault>  <https://twitter.com/ltetreault>
> From: ProSapien Sam Smith <sam@prosapien.com>
> Sent: September 18, 2019 10:13 AM
> To: Dave Longley <dlongley@digitalbazaar.com>
> Cc: Daniel Hardman <daniel.hardman@evernym.com>; W3C Credentials CG (Public List) <public-credentials@w3.org>
> Subject: Re: "anybody can ledgerize" vulnerability
>  
> A self-certifying identifier implies that the identifier is self-authenticating in that it includes the key material needed to authenticate itself (by virtue of the key material in the identifier) and then  the creator of the identifier may authorize via a signature with the associated private key  some action on that identifier such as creating a did doc. 
> 
> It appears that Veres One is self-certifying by including unique key material in the identifier and then requiring verification using that same key material before accepting the DID Doc. The is essentially the correct behavior. 
> 
> The act of not including the key material in the identifier itself removes the self-authentication feature. This lack is the source of the problem and exposes the vulnerability.  Eliminating self-authentication means that some other authority must authenticate the origination or inception event on the identifier. This can be a ledger but that means that the origination event or registration event on the ledger can be performed by anyone because the identifier is not uniquely bound to the key material used to register it. This creates a race condition (first to register) and allows someone to register or ledgerize the identifier unauthorized.  This is problem for private identifiers where the originator does not want the identifier ledgerized and therefore never registers it thereby opening the opportunity for someone else to ledgerize it. 
> 
> Requiring an external authority to authenticate identifiers in order to authorize actions of the identifier is inherently more centralized and opens a can of worms.  It matters not that the external authority is a permission-less ledger the identifier is still not self-authenticating.
> 
> 
> 
>> 
>> 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.
>> 
>> 
>> -- 
>> Dave Longley
>> CTO
>> Digital Bazaar, Inc.
> 
> 
> Samuel M. Smith Ph.D.   Founder
> smith.sam@prosapien.com <mailto: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/ <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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 


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