Re: "anybody can ledgerize" vulnerability

> On 18 Sep 2019, at 19:17 , Orie Steele <orie@transmute.industries> wrote:
> 
> I agree with pretty much everything you have said. (Yes to your first question, with quibbles about the definition of valid).
> 
> I'm not familiar with KERI, but it sounds like the method implementers have separated the construction of the DID from the construction/registration of the DID Document, I don't see any issue with that, as long as they have documented their DID Method sufficient for an implementation, and debate about its security.

Yes it does separate the two. The goal of KERI is  DID method independence so KERI core is meant to exist at a lower level  that can  be leveraged by any DID Method.  The goal of KERI is to formulate  best practices for decentralized key management infrastructure that can be applied universally.

> 
> I agree that when the identifier is not self-certifying, the root of trust is different. But the devil is still in the details of the method implementation, and thats why the rubric is important.

Agreed !

> 
> If I write a smart contract that enables a user to claim a DID of the form did:eth-vanity:google, I am not registering a self-certifying identifier, but I still may have created a valid DID Method. The rubric is how we should argue about the security issues arising from that construction (centralization as you pointed out) ... same thing applies to GitHub DID, anyone can squat on a DID by creating github organizations.

Yes entirely possible. My concern is that proposers of non-self-certifying DID schemes were not evaluating appropriate security rubrics and so to illustrate my point I brought up a couple of vulnerabilities that easily happen without self-certification but in an environment of decentralization.

> 
> "Ledgers may never authorize the inception event of a self-certifying identifier."
> 
> I'm not sure exactly what you mean by this, but i suspect you mean that it does not matter if anyone has ever used an ethereum address, it is still a valid self certifying identifier, in which case I agree... but, you can also make a DID Method that only considers a self-certifying identifier to be a valid DID IF a ledger transaction exists, and you can also make a DID Method that considers a DID to be valid if it is a deterministic function of a did document that is signed by a key listed in the DID Document with this data content addressed and anchored to a ledger... The fact that the ledger is needed for the identifier to be verifiably self-certifying may not equate to authorization, but its clearly more significant than a simple public key transformation. 

Maybe my statement is too extreme but the point I was trying to make is that by definition a self-certifying identifier's inception happens before a ledger can see it (approve or authorize it). So not requiring authorization from the private key and substituting authorization from the ledger is too late. Requiring both is ok if that fits your use case better. I agree that one can add additional restrictions on the authorized use of an identifier.  One can always add additional roots of trust such as ledgers that then must provide additional authorizations.  My concern is not additional roots of trust but attempting to substitute a different root of trust as in "instead of"  not "in addition too".  

Moreover, for private relationships self-certifying identifiers may be used without ever touching a ledger.  They are sufficient in and of themselves and thereby not using a ledger enhances privacy preservation.  So I feel like some believe that they can't have both privacy and security because they need a ledger for security and my response is that you don't necessarily need a ledger for security so you can have more privacy if you want it.


> 
> My understanding of Veres One and Sidetree is that we take very similar approaches in this regard, but I would guess that one difference is that Sidetree may include service endpoints, and other non key related material as well, so I can use the same key to create unique DIDs by altering initial values of serviceEndpoints in the DID Document.
> 
> I guess my question is: At what point is the derivation of a DID so complicated that the identifier looses its self-certifying behavior, or is it acceptable for it to be arbitrarily complicated so long as the protocol is cryptographically verifiable.

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

I think my point is now well taken that a self-certifying identifier (namespace) does not need any additional root of trust. It seemed to me that many believed erroneously that a ledger or some other infrastructure was required in order for an identifier to have a cryptographically verifiable root of trust or conversely that naively using a ledger without self-certifiability was sufficient in a decentralized application.


Good discussion.

Sam


