Commit abdce6a4 authored by intrigeri's avatar intrigeri
Browse files

Merge remote-tracking branch 'origin/doc/11751-signing-key-revocation'

Closes: #11751
parents 24b2d87f 85df48c1
......@@ -108,6 +108,8 @@ systems managed by anyone other than Tails core developers.
packages, public keys, and so on from the outside world.
* Expires in less than one year. We will extend its validity as many
times as we find reasonable.
* Has a revocation certificate split amongst different people.
See the [[details of the mechanism|signing_key_revocation]].
### Signing subkeys
[[!meta title="Revocation of the Tails signing key"]]
This document proposes a mechanism for the distribution and activation of
the revocation certificate of the Tails signing key.
Covered by current proposal:
A. Prevent any single individual from revoking our signing key.
B. Allow a coalition of people from to revoke our signing key
in case most of the people from become unavailable.
C. Allow a coalition of people, not necessarily from, to
revoke our signing key in case everybody or almost everybody from becomes unavailable.
D. Make it hard for a coalition of people not from to revoke
our signing key unless everybody or almost everybody from
becomes unavailable.
E. People not from shouldn't know how the shares are spread
and who has them.
F. People in possession of a share of the signing key should have
instructions on how to use it if needed.
We define four complementary groups of trusted people:
- Group A: people from themselves
- Group B
- Group C
- Group D
All these people should have an OpenPGP key and understand what
a revocation certificate is.
Cryptographic shares
We generate a revocation certificate of the signing key and split it
into a number of cryptographic shares, using for example Shamir's secret
sharing scheme implemented by `gfshare`.
The following combinations of people could get together and reassemble their
shares to reconstruct a complete revocation certificate:
- Three people from A{3}
- Two people from and one person not from A{2}+(B|C|D)
- One person from, and two people not from but from two different groups: A+(B|C|D){2}
- Three people not from but from three different groups: (B+C+D){3}
We generate these shares:
- N shares, one for each person from
- 1 share for people in group B
- 1 share for people in group C
- 1 share for people in group D
Who knows what
- People from know the composition of each group
- People not from
- Are explained in which circumstances they should revoke the signing key
- Are told to write to a certain contact email address if they decide to revoke the signing key
- Are told that they need three different shares to reassemble the revocation certificate
- Everybody who owns a share is subscribed to a mailing list.
- This mailing list is hosted on a trusted server different from to
be more resilient than our usual communication channels.
Changing the members of the groups B, C, or D
To add someone to a given group:
- Request someone from that group to send her share to the new
person in the group.
To remove someone from a given group:
- Send new shares to everybody except to the person who is being removed.
- Request everybody to delete their previous share and track this.
Once everybody in 2 groups amongst B, C, or D have deleted their share, it becomes
impossible for them to reassemble the revocation certificate with the previous
set of shares.
- Let's hope that this doesn't happen very often :)
There is no expiry date on revocation certificates. One way of
cancelling the revocation power is to destroy all copies of shares of 2
groups amongst B, C, or D.
Email to members of the groups
Subject: distribution
We want to propose you to be part of a distributed mechanism for the
revocation certificate of the Tails signing key.
The idea is to distribute cryptographic shares of this revocation
certificate to people that we trust. These cryptographic shares can be
put together to reassemble the revocation certificate and revoke the
Tails signing key. This may be needed in case something really bad
happens to us and we are not able to do the revocation ourselves.
Note: In all this document, 'us' refers to the set of people subscribed
to which is a Schleuder mailing list.
You can read a complete description of the distribution mechanism on The recipe is
public and the only secret component is the list of people who are in
possession of the cryptographic material.
We are proposing this to you because we trust in both your technical
abilities to store your share in a safe place and manipulate it as
required but also because we trust in you as a human being to make
informed judgement on when to use your share and act only in the
interest of Tails.
The bad things that could happen if the mechanism fails are:
A. The signing key is not revoked while it should be. This could allow
possible attackers to distribute malicious Tails ISO images or publish
malicious information on our name.
B. The signing key is revoked when it should not have been. This would
prevent people from verifying our ISO images with OpenPGP until we
publish a new signing key.
Distribution of the shares
Each person from, group A, has a *different* share, A1,
A2, ..., An.
On top of this, we defined three complementary groups, B, C, and D of
trusted people who have a close relationship with Tails but different
interests and different access to information about us. You are part of
one of these groups.
Everybody in group B has an *identical* share B.
Everybody in group C has an *identical* share C.
Everybody in group D has an *identical* share D.
Three different shares are need to reassemble the revocation
certificate. For example, shares A1, A2, and A3, or shares A1, B, and C.
How to store your share
Please keep your share in an encrypted storage and make it as hard as
you can for untrusted people to get a copy of it.
You also need to store the number in the file name of your share as it
is needed to use the share. Other than that, you can rename the file.
Feel free to back up the file but we might also request you to delete it
at some point and you should be able to know whether you still have a
copy of it or not. It is all-right to lose your share as long as you
tell us that you have lost it. It is actually worse to still have a copy
of the share "somewhere" while thinking that you have none, than to lose
it by mistake.
Don't hesitate to ask us if you need clarification on the technical
aspects of this.
When to use your share
Everybody in possession of a share is subscribed to a mailing list:
If someone in possession of a share gets to learn about a very bad event
that happened to many of us and really thinks that we are not capable of
revoking the Tails signing key ourselves anymore, then this person
should write to the mailing list explaining why she thinks that the
signing key needs to be revoked.
Yes, there is no mathematically proven algorithm for this and here is
where your judgement as a human being is needed. The description of the
very bad event should be checked or backed by enough people to be
Keep in mind that we could still revoke the signing key ourselves as
long as three of us are able to communicate and gather their shares. So
we only need your help if only two of us are still able to communicate.
Unless you really want to start the key revocation process, do not write
to this mailing list.
Further communications
In case we need to communicate with you about this revocation mechanism
in the future, we will always do it with messages signed by the Tails
signing key itself. We might do so for example to:
- Ask you to send your share to a new member of your group.
- Ask you to delete your share. This could be needed to cancel to
power of others people's share: as long as enough of you delete
their shares, the few people that might not delete them would end up
with unusable shares.
So, can we count on you for this?
Thanks and may the force be with you!
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment