Re: "anybody can ledgerize" vulnerability

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.


[photo]
Lucas Tétreault
VP Research & Development
300A - 2221 Cornwall Street
Regina, SK. S4P 2L1
(306) 541-311<tel:(306)%20541-3116>5    ・       [vivvo] <http://www.vivvo.com/>         ・       [github] <https://github.com/lucastetreault>    [linkedIn] <https://www.linkedin.com/in/lucas-t%C3%A9treault>   [twitter] <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/


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

Received on Wednesday, 18 September 2019 17:03:22 UTC