Initial Trust Establishment Specification

[oskarth]

Trust establishment refers to the combination of long-term key exchange and long term key authentication.

This should answer how we establish trust in Status, i.e. between clients, and any other type of trust establishment (like mailservers etc).

See https://github.com/status-im/specs/blob/master/x5.md for current draft.

• If certain things are deemed as out of scope, e.g. ENS usernames, LES, etc then this MAY be excluded from an initial version, assuming it is documented as an Enhancement in the document.

Acceptance criteria

• [ ] Someone can read this and implement a Status client (including links to other specs)
• [ ] They should clarify what security guarantees the protocol(s) provide and don't provide
• [ ] As well as what each protocol/layer requires and provides
• [ ] They should be described as orthogonal pieces, so if someone wants a different transport that should ideally require minimal tweaks to the protocols

In terms of who will judge, it'll be 2-3 main groups initially:

• [ ] Ourselves in protocol group
• [ ] Client implementers (Core, Embark and Nimbus people i.e. status-js and Stratus)
• [ ] Core dev calls participants

Questions a spec should answer

Security properties

Network MitM Prevented Operator MitM Prevented Operator MitM Detected Operator Accountability Key Revocation Possible Privacy Preserving Usability

Automatic Key Initialization Low Key Maintenance Easy Key Discovery Easy Key Recovery In-Band No Shared Secrets Alert-less Key Renewal Immediate Enrollment Inattentive User Resistant Adoptability

Multiple Key Support No Service Provider No Auditing Required No Name Squatting Asynchronous Scalable

Examples

• Opportunistic Encryption
• Key Fingerprint Verification
• Key directory
• Web of trust
• Optional verification
• Blockchain

Relevance

• Conversational keys
• Identity of mailserver
• ENS
• (Later) Blockchain relevance
• (Later) Multiple key support

[oskarth]

I updated this with more specifics @adambabik. It is largely orthogonal to things like our use of Whisper as a transport, PFS feature, etc.

[oskarth]

@corpetty Is this something you would want to take a stab at in terms of getting to a solid draft? Largely based on work we did in Brussels, plus some stuff you've been thinking about lately.

The main gotcha as I see it is to ensure we don't confuse app vs protocol, so we can talk about recommended practices for app (e.g. later on cold keycard authentication, etc) but the focus should be on things that should be true for all clients.

[oskarth]

For context, I don't think this is too fleshed out in the docs by Adam and Andrea in terms of properties we looked at (though it is mentioned briefly), and Adam is off on vacation for a few weeks.

[oskarth]

@corpetty how is this going? I think just minimal basics would be useful, can be timeboxed ~1-2h.

[oskarth]

Largely done; closing as no longer relevant. If we want to do further QA of specs, I suggest we do this through more specific issues.