On Mon, 2019-06-10 at 16:56 +0000, Jeremy Stanley wrote: > 2. Don't place all your trust key revocation, instead plan a > rotation schedule so that even if a key falls into the wrong hands > it's more likely users will smell something fishy when they see it > used to sign new artifacts after expiration, even if they're not > regularly checking for key revocations.
We generate new keys once a year, publishing them in a keyring package 6 months before they start being used. We are currently signing with the 2019 key, and will generate the 2020 key in a few weeks. > 3. Use signing-only subkeys in your automation, not your master > keys; this way the master keys can kept symmetrically encrypted > somewhere you only access to create or revoke subkeys (maybe even on > the other side of an air gap or locked up in an HSM). We are doing this already :) > 4. Package the public keys and make sure your pregeneration/rotation > schedule takes into account a slowest reasonable update frequency, > so that your users are likely to have your next key in place and > trusted before you transition to signing anything with it. We are publishing a keyring package which takes care of this. > 5. It probably goes without saying, but always generate a revocation > certificate for every master key when you create that key, and keep > it somewhere safe as a precaution in case you lose control of the > master. We are doing this already :) > 6. To allow for easier manual verification of key transitions, > always sign new keys with their predecessors when creating them. We haven't signed the new key at the GPG key-signing level, but we've effectively signed it at the APT level by publishing it in the repository 6 months before it gets used. > 7. You *may* want to separate signing and artifact building onto > different systems so you have tighter control over key distribution > and can shield key material from processes involving the running of > less-trusted/arbitrary code, though this still comes with its own > "chain of custody" problem as you need some way for the signing > system to trust not only the build system but now also the channel > through which the artifacts are transferred. The only place where the APT key gets used is to publish the APT repository itself. Internally, the build process signs with a disposable, unpublished GPG key that can easily be revoked if it's compromised. (The Aptly server is also only visible inside our network, so outsiders can't upload to it anyway.) > 8. Publishing fingerprints and validity dates for your keys > alongside your release documentation/announcements is sometimes > beneficial for bootstrapping initial trust (we also publish full > copies of our public keys on their own page, in addition to pushing > them into the public keyserver network). I've published the key and installation instructions on our APT landing page. > There's probably more I'm forgetting, but that's at least a good > start at mitigating unattended use of unencrypted keys while > maintaining a robust and resilient signing infrastructure. It sounds like I'm doing most of this already. Thank you for all the advice! Kyle