-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initial Trust Establishment Specification #12
Comments
I updated this with more specifics @adambabik. It is largely orthogonal to things like our use of Whisper as a transport, PFS feature, etc. |
@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. |
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. |
@corpetty how is this going? I think just minimal basics would be useful, can be timeboxed ~1-2h. |
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. |
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.
Acceptance criteria
In terms of who will judge, it'll be 2-3 main groups initially:
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
Relevance
The text was updated successfully, but these errors were encountered: