Riseup Role OpenPGP Key

We have a role key, we need to detail how this key is handled, and the policy that we can publish so people can certify it.

Riseup has a collectively managed OpenPGP key. This key is used to represent Riseup as an organization, and is not linked to any specific individual who is part of the collective. The signatures on that key are not indicators of who makes up that role.

We need to have a clear policy delineated, that we can refer to in the comment field of the key, and then we need to solicit signatures of that role key from people we exchange keys with. This is important to do to not only build up trust paths to Riseup’s key, but also because at the moment the role key is only signed by two people, who are both Riseup collective members. Having this information exposed defeats the purpose of a role key.

The following is a draft help document that we would publish and then refer to in our key comment field, once we are comfortable with it. It should be signed with the role key before it is published.

Date of last change: xxx

What is this key?

Normally people consider the web of trust (WoT) to be a mathematical association of a physical person’s identity with a key, as the WoT is used primarily for an identity authentication mechanism to provide reasonable assurance that the person in control of that key is actually the person you think you are communicating with. In a highly mediated communication realm, having such assurances are often critical. However, it is also possible to have a key that doesn’t represent an individual, but rather an organization. Riseup has such a collectively managed key, and this document describes what that key is used for.

Should I sign this key?

Signing Riseup’s collectively managed OpenPGP key says nothing about how secure Riseup is, either its technical infrastructure, or organizationally. The amount of “trust” that you put in Riseup, should also not be a factor. It only says that you have made some level of effort to verify that the individual that asked you to sign the public key, appeared to you to be in control of that key.

The value of your key, or the signatures you make are not diminished if for some reason Riseup has been compromised. Your signature on this key, indeed any other, does not indicate infinite endorsement of identity and validity. It simply states that you exercised due diligence in verifying and felt sufficiently satisfied by that to sign the key.

How do you exercise due diligence? You should be checking fingerprints, and making reasonable attempts at verification. Perhaps you could arrange a shared secret phrase with the Riseup collective member you met, that would have to be returned to you in an email before you will sign the key and then send your signature on the key as an email, encrypted to the key itself to collective@riseup.net.

When you assess the relative validity of such a key, you should consider that this keypair may be shared among a group of people and that there may be individuals that make validity assertions about this keypair who you, the signer, has never met.

Riseup’s Key Policy

The Riseup Collective will use this collectively managed key to cryptographically authenticate content that will be distributed over the network. This content is content that we consider important for our users to be able to verify using the OpenPGP Web of Trust.


Riseup will update important documentation, as appropriate, and cryptographically sign that content to provide verification. For example, the fingerprints of our SSL keys will be represented in our help documentation signed by our collectively managed key.


Riseup will accept OpenPGP-signed communications, validate that the chain of trust is no longer than 3 steps between the signing key and Riseup’s key, or any member of the collective’s keys, and act appropriately based upon the validity of the signature.

Riseup will OpenPGP-sign all outgoing collective communications with the collective’s key (collective members may optionally also sign mail with their own individual keys).


Riseup will use the collective’s key to provide cryptographic signatures of software that we distribute, so that there will be available a reasonable verification of authenticity. Riseup will use modern cryptographic hashes to compute message digests of the distributed software and will then publish those hashes, signed by the key.


The Riseup Collective key, and its associated secret key material, will only be used by Riseup Collective members, and nobody else. As the collective changes, additional people will have capability to access this private key and use it for the uses outlined above. As people leave the collective, the access to the key will be removed. If that access cannot be reasonably removed, a revocation signature will be made on the key and sent to the keyserver network.


Riseup commits to providing up-to-date and clear documentation that demonstrates how to verify these cryptographic signatures and why.


In the future, we may need to update this policy with more information, additional use cases, etc. If the policy is updated, we will cryptographically sign the updated policy, provide a clear indication of when it was changed last, and what changes were made. We will also do our best to communicate to you that this policy has changed, so you can be aware of it.

How to verify this document

Some details should go here about how people can go about verifying the cryptographic signature of this document.


Seems great to me.


And to me. That’s a nice template, which I’d like to reuse if I may.


I hadn’t spend much thinking before on role based keys, used by a bunch of people for different purposes. It raised a bunch of questions:
- what are different ways to manage it? Sharing a secret? Secret sharing? Are there some existing tools you’ve looked at to accomplish this?
- how are you revoking access to one or more people (for whatever reason, I’m only thinking about the way to do this not how you get to an agreement to do this)?
- why are you using a single key for all these different purposes and not different subkeys for different purposes? Or a key for software signing, a key for communication etc.
-… yet another approach.

You’ve probably spend a whole bunch of thinking on this subject, and I can imagine that you don’t want to tell the world how you’re managing it in detail, but if you can share your thoughts (or the thoughts from others about this) that would be very interesting.


ideas around key management:
1) you could share the private key among members or a subset of members, you could also make a setup where you need N people from the members in order to sign. The latter makes it more difficult imho.
2) get a new key, revoke the old one. or in the case of 1b, destroy the part where the member has access to.


“It only says that you have made some level of effort to verify that the individual that asked you to sign the public key, appeared to you to be in control of that key.”

this seems dubious to me at some level. I am not part of the riseup collective. let’s pretend that i am even a known adversary of riseup.

Let’s say that i produce a key with a user ID “riseup.net Role Key” (or whatever).

The fact that I can demonstrate to some user that i control the key does not mean that they should certify the key+userid combination, particularly if they do not believe i am a member of the riseup collective, or potentially responsible for the riseup role key.


True, that is a good point dkg. That was written to address the concern that people were having that signing the role key indicated some level of trust of riseup, but I see how it uncovers an additional problem. Do you think the paragraph which has some suggestions about exercising due diligence in verifying that the key is the right collective key could be re-worded in some way to make that clearer earlier (the one that follows the section you quoted and starts with “How do you exercise due diligence?”


I would like to reuse/translate/adapt. Is there a license for this text?


I actually have it on my todo list to do some fairly major overhaul of this taking into account some of the comments here and some others that I received. You are welcome to use this text as it is, but maybe you want to wait a week or so more until I get to the rewrite?


Ping. May I reuse/translate/adapt the current version and then update in the future if needed?


yes, you can re-use/translate/adapt consider it public domain! I was hoping to update this with some changes, before it was used, but I actually dont mind it being used now.


Could this page be public? :)


Seeing as I haven’t had time to update this, I’m making it public now.


Is there any possibility of having the collective sign keys used for activism? I have a key that expires in a year but I am planning to make a pair that doesn’t and I would like to start building some reputability for the key. The RIseup collective would be a great start.