> 
> Thanks for your thoughts.
> 
> OS
> 
> On Wed, Sep 18, 2019 at 12:37 PM ProSapien Sam Smith <sam@prosapien.com <mailto:sam@prosapien.com>> wrote:
> Ori,
> 
> Just to clarify what you are saying.  When you say "(we need to ignore DID create operations which are not self certifying, if the DID is not a function of the controller public key like ETHR for example)." Do you mean: Valid DID methods should not allow DID creation unless the DID is self certifying?
> 
> If so then I agree with you in general. But I think it would be helpful  separate out  two sets of events. It is conflating these events that is often a cause for confusion. The two sets of events are inception and later management events. At inception creation, origination, designation, and delegation may occur that authorize other mechanisms for the later management events but the only authority that exists at inception is the controller of the private key from the public private key pair whose public key is included in the identifier.
> 
> To clarify, the root of trust for the origination of a self-certifying identifier is  the entropy in the seed coupled with the cypher-suite digital signature scheme that generates the public-private key pair. No other authority is ever needed.  The identifier is thereby self-authenticating by virtue of the fact that this collision resistant public key is included in the identifier.  To elaborate, a public key itself is a self-certifying identifier but we really want to create self-certifying extensible namespaces so we embed the public key as a prefix in the namespace identifier thereby making the namespace self-certifying (aka a DID).   Even mentioning a ledger in this origination context is confusing as it does not play a role at this stage.  It is completely unnecessary. All the authority comes from the collision resistance of the entropy in the seed.  If I can create a public private key pair with sufficient collision resistance and then embed the public key in a namespace identifier and thereby assert control of the namespace via a verifiable signature with the associated private key and no once else can make verifiable signatures then I am the sole ruler (sovereign) of that namespace!!!  No other authority is involved or needed!  (This assumes agreement knowledge of the cypher suites with sufficient collision resistance for the given public key. To be fully self-contained a self-certifying identifier must include the cypher-suite or only be used in a context where the cypher-suite is known.
> 
> Nonetheless, I may want to make my namespace extensible. I may want to be able to recover from later loss or exploit of the private key or better protect my namespace by using multi-sig.  I need some mechanism for extensibility and a secure method for designating that extensibility mechanism. It is after origination  that things like ledgers and DID Docs come into play to support this extensibility. I may delegate some of my authority over my namespace to some extensibility mechanism. The earliest this delegation may happen is in the inception event. Its the first event after creation of the public/private key pair whose public key is embedded in the namespace identifier. Extensibility may include a mechanism for future management events on the identifier such as rotation from the originating private key to some other set of private keys. As no other authority yet exists at the time of inception, the inception event may be solely authorized by the originating private key.   The most secure way to do this inception origination designation is to only use the private key once and only once at inception. In this case the private key in the originating public/private key pair is a one time use key.  
> 
> One way to designate extensibility in the inception event is to designate the contents of the DID Doc. In this case the origination of the DID Doc is authorized in the inception event. But it does not have to be in the inception event.  The did doc could be authorized in a later event after the inception event. This is the case In KERI.  The inception event in KERI may designate a pre-rotation to multi-sig set of keys. An immediately successive linked  or combined rotation event would then activate those keys. At this point then the newly designated must-sig keys could be used to more securely authorize a DID-Doc creation that would be verifiable by including the key event history (inception and rotation) up to that point and the cypher suite in the DID-Doc and attaching the multi signatures. Further extensibility designations could be made including designating infrastructure such as a ledger to maintain the key event history or rotating to other keys or cypher suites.  The DID Doc, however is only useful or valid  or authoritative for events that occur after the inception event. These events are part of the second group of events I called management events. Likewise Ledgers may only be authoritative in this second set of events but never in the inception event.
> 
> To restate, ledgerization is a form of designation/delegation and must always occurs after creation of the public/private key pair and the identifier. Ledgerization may occur as part of the inception event which is authorized by the private key signature but not sooner. Ledgers may never authorize the inception event of a self-certifying identifier. When ledgerization occurs later than  inception then it may be authorized by some other set of keys that are in the key event history but are  provenanced to the inception event.  To restate ledgerization must be authorized by provenanced key(s) originating with the original private key otherwise it is not based on the same root of trust. 
> 
> When the identifier is not self-certifying  then the root of trust is different.  The association between the identifier and the controlling public/private key pair(s) must be derived from some other source of authority besides the entropy in the public/private key pair generation and this opens a can of worms. The root of trust and hence security of such as system is now based on the security of the other source of authority whatever that may be. And must be analyzed from that perspective. In general proposers of non self-certifying identifiers have not provided such analysis as part of their proposals. This is the source of my extreme concern on this matter.
> 
> 
> 
> 
> 
>> On 17 Sep 2019, at 17:01 , Orie Steele <orie@transmute.industries <mailto:orie@transmute.industries>> wrote:
>> 
>> This sort of thing also has migration implications. Consider wanting to move from one DID Method to another, or from one ledger to another.
>> 
>> In the case of Sidetree bases DID Methods, the DID is a function of the initial DDO and a valid signature of that DDO from a key listed in it, as you have mentioned.
>> 
>> The validation occurs on the read side, because there is no write side protection for public ledgers (censorship resistance).
>> 
>> I'm not exactly sure what you mean by signing the DID Doc, but generally:
>> 
>> https://w3c-ccg.github.io/did-spec/#proving-control-of-a-did-and-did-document <https://w3c-ccg.github.io/did-spec/#proving-control-of-a-did-and-did-document>
>> 
>> The DID Method resolution is what actually enforces the linkage between the identifier and the document.
>> 
>> I usually think of the DID as a special case of public key thumbprint, that points to multiple keys (the DDO), and both the identifier and keys are all public information.
>> 
>> There are at least 2 signatures we are talking about here:
>> 
>> 1. The ledger signature (used to sign the public ledger transaction)
>> 2. The DID create operation signature (used to show that at least one of the keys in the create payload is under the control of the registering entity).
>> 
>> 1 is protected by the ledger (needs to come from a funded address, but may have nothing to do with the actual DID, see BTRC, ETHR vs ION, ELEM).
>> 2 is protected on the read side by the DID Method (we need to ignore DID create operations which are not self certifying, if the DID is not a function of the controller public key like ETHR for example).
>> 
>> I don't think there is anything wrong with a DID Method that allows for creating of a DID Doc with more than one key, but only requires a signature from one of the keys, after all I can always claim to control another person's public key, the problem is when that claim is true and they don't know about it.
>> 
>> It would generally be good opsec to scan all public ledger based methods for activity related to keys you believe you exclusively control, or are interested in monitoring on behalf of someone.
>> 
>> For centralized DID methods, private ledgers, pairwise unique DIDs or ephemeral DIDs, the same principle holds, its just you have less ability to actually monitor activity regarding keys, and therefore its even more important that the DID Method be carefully implemented to support the self certifying property, because you may not be able to see that someone is attempting to pivot from a troll to an attacker.
>> 
>> I agree that this kind of thing belongs in the rubric its entirely up to the DID Method implementer to ensure that at least one of the keys registered to a new DID Doc is used when the DID is created.
>> 
>> Thanks for raising this issue.
>> 
>> OS
>> 
>> 
>> On Tue, Sep 17, 2019 at 5:05 PM Daniel Hardman <daniel.hardman@evernym.com <mailto:daniel.hardman@evernym.com>> wrote:
>> Sam Smith and I have been discussing an issue that I wanted to bring to this group. It is a risk that Sam has described as the "anybody can ledgerize" problem: What is to prevent someone other than the owner of a DID from recording the initial version of a DID doc on a ledger, thus making public something that the owner intended to keep off ledger permanently or temporarily?
>> 
>> Even though this question is framed in terms of ledgers, it has direct application to non-ledger DID methods as well.
>> 
>> I believe that some DID methods allow anyone with write permission or willing to pay transaction fees to write a DID and its initial DID Doc to the shared source of truth. Since the DID doc just contains public keys, all the info in it might be known by someone other than the DID's owner -- another party in the list of controllers, for example, or even an adversary. Yes, the adversary possesses none of the private keys, and so cannot control the DID after registration--but the mere registration of someone else's data under circumstances of an attacker's choosing could, in and of itself, constitute mischief.
>> 
>> To guard against abuse, the correct behavior of a ledger is probably to require that the request to write the genesis version of the DID doc be signed by a key in the DID doc. Note that just signing the DID doc isn't enough, since the attacker could have captured the signature when he captured the DID doc content. Even better security would be to require that the DID value be *derived* from a key in the DID doc, and that the initial write request use that key as well. @Joe Andrieu <mailto:joe@legreq.com> perhaps this protection against abuse needs to be a rubric? Or perhaps it is more fundamental, and needs to be a requirement of all DID methods, period?
>> 
>> 
>> -- 
>> ORIE STEELE
>> Chief Technology Officer
>> www.transmute.industries <http://www.transmute.industries/>
>> 
>>  <https://www.transmute.industries/>
> 
> 
> 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
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> -- 
> ORIE STEELE
> Chief Technology Officer
> www.transmute.industries
> 
>  <https://www.transmute.industries/>


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