On Fri, Jun 12, 2009 at 3:14 AM, Daniel Kahn
Gillmor<dkg(_at_)fifthhorseman(_dot_)net> wrote:
[subkey-encryption]
There should be at least one properly-bound, non-expired, non-revoked
subkey marked for use with encrypted communications and/or storage.
No, we need to allow primary key only "signature" keys
[subkey-encryption-type]
[subkey-encryption-size]
[subkey-encryption-binding-strong-digest]
all N/A if key is primary only
[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?).
I would say that this - as well as the primary key
expiry checking - is a "recommendation" only.
I fully agree with keys having expiration times,
and even that there might be grounds for there
being an *application*-level default for one, but
I *also* agree that people should be free not to
have one set.
Your primary key "guideline" (if I may now refer
to it as such) of 10 years seems sensible. I feel
that the encryption one is more arbitrary, although
I agree with your premise that there could/should
be shorter life-times for encryption sub keys.
I think there are certain differences of compliance
and/or usage when discussing OpenPGP:
1. the RFC
2. "best practises" - what I think you're aiming for
3. application-level defaults
4. What the user/organisation wants to do
Note, that's not (necessarily) a hierarchy, some
may overlap, and point 4 may not necessarily
agree or comply with any of the other three.
[wot-published]
may not apply
[wot-other-sig]
[wot-other-sig-strong-digest]
may be within a closed and/or offline set of
users, but they certainly apply as sub-ideals
if the key *is* wot-published as above.
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
This actually all reminds me a bit of the early "HTML
verifiers" - and indeed would still apply to the WWW
today, with its various forms of HTML compliance
(or not!).
The W3C brought out a verification tool, which
eventually was taken over and maintained by an
outside party (it's called "HTML tidy" from memory).
At first this tool was highly useful, but after a while
it became *so* pedantic that it became useless in
practise.
I'm all for a "best practises" document (that would
have to evolve over time), which people of course
would be allowed to deviate from.
I think this sort "on the ground consensus" would
be a more real-world reflection of the RFC, and at
the same time would have a two-way relationship
between the defaults in ["desktop"(?)] OpenPGP
applications (e.g. PGP, GnuPG).
Just my thoughts.