Subject: openpgplint: encouraging best practices for OpenPGP keys today

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 11 Jun 2009 22:14:49 -0400

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

---

From: Daniel Franke <[email-masked]>
Date: Thu, 11 Jun 2009 19:52:49 -0700

> should be marked as the primary User ID.

This expectation doesn't make sense.  I have multiple IDs representing
my personal and work addresses.  My primary address is my personal one,
but I've had it longer than I've had my current, hence this ID is not
the newest.

> current Web of Trust (maybe this would be a network check against the

Many people have no wish to have their key on public keyservers; there's
even a flag you can set (no-ks-modify) to request that others not upload
it.  Some people might only use PGP among a small, well-delineated group
and exchange keys by sneakernet.  Also, from when I ran a keyserver a
few years back, I'm fairly sure I remember seeing logs of it being
perused by spammers.

-- 
 Daniel Franke         [email-masked]         http://www.dfranke.us
 |----| =|\     \\\\    
 || * | -|-\---------   Man is free at the instant he wants to be. 
 -----| =|  \   ///     --Voltaire

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Thu, 11 Jun 2009 23:19:40 -0400

Thanks for the feedback, Daniel.

> but I've had it longer than I've had my current, hence this ID is not

Right; this test checks for the most recent self-sig *over the given
uid*, not the self-sig over the most recent uid.  My intent with the
"most recent" terminology was to acknowledge this clause in RFC 4880 (in
section 5.2.3.3):

   An implementation that encounters multiple self-signatures on the
   same object may resolve the ambiguity in any way it sees fit, but it
   is RECOMMENDED that priority be given to the most recent self-
   signature.

I've probably phrased it poorly; suggestions for how to rephrase it?

> few years back, I'm fairly sure I remember seeing logs of it being

True, there are many people who do not their keys on public keyservers.
 Should this be represented as a different situation than the normal
case?  Or would it be OK to this issue "pedantic", and include the
detail about why some folks might prefer to avoid it in the explanation?

From the perspective of being able to find a trust path to an third
party through mutual acquaintances, it seems advantageous to encourage
people to publish to the WoT.  But there are downsides, as you say, such
as spammers and social/transactional surveillance by third parties.

I should note that i'm a bit confused about the keyserver-no-modify
flag.  recent versions of GPG seem to set it by default.  But the spec says:

  http://tools.ietf.org/html/rfc4880#section-5.2.3.17

       the key holder requests that this key only be modified or updated
       by the key holder or an administrator of the key server.

And yet, i can upload gpg-created keys to keyservers with no warnings
(whether or not i hold the secret key) and the keyservers accept them
anyway.

How is the keyserver supposed to tell who is making the upload?  Or are
clients expected to interpret this flag, and behave honorably with it?
is gnupg behaving poorly?  Should i have to override something to force
such a key into the keyservers?

	--dkg

---

From: David Shaw <[email-masked]>
Date: Thu, 11 Jun 2009 23:56:55 -0400

> (whether or not i hold the secret key) and the keyservers accept them

The keyserver no-modify flag is effectively a no-op.  GPG lets you set  
or unset it, but since no keyserver actually looks at it, the flag  
isn't all that useful.

David

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 12 Jun 2009 00:33:22 -0400

Over in [email-masked] on 06/11/2009 11:56 PM, David Shaw wrote:
> or unset it, but since no keyserver actually looks at it, the flag isn't
> all that useful.

Should we try to address this?  What would it mean to make this flag
meaningful?  Say a keyserver decided to try to respect it: how would it
do so?

let's assume that key server admin can directly tamper with the key
store, and not worry about that part of the RFC directly.

That leaves us with:  how does the keyserver know that it was being
updated by the key holder?

One approach would be to use OpenPGP client-side certificates (with
authentication flag set?) for an RFC 5081-compliant TLS connection to
the keyserver.  This seems far-fetched with the current state of tools.
 It also wouldn't cleanly address keyserver propagation (only the
initial keyserver received and could verify the TLS connections).

