jmg
/
medashare
1
0
Fork 0
Code Issues 0 Pull Requests 0 Releases 0 Wiki Activity
MetaData Sharing
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
228 Commits
1 Branch
3.3 MiB
 
 
 
 
Branch: main
Branches Tags
${ item.name }
Create branch ${ searchTerm }
from 'main'
${ noResults }
medashare/OBJSIG.md

5.3 KiB
Raw Permalink Blame History

Object Signing

Signing objects is very important. But the other issue is authenticating that the signed object is valid. One issue that is if a key is compromised, it can be used to sign statements that objects in the past are valid. One way to address this situation is to sign the current Merkle DAG that contains all the “produced” objects by that author. The tree structure of a Merkle DAG with selective split locations allow the tree to add additional objects w/o recalculating the entire tree.

This also allows rolling keys more simply, as the new key starts signing the new root, and once verification of the new key has been done, the objects are now authenticated again. When this happens, no old keys need be kept, and it’s encouraged to remove the old keys and only keep one, the current key, for each identity.

As this spec is geared toward JSON encoding, but

Objects: Identity

  • uuid: UUIDv4
  • updated: Date that this object was last updated
  • name: Common name of this identity.
  • email (optional)
  • info
  • tree_hash: Hash of the root of the object tree
  • public_key: A publicKey object as specified in JSF
  • sig: The signature of the object, a signaturecore as defined by JSF.

name: Note that it is recommended to ensure that this is unique among all the identities imported/trusted, and that work is done to present look alike names. Giving an option to rename an Identity locally is highly recommended to make it easier for the user. info: General information text about this identity. tree_hash: The multihash of the root of the object tree. sig: Note that keyId and publicKey should not be included, as the public key used to verify the signature MUST be the publick_key as specified by the public_key property of the Identity object.

ValidIdentity

  • identity: UUIDv4 of the identity.
  • identity_pubkey: The publicKey object, per JSF, of the Identity object being asserted.
  • assertee: UUIDv4 of the identity asserting the validity.
  • assertee_pubkey: The publicKey object, per JSF, of the Identity object being asserted.
  • sig: Signature of the assertion, a signateurecore by JSF.

It is yet to be decided if the ValidIdentity object will be used.

The tree_hash is a multihash. The data refered will be a JSON JCS encoded object or array. If it is an array, then each element of the array will be a multihash refering to an object that validated by the tree. The array MUST on contain unique multihashes, that is the array is the equivalent of a set. The array MUST be sorted, so that a binary search may be used over the array to find if a multihash is present or not. If the data is an object, it will contain a key to help locate the object, with the value being another multihash, refering to either an object or array again. In all cases, the order of objects MUST be: tree_hash -> [ object -> ]* array -> authenticated object. If objects are used, the keys SHALL be based upon the last modified date of the object. The first level MUST be year, then month, then day, then hour, then minute, then second, then milisecond, then microsecond. If the encoded array is longer than 256KiB, it MUST be broken up, and a new level of objects MUST be added.

Note that the contents of the multihash are NOT distributed w/ the Identity object. The entire tree may be very large, and a complete tree is NOT needed to verify a subset of the tree. It is expected that the parts will be hosted via IPFS, or another mechanism allowing the retrival of the data.

Questions:

  • Should ranges be supported for keys? That is, days could be 05-13. Advantages, easier to split nodes. Actually, better will be to use a proper B-tree style structure, where there’s a left node, and then each key has all the values between it and the next node.
  • Use Base64URL or Base32? JSF uses Base64URL though.
  • Should hard limits be enforced on the array length?
  • IPFS has a 1MiB block size limit, and it looks like UnixFS uses a default block size of 256KiB, so something similar should be used. Maybe recommend even smaller, say 8KiB?
  • What should block garbage collection be? That is when a block is no longer in the tree, how long should it be “available” for? This partly depends upon how often the Identity object is published, that is, only push a complete tree when an Identity hash is “published” or fetched publicly.
  • When distributing a set, use the IPFS CAR format? or something else?
  • Should the merkle tree objects be a proper object themselves? That is have their own UUID? If anything, this is more like a UUIDv5 type thing where the object would have a UUIDv5, BUT why use that when hashing the object directly gives the same results? Advantage, the objects can be passed as normal, everyday objects, disadvantage is that there will be more overhead, and cannot use IPFS directly for serving the blocks.

Answered:

  • Should a Rabin fingerprint be used? Other option is to create a n-tree. No, as this needs to be an append (in time) friendly structure, where inserting hashes into a sorted list will be random, causing lots of blocks to be created and unable to be cached.