[solved] How to verify that <cid> is signed by <peerid>?

Ecosystem
27

I don’t see a problem there.
The peer id is the users’ public key.
I trust “that peer id”.
The user creates whatever data and signs it with it’s private key. I can verify that sign with the public key (the peer id) as i’ve demonstrated in this post.

I can apply this concept now to IPNS keys (in the 0.7.0 scheme that is) and to any ipfs data where a public key and a sign is known to verify that i want that data. Now how to do that last part is up for debate as i’d need to make a format, say like:

{
  "pubkey" : "peer id or some other public key mechanism",
  "sign": "%$@#TGE#%YHH%#YHYT$R^",
  "contentHash": "Qm....."
}

I can then verify that the Qm..... is in fact signed by that public key (as you need the private key to sign it and only you should have that private key). Still, this only means that i trust whatever that given public key + sign tells me. In this scheme anyone can sign any Qm… hash. It’s just that i trust those that are signed with publickeys that i trust.

With that logic i’m able to confirm that <cid> is valid for me, provided that the user provided me that above json blob to be able to verify it. If the user were to send a IPNS in 0.7.0 format then the public key can be omitted as it’s part of the content hash.

Now it would be super awesome if the sign would be part of the content hash itself! Something like:
<cid><sign> = <newcid>
As it would then contain:

  1. public key
  2. sign of the content hash with the private key of that public key
  3. the content hash

It would solve everything i mentioned here.
It would allow verification with only <newcid>.

The downside is that this will explode the <newcid> in length to unusable long.
But i think this mechanism with the json blob above as “metadata” would be very workable already! Anything more that simplifies it further is just a big bonus :slight_smile:

With that, i’m making this thread as solved.