Re: "anybody can ledgerize" vulnerability

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.

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.

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.

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

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.

Thanks for your thoughts.

OS

On Wed, Sep 18, 2019 at 12:37 PM ProSapien Sam Smith <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> 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
>
> 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>
> 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 <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
>
>
>
>
>
>
>
>
>
>
>

-- 
*ORIE STEELE*
Chief Technology Officer
www.transmute.industries

<https://www.transmute.industries>