Release PGP key strategy and policy #709

Continuation of #681 but specifically on the topic of PGP keys for signing releases.

Context: release builds come from a git tag of the form vx.y.z which is signed by an authorized releaser (see git tag -v v1.0.4 or any other release tag) with their personal PGP key. Release builds available on iojs.org have a have a SHASUMS256.txt file generated for all downloadable assets (minus the docs/ directory). This file is also signed with the same key that signed the git tag for that release and the signed file is made available as SHASUMS256.txt.asc. An ASCII armoured version of their public key is also made available as SHASUMS256.txt.gpg for convenience.

The procedure I put in place in #681 for releases says that:

• releasers should list their full key fingerprint on the README (mine is there now); and
• the keys should also be submitted to https://sks-keyservers.net/ - the README also now contains instructions for how you can verify a download which includes this keyserver. See #verifying-binaries

Questions for discussion:

@bnoordhuis asked if we could

use a single master key with as many sub-keys as there are release managers? It would make all releases be signed by "io.js Release Engineering releng@iojs.org" (or whatever we decide to call ourselves) and it makes revocation a little easier. Master key management is an open issue, though; who gets to own it?"

My response is that I don't feel strongly about this but:

My personal bias is towards decentralising this and making individuals responsible for signing their releases with their own keys, simply because I think decentralisation in most aspects of the project are more healthy for the community focus and ethos that we're trying to foster. It also makes that individual properly responsible for that release rather than it just being a mechanical task.

@chrisdickinson had trouble submitting to sks-keyservers.net and @indutny suggested https://pgp.mit.edu/ might be a better alternative

My response is:

The only reason I chose sks-keyservers.net was because the only precedent I'm aware of for checking signed shasums is in the Docker images for both Node (official Docker ones) and io.js and that's what they've chosen to use. I don't know the reasoning behind this but I went with that as an established convention.

Both of these points need discussion, I'm labelling this as tc-agenda but please don't take that as a sign that this is only for the TC to discuss. Opinions welcome from those with expertise on this matter.