Project

General

Profile

Feature #15604

Act on the reviews of our revocation certificate mechanism

Added by sajolida over 1 year ago. Updated 5 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
-
Category:
Infrastructure
Target version:
Start date:
05/16/2018
Due date:
% Done:

0%

Feature Branch:
Type of work:
Contributors documentation
Blueprint:
Starter:
Affected tool:

Description

We received the reviews by email on (<> and <>).

Summary:

  • Consider splitting a designated revocation key instead of a revocation certificate. The benefit would be to have an expiry date on the key, which is not the case with a certificate.
  • Regularly check with the people in the scheme to make sure that the communication channel with them is still working and that they still have the instructions and their share.
  • Update "until we publish a new signing key" in the document as it won't be enough to build again trust within our user base (cf. other possible fake keys on the public key servers).

Related issues

Related to Tails - Feature #10022: Have experts review our revocation mechanism of Tails signing key Resolved 08/14/2015
Blocks Tails - Feature #16665: Update the list of people in groups B, C, and D of our revocation mechanism (2019 edition) In Progress

History

#1 Updated by sajolida over 1 year ago

  • Target version changed from Tails_3.9 to Tails_3.10.1

#2 Updated by sajolida about 1 year ago

  • Target version changed from Tails_3.10.1 to Tails_3.11

#3 Updated by sajolida about 1 year ago

  • Related to Feature #10022: Have experts review our revocation mechanism of Tails signing key added

#4 Updated by sajolida about 1 year ago

  • Target version changed from Tails_3.11 to Tails_3.12

#5 Updated by sajolida 11 months ago

  • Target version changed from Tails_3.12 to Tails_3.13

#6 Updated by sajolida 9 months ago

  • Target version changed from Tails_3.13 to Tails_3.14

#7 Updated by sajolida 8 months ago

Another improvement to add to the mechanism: it's useful to have someone hosting the mailing list being part of group B, C, or D since they can take care of its existence (eg. bypass cleaning polices of non-used mailing lists, etc.)

#8 Updated by CyrilBrulebois 7 months ago

  • Target version changed from Tails_3.14 to Tails_3.15

#9 Updated by sajolida 6 months ago

  • Status changed from Confirmed to Needs Validation
  • Assignee deleted (sajolida)

Please someone review: 29bd9b8986, de97b4cd01, 5f87f8d819, 1a7564b1e6.

@intrigeri maybe? :)

Then I think we're done.

I couldn't find any information regarding revocation keys so I ignored this proposal.

#10 Updated by sajolida 6 months ago

  • Blocks Feature #16665: Update the list of people in groups B, C, and D of our revocation mechanism (2019 edition) added

#11 Updated by intrigeri 6 months ago

  • Assignee set to intrigeri

#12 Updated by intrigeri 6 months ago

  • Description updated (diff)

I couldn't find any information regarding revocation keys so I ignored this proposal.

I've rephrased the ticket description and added pointers to the corresponding doc so it's clearer what this is about. Does it help?

#13 Updated by intrigeri 6 months ago

  • Status changed from Needs Validation to In Progress
  • Assignee changed from intrigeri to sajolida

Please someone review: 29bd9b8986, de97b4cd01,

All right.

5f87f8d819

This seems oddly placed in the middle of "When to use your share": apart of the fact it is somewhat off-topic in this section (I can live with that), the paragraph immediately after the added text ("Yes, there is no […]") was meant as an explanation for the paragraph immediately before it ("If someone in possession […]"), so this addition seems to break the logical flow of explanation.

What about this: we add a "How to use your share" section after "When to use your share" and move this added text there?

1a7564b1e6.

I've added a few commits on top of it to fix some issues. Please review :)

#14 Updated by sajolida 6 months ago

  • Assignee changed from sajolida to intrigeri

Regarding 5f87f8d819, I read again the whole section, and you're right that's it's misplaced. I wrote it because it felt that we were missing some information on what should happen between "someone writes to the mailing list" and "the signing key is revoked". I tried to find a better place for it in 40d31f22e9, otherwise maybe we can remove it.

Regarding 76a4547f93, I thought about that but also got scared about the mailing list not working when people will want to write to it. We actually never tested that this mailing list is working and that everybody would receive its emails. I thought that writing the "update" email to the mailing list was a way of making sure that it works every now and then. But I also understand your fear. Maybe a solution would be to put the mailing list in emergency moderation right after we write to it and until all the members are updated.

#15 Updated by intrigeri 6 months ago

  • Assignee changed from intrigeri to sajolida

Regarding 5f87f8d819, I read again the whole section, and you're right that's it's misplaced. I wrote it because it felt that we were missing some information on what should happen between "someone writes to the mailing list" and "the signing key is revoked". I tried to find a better place for it in 40d31f22e9, otherwise maybe we can remove it.

Good enough!

Regarding 76a4547f93, I thought about that but also got scared about the mailing list not working when people will want to write to it. We actually never tested that this mailing list is working and that everybody would receive its emails. I thought that writing the "update" email to the mailing list was a way of making sure that it works every now and then. But I also understand your fear.

I'm not personally too worried about the list not working: as long as other lists hosted on the same server work, what can possibly go wrong for this one list? (famous last words, I know, I know…)

Maybe a solution would be to put the mailing list in emergency moderation right after we write to it and until all the members are updated.

During that time (it can potentially take a while), the whole scheme would be in a non-working state. I'm not a fan of breaking stuff intentionally as a mean to verify that it would otherwise work :)

I'd be fine with reverting 76a4547f93, triple-checking that the default Reply-To for the list is set to "sender" and not to "the list", trying it out once and seeing if anyone ignores the big fat warning and replies to the list. I'm also fine with keeping things in the post-76a4547f93 state I've put them in. Your call!

#16 Updated by CyrilBrulebois 5 months ago

  • Target version changed from Tails_3.15 to Tails_3.16

#17 Updated by sajolida 5 months ago

  • Status changed from In Progress to Resolved
  • Assignee deleted (sajolida)

Let's keep 76a4547f93 then. I added another step in 94452521aa to check the configuration of the list.

I think we're done here! Hurray!

Also available in: Atom PDF