-
Notifications
You must be signed in to change notification settings - Fork 38
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
Shamir deletion specification - server side #7609
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A couple of comments but LGTM otherwise 👍
@touilleMan should review and validate this before it's merged
f29d3c2
to
2f9f3a2
Compare
"type": "DateTime" | ||
}, | ||
{ | ||
"name": "previous_timestamp", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I find previous_timestamp
not clear enough, as it may refer to the previous timestamp in the shamir topic (which is itself different for each user), for instance:
- Alice creates shamir for herself with Bob as recipient
- Bob creates shamir for himself with Mallory as recipient
- Alice delete her shamir
In this case, Alice's shamir topic contains certificates from steps 1 and 3, while Bob's shamir topic contains certificates from steps 1, 2 and 3 (hence it is weird for Bob that certificate from step 3's previous_timestamp
field refers to certificate from step 1...)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On top of that, I think a user_id
field is missing: this field has been added to shamir brief/share certificates now that author
field doesn't contains the user ID (as DeviceID and UserID are now both UUID).
In theory author's user ID can be retrieved from fetching the author's device certificate, however this is cumbersome given in the certificate storage we want to index the certificate by the author user ID (given it is the discriminant in the shamir topic) but the code requires that all indexed data are within the certificate (and changing this code is just not worth the complexity)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, to summarize both previous points, I think we should have:
{
// User here must be the one owning the device used as author
// (i.e. a user can only remove its own Shamir recovery)
"name": "to_delete_setup_user_id",
"type": "UserID"
},
{
// User ID + timestamp is enough to uniquely identify a Shamir recovery
"name": "to_delete_setup_timestamp",
"type": "DateTime"
},
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
// (i.e. a user can only remove its own Shamir recovery)
And that means if we want a configuration where only admins can delete shamir certificates, it should be quite easy
4 | ||
], | ||
"req": { | ||
"cmd": "shamir_recovery_deletion", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"cmd": "shamir_recovery_deletion", | |
"cmd": "shamir_recovery_delete_setup", |
The command name should contain a verb
(btw I guess shamir_recovery_setup
is a bit weird on this regard given setup
is both the verb and the noun, since after that we refer to the configuration set by this command as the shamir setup
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe shamir_recovery_setup_setup
?
4cb8a65
to
65b2b27
Compare
}, | ||
{ | ||
// Share recipients lists are incoherent | ||
"status": "incoherent_date" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Share recipients are the only not identifying data that we have in the deletion certificate to check. Maybe we could include more data from the brief to ensure coherence. I'm not sure how much it's needed though
219f500
to
7bd5353
Compare
Related #7364