Hi OpenPGP folks--
Between the recent SHA-1 development, MD5 attacks against other PKI
infrastructure, advances in computing power, and various nuances of the
protocol, it has occurred to me that most users of OpenPGP could
probably use some help in determining ways to increase the security of
their keys.
Following the model of lint [0], it occurred to me that it might be nice
to have a tool that scans an openpgp key and suggests changes or options
that the keyholder might want to consider. I'm calling this (entirely
hypothetical) tool "openpgplint" at the moment.
I'm aware one size does not fit all, and different situations warrant
different configurations. But maybe there's a way to present a
comprehensible range of situations, and then offer a series of
realizable best-practices recommendations to users based on their choice
of situation.
So i'm hoping to create a list of (a) typical situations where openpgp
keys are used, and (b) best practices for keyholders in those
situations. If i can assemble something that looks reasonably useful,
i'd be willing to write some code to implement the checks. Some checks
might require network access -- i assume that those checks could be
easily disabled by any automated tool, if a user wants privacy.
Suggestions and criticism are both welcome!
Here's a proposal for defining a well-secured, OpenPGP key that seems
reasonable for use by an individual communicating with other people with
modern OpenPGP clients over the next 3 years, as i understand the
situation (for reference, test names in preceding brackets):
[v4key]
The key should in OpenPGPv4 format
[key-type]
The primary key should be either DSA or RSA
[key-size]
The primary key should have at least 2048 bits.
[valid-uid]
The key should have at least one valid, non-expired, non-revoked User
ID in an RFC-822-compliant e-mail address form. (maybe a network check
to see that mail can be delivered for the domain in question at least?).
[selfsig-strong-digest]
The most recent self-sig over each user ID should be made over a
digest from the SHA-2 family (SHA224, SHA256, SHA384, or SHA512).
[selfsig-expiration]
The most recent self-sig over each user ID should include an
expiration date no more than 10 years in the future (or maybe 10 years
from key creation?).
[selfsig-strong-digest-advertisement]
The most recent self-sig over each User ID should list preferred
digest algorithms including at least one digest from the SHA-2 family.
[selfsig-primary]
The most recent self-sig over the User ID identified in [valid-uid]
should be marked as the primary User ID.
[self-sig-usage-sign-and-certify]
The most recent self-sig over each User ID should indicate that the
primary key is usable only for signing and/or certification.
[subkey-encryption]
There should be at least one properly-bound, non-expired, non-revoked
subkey marked for use with encrypted communications and/or storage.
[subkey-encryption-type]
All encryption-capable subkeys should be either RSA or ElGamal.
[subkey-encryption-size]
All encryption-capable subkeys should be at least 2048 bits.
[subkey-encryption-binding-strong-digest]
The most recent binding signature for each encryption-capable subkey
should use a digest algorithm from the SHA-2 family.
[subkey-encryption-binding-expiration]
The most recent binding signature for each encryption-capable subkey
should have an expiration date no more than 5 years in the future (or
maybe 5 years from key creation?).
[wot-published]
The key and associated [valid-uid] and [subkey-encryption] (and their
most recent binding signatures) should be visible from keyservers in the
current Web of Trust (maybe this would be a network check against the
SKS pool?).
[wot-other-sig]
The UID specified by [valid-uid] should be certified by at least one
other key also visible in the public WoT (another network check?).
[wot-other-sig-strong-digest]
At least one certification meeting the criteria for [wot-other-sig]
should be made over a digest from the SHA-2 family.
What other tests would you do? which of the above tests do you think is
bad or wrong? What improvements would you make? Any suggestions for
other situation profiles to consider?
A failure of each test could be associated with help text or
instructions about how to address the concern using a particular
OpenPGP-compliant tool. Perhaps specific failures or specific tests
could be ranked for each situation as well (e.g. critical, bad, warning,
pedantic). Suggestions for help text (either generic for a test, or for
a specific tool for a test) would also be welcome.
Thanks for any feedback you might have,
--dkg
[0] http://en.wikipedia.org/wiki/Lint_programming_tool
signature.asc
Description: OpenPGP digital signature