Re: "anybody can ledgerize" vulnerability

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>