Skip to content
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

Proposal for storing megolm keys serverside #1219

Closed
benparsons opened this issue May 10, 2018 · 10 comments
Closed

Proposal for storing megolm keys serverside #1219

benparsons opened this issue May 10, 2018 · 10 comments
Labels
disposition-merge e2e feature:e2e-cross-signing kind:core MSC which is critical to the protocol's success merged A proposal whose PR has merged into the spec! proposal A matrix spec change proposal

Comments

@benparsons
Copy link
Member

benparsons commented May 10, 2018

Documentation: #1538
Author: @ara4n, @uhoreg
Date: 23/11/2017

@uhoreg
Copy link
Member

uhoreg commented Aug 13, 2018

The API was designed for option 1, and mostly works for option 2, but it seems like the /room_keys/version API could work better with the PK encryption, and doesn't seem to support the "Verifying the device [new] with an existing device, so the device gets a copy of the recovery-key public key, and can start backing up into the same session" use case.

I think one way to support that is to have the client use the version API to upload the public key for the backup, signed with the device's signing key, along with the device ID. When a new device signs in and wants to back up to that version, then it prompts the user to verify one of the devices that signed the public key. Once the device has been verified, the new device can sign the public key and upload its signature, so that newer devices can check the public key by verifying that device. (Alternatively, we could integrate with the cross-signing data somehow, so that we don't need multiple signatures.)

I think most of this (other than uploading other signatures) can be done with the existing API by changing the contents of the auth_data.

@uhoreg
Copy link
Member

uhoreg commented Sep 10, 2019

@mscbot fcp merge
?

@mscbot
Copy link
Collaborator

mscbot commented Sep 10, 2019

Team member @uhoreg has proposed to merge this. The next step is review by the rest of the tagged people:

No concerns currently listed.

Once at least 75% of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

@mscbot mscbot added proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. disposition-merge labels Sep 10, 2019
@mscbot mscbot added final-comment-period This MSC has entered a final comment period in interest to approval, postpone, or delete in 5 days. and removed proposed-final-comment-period Currently awaiting signoff of a majority of team members in order to enter the final comment period. labels Oct 24, 2019
@mscbot
Copy link
Collaborator

mscbot commented Oct 24, 2019

🔔 This is now entering its final comment period, as per the review above. 🔔

@mscbot
Copy link
Collaborator

mscbot commented Oct 29, 2019

The final comment period, with a disposition to merge, as per the review above, is now complete.

@mscbot mscbot removed the final-comment-period This MSC has entered a final comment period in interest to approval, postpone, or delete in 5 days. label Oct 29, 2019
@turt2live
Copy link
Member

This issue should remain open because it is under the legacy process - we'll close it when the spec PR has been merged.

@turt2live
Copy link
Member

@uhoreg if you have proofs of implementation, please link to them here.

@uhoreg
Copy link
Member

uhoreg commented Oct 29, 2019

Synapse implementation: mainly in matrix-org/synapse#4019, with some bits in matrix-org/synapse#4123, matrix-org/synapse#4580, matrix-org/synapse#6189, and matrix-org/synapse#5858 (the last one needs a bit of tweaking yet)
JS-SDK implementation mainly: in matrix-org/matrix-js-sdk#736 with a bit in matrix-org/matrix-js-sdk#786

@turt2live turt2live added spec-pr-missing Proposal has been implemented and is being used in the wild but hasn't yet been added to the spec and removed finished-final-comment-period labels Oct 29, 2019
@turt2live
Copy link
Member

Spec PR: #2387

@turt2live turt2live added spec-pr-in-review A proposal which has been PR'd against the spec and is in review and removed spec-pr-missing Proposal has been implemented and is being used in the wild but hasn't yet been added to the spec labels Dec 16, 2019
@turt2live turt2live added the kind:core MSC which is critical to the protocol's success label Apr 21, 2020
@uhoreg uhoreg added merged A proposal whose PR has merged into the spec! and removed spec-pr-in-review A proposal which has been PR'd against the spec and is in review labels Jun 2, 2020
@uhoreg
Copy link
Member

uhoreg commented Jun 2, 2020

Merged! 🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
disposition-merge e2e feature:e2e-cross-signing kind:core MSC which is critical to the protocol's success merged A proposal whose PR has merged into the spec! proposal A matrix spec change proposal
Projects
None yet
Development

No branches or pull requests

8 participants