Consider adding "Actors" and the ability to rotate keys

[iamcarbon]

Identifying all actors by their public key prevents an actor from rotating or revoking their key. By pointing owners to a versioned actor record, the system could support rotating and revoking keys.

A trusted ledger of key revocations could also be used to prove whether a record signed at a point in time was valid.

By establishing a set of trusted actors, a key recovery method could be introduced that allows trusted actors to commit a key rotation transaction through a cryptographically verified quorum.

Perhaps one of these actors is a friend. A T2 chip. Or FIDO key.

[iamcarbon]

A potential Schema.

Actor record { 
   id: UUID
}

// Actors include
Person : Actor record { }
Service : Actor record { }
Organization : Actor record { }

Actor::Key_reset_policy record {
    quorum: Integer, // The number of trustees that must agree to let the actor reset their key
    trustees: [ ] Trustee
} 

// A trustline establishes trust between two parties (or keys) for a specific purpose.
// 1. To assert our identity (that we control our current private key) 
// 2. That the trustee hold an asset on our behalf and will provide it on demand
// By trusting a actor, we inherently trust their currently active key (which may be rotated frequently)

Trustee ≡ Actor | Key

Trustline record { 
   truster: Actor,  
   trustee: Trustee,   
   acting_as: Verifier of Identity | Holder of Asset
   expires?: Timestamp
}

Controller ≡ Actor | Key

// A record records data about an object (and represents an object at a point in time)
Record class { 
   uuid           : UUID,
   object        : Object, 
   hash           : [ ] byte,
   data            : [ ],  // the object's schema should define the serialization format of the data 
   transaction : Transaction
}

// The entity or service controlling an object isn't always it's owner
// An owner may delegate control, reassert control, or transfer ownership of an object through a transaction
// Ownership of an object may change over time
// An object may also represent a physical or virtual asset with varying quantities
// Records record the changes of an object over time

Object class {
   uuid          : UUID,
   record      : Record, // Current record representing the object's data
   controller : Controller
}

// Rather then signing individual records, consider signing the transactions used to commit the record. The transactions could have multiple parties.

Ownership record { 
  object: Object,
  owner: Actor | Key,
  timestamp : Timestamp, // when the ownership began
  disposed?: Timestamp // when the ownership ended (through sale, forfeiture, end of life, etc)
}

Cryptography::Key record { 
  uuid: UUID, 
  type: Cryptography::Algorithm,
  revocation?: Cryptography::Key::Revocation,
  expires?: Timestamp,
  controller: Actor
}

// A key may perform any action on behalf of it's controller that does not violate a system policy or protocol

Cryptography::Key::Revocation {
    transaction: Transaction, // the transaction used to revoke the key
    reason: Rotated | Compromised,
    timestamp: Timestamp
}

// We may also want to include additional authenticated data to allow additional data to be verified (e.g. roughtime)

Signature record { 
   key     : Cryptography::Key, 
   aad?   : any,
   value  : [ ] byte,
   timestamp : Timestamp
} 

Transaction record {
    uuid: UUID,
    signatures: [ ] Signature,
    committed: Timestamp
}

[danielcrenna]

@iamcarbon

I like this idea.

One consideration on the revocation is that I don't think I could legitimately assert that a key was revoked prior to an actor committing a transaction. The revocation list itself would have to have quorum, and then you might have a situation where you can prevent a revocation from "taking" by upsetting that state.

[iamcarbon]

Yeah. There's some tricky timing & coordination issues in this proposal. And agree that a hard assertion would compromise availability. This could be done more lazily by trusting a third parties (e.g. https://blog.cloudflare.com/roughtime/) to validate when things happened -- and allow the system to retroactively react when learning of key revocations. It may be reasonable to add a new flag state to records (RecordFlags = Invalidated). This may also be infeasible with an append only log (if the space cannot be reserved and updated in-place). It's possible that we may also still need to modify the log reactively to react to privacy and legal concerns as well.

[danielcrenna]

I'm not against the idea of a mutable log, but it complicates several replication scenarios and removes "free" data provenance features.

I think the existing implementation needs to reach a further milestone before we black-boarding data removal.

Worth pointing out that there are no crypto-economics at play here, so nothing prevents running a private instance where exposing sensitive data becomes a network concern.

Are there ready examples of the need to delete data legally outside of GDPR or is that your primary concern?

[iamcarbon]

Agreed that this is a non-inniment-concern for private instances and small syndications that inherently trust each other and communicate peer to peer.

My future brain is leaping ahead where instances can form a network — and share information and “things” with one another — where the possibility of trust bring compromised - either by a malicious actor or a system a CSV / zero day — becomes inevitable.

By supporting the right to be forgotten / GDPR, CCAP and DMCA, the system would also allow public providers to participate and establish themselves as trust anchors.

I also believe that it remains possible to achieve GDPR and CCAP compliance without loosing data provenance - by keeping the records tombstone (soft delete marker) along with the records hash - while destroying the records data. Loosing the records DEK is also a solution.

But yes, future problem!!!

Sent from my iPhone

On Mar 6, 2021, at 7:18 PM, Daniel notifications@github.com wrote:  I'm not against the idea of a mutable log, but it complicates several replication scenarios and removes "free" data provenance features.

I think the existing implementation needs to reach a further milestone before we black-boarding data removal.

Worth pointing out that there are no crypto-economics at play here, so nothing prevents running a private instance where exposing sensitive data becomes a network concern.

Are there ready examples of the need to delete data legally outside of GDPR or is that your primary concern?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or unsubscribe.