keys: remove revoked key 867B9DFA

[sheerlox]

Key 1C050899334244A8AF75E53792EF661D867B9DFA has been revoked: https://keyserver.ubuntu.com/pks/lookup?search=1C050899334244A8AF75E53792EF661D867B9DFA&fingerprint=on&op=index

This PR removes it so automated workflows relying on this repository to import all signing keys can keep working (example broken workflow).

Not sure this PR makes sense since this key signed previous Node.js releases.

What would be the best way to go about this? Does it make sense to use the key(s) stored in keys/, which does not embed the revoking information? Can the releases this key might have signed be re-signed with valid keys?

[UlisesGascon]

ping: @nodejs/security and @nodejs/releasers

[canterberry]

Thanks for putting this together, @sheerlox ! It's a good callout, and I don't have a definitive answer.

My thoughts and context...

The initial intent of this repo was to provide an actively maintained source of truth for the contents of release signing keys, regardless of which keys are currently authorized for signing.

i.e: if you have a release signature from any valid Node.js release, you should be able to find the signing key in this repo.

However, I can see the potential danger in workflows which assume none of the keys in this repo have since been revoked. Without some additional step to filter only signing keys which were valid at the time of that release:

• new members of the release team could sign any previous Node.js release
• former members of the release team could sign any Node.js release even after their departure

The open question to the release team is: are either of the above scenarios in scope for this repo's threat model?

If so, then I would propose the following workflow for potentially hardening this repo to mitigate the threat:

1. The HEAD of this repo's main branch should be the current source of truth for which keys are designated for and authorized to sign releases. In other words, if a new Node.js release is signed today, then any key currently in this repo should be considered valid for signing that release.

2. When verifying a release, the ref (commit) in this repo selected for verification should be the latest commit prior to the signature timestamp.

A workflow change for the release team would be to add/remove signing keys at the appropriate times:

• New keys should be added prior to the first release signed with that key.
• Retired/revoked keys should be removed from this repo ASAP.

For a decision and further discussion, we'll need to bring in some folks from the Node.js release/security team.