add some e2ee clarifications #1294
Conversation
There was a problem hiding this comment.
What's there looks mostly good, but I have a few suggestions.
Also, in relation to #1275, I don't think this PR addresses these points:
- The implementation should first check whether a given key ID is a MSK (referring to a cross-signing user identity), and only then check whether it matches a device.
- Specify what it means for a device to be trusted
Did I just miss it?
|
Looks sensible & like useful clarifications to me. đź‘Ť |
dbkr
left a comment
dbkr
left a comment
There was a problem hiding this comment.
(Not approving yet since Denis has outstanding comments)
Co-authored-by: Denis Kasak <[email protected]>
Since we mean "verified" when we say "trusted", maybe we should just say "verified" instead? Especially since we use "trusted" in other contexts to mean something else. |
dkasak
left a comment
dkasak
left a comment
There was a problem hiding this comment.
I left a final comment that needs addressing before merging, but otherwise this looks good to me.
The final comment concerns the goal of ending up not being vulnerable to key confusion bugs, which means we either have to flat out refuse to proceed in case of key ID collisions or we have to guarantee a consistent key checking order. I think I prefer flat out refusing, because it's simpler, unless you see a problem with it.
Once either suggestion is merged, I'm considering this good for merging.
Co-authored-by: Denis Kasak <[email protected]>
3 participants
fixes #1275
fixes #1313
Preview: https://pr1294--matrix-spec-previews.netlify.app