Re: "anybody can ledgerize" vulnerability

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