Alternately, a keyserver could only append signatures to a key/uid
marked "no-modify" if the new signature arriving is itself wrapped in a
0x50-style "third-party confirmation" signature, where the "third-party"
is in fact the original keyholder (the "third party" == the "first
party", if you will).

Then the workflow for adding certifications to a key in the public
keyservers might look like:

 * Alice publishes her key (with the keyserver-no-modify flag set) to
the public keyservers.  they accept the primary key, user ID, and
self-sig because the self-sig is validated by the primary key.

 * Alice shows Bob her key fingerprint and her identification.

 * Bob fetches Alice's key from the keyserver, verifies the fingerprint
and user ID, and signs the UID+key, creating signature X.

 * Bob tries to post X to the public keyservers, but they reject it
because the key is set no-modify.  Bob's client offers to mail X
directly to Alice instead, and he lets it do so.

 * Alice receives X, looks it over, verifies that it was properly made
by Bob, and decides that she wants to publish it.

 * Alice creates a 0x50 "third-party" certification over X, creating Y.

 * Alice feeds Y to the keyservers, who verify that her signature is
attributed to the key being signed by X, so they accept X.

 * when the keyservers propagate new signatures, they propagate not only
X, but Y, allowing other keyservers to verify that X is acceptable to
the original keyholder.

It seems that an architecture like this (if it was the standard for
keyservers) could prevent a lot of bogus signatures from accumulating on
a given key, and could nicely prevent the kind of denial of service
attacks that are possible against a key by loading up millions of bgus
certifications on that key.

Are there other proposed ways one could implement a keyserver which
respects the intent of keyserver no-modify?

	--dkg

---

From: "John W. Moore III" <[email-masked]>
Date: Fri, 12 Jun 2009 00:54:42 -0400

> respects the intent of keyserver no-modify?

Rather than attempt to introduce this much complexity into the Keyserver
system [an impossibility] if such a scheme must be implemented then
simply introduce into the Key Generation Wizard the --keyserver command
and then have the individual specify where they desire their Key to be
retrieved from. [Big Lumber, Personal Web page, etc.]  Of course this
pre-supposes that all other Users have the --honor-keyserver-url
preference specified in gpg.conf or their Options file.  [possibly
excluding PGP & other OpenPGP implementations]  :-\

The bottom line is that it is too late to re-invent the Keyserver
System/Network for Key distribution.  Sufficient tools exist already to
mitigate 'Key pollution' from Keyservers but education of the User Base
in proper implementation is sorely lacking.  IMO the dilemma of
--no-ks-modify falls under the heading of "Accept the things I cannot
Change" & "Wisdom to know the difference."

JOHN :-\
Timestamp: Friday 12 Jun 2009, 00:53  --400 (Eastern Daylight Time)

---

From: Daniel Franke <[email-masked]>
Date: Thu, 11 Jun 2009 22:40:51 -0700

> meaningful?  Say a keyserver decided to try to respect it: how would it

Since, as you note, the keyserver admin has the ability to tamper with
public keys regardless, I don't see wisdom in trying to securely enforce
the semantics of ks-no-modify.  I think a better and simpler approach
would be to check it client-side: prompt the user for confirmation if he
tries to upload [modifications to] a public key for which ks-no-modify
is set and for which the correspond private key is not in his keyring.

---

From: David Crick <[email-masked]>
Date: Fri, 12 Jun 2009 11:19:41 +0100

> subkey marked for use with encrypted communications and/or storage.

No, we need to allow primary key only "signature" keys

> [subkey-encryption-binding-strong-digest]

all N/A if key is primary only

> 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-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.

> Thanks for any feedback you might have,

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.

---

From: Daniel Kahn Gillmor <[email-masked]>
Date: Fri, 12 Jun 2009 11:46:29 -0400

> excluding PGP & other OpenPGP implementations]  :-\

I think maybe we're thinking of different threats;  it would be useful
to have a redundant set of keyservers that would be
"pollution-resistant", at least for keys which have specified that they
prefer to be propagated that way.

setting keyserver-url only provides redundancy if you point it to a
replicating keyserver; but if you point it to a generic replicating
keyserver, you lose the pollution-resistance that a privately maintained
key file gives you.

> System/Network for Key distribution.

Really?  I'm not suggesting that a change like this could be done
quickly, but it does seem like the infrastructure can change.  For
example, SKS didn't even exist when RFC 2440 came out (and included the
no-modify flag for keyserver preferences), but it is now arguably the
dominant keyserver using a novel synchronization protocol, and under
active development.   What makes you say it's too late to make changes?

> Sufficient tools exist already to
> mitigate 'Key pollution' from Keyservers 

i'm glad to hear it!  What tools do you suggest we use?

> but education of the User Base
> in proper implementation is sorely lacking.

Are you suggesting that the tools we have require every single user to
behave responsibly in order to avoid keyserver pollution?  in that case,
the problem seems like it lies in the tools or the protocols, not in the
user base.  There will always be one incompetent or malicious user who
will abuse the tools.  It would be good to ensure that two parties who
are both competent and non-malicious could use the tools without
interference by an arbitrary malefactor.

The current keyserver infrastructure seems to be vulnerable to a range
of attacks by arbitrary malefactors:

https://www.informatik.uni-hamburg.de/SVS/archiv/thesis/06-08-27-BT-Holst-PGP-Key-Servers.pdf

And some of these attacks (certainly not all) seem like they could be
mitigated by a wider adoption of the kind of workflow we're discussing.

> IMO the dilemma of

You may very well be right, but i'm not wise enough yet to see why this
doesn't currently fall into "the courage to change the things i can".
Can you help me understand why you think it's set in stone?

	--dkg

---

From: David Shaw <[email-masked]>
Date: Fri, 12 Jun 2009 12:27:55 -0400

> excluding PGP & other OpenPGP implementations]  :-\

Note that "honor-keyserver-url" is enabled by default in GPG, and has  
been enabled by default since preferred keyserver URL support was  
added back in 2004.  It's possible someone has turned it off, but this  
would be the exception, not the rule.

PGP supports preferred keyservers as well, and as far as I know, they  
work more or less the same way they do in GPG: when refreshing a key  
with a preferred keyserver set, that keyserver is used.

Preferred keyserver URLs don't really address the "find me a key"  
problem.  They only address the "keep the key I've already found up to  
date" problem.

David