Daniel Kahn Gillmor | 12 Jun 2009 04:14

openpgplint: encouraging best practices for OpenPGP keys today

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
(Continue reading)

David Crick | 12 Jun 2009 12:19
Picon

Re: openpgplint: encouraging best practices for OpenPGP keys today


On Fri, Jun 12, 2009 at 3:14 AM, Daniel Kahn
Gillmor<dkg <at> fifthhorseman.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
(Continue reading)

Daniel Franke | 12 Jun 2009 04:52
Picon
Favicon

Re: openpgplint: encouraging best practices for OpenPGP keys today


Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:

> [selfsig-primary]
>   The most recent self-sig over the User ID identified in [valid-uid]
> 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.

> [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?).

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         df <at> dfranke.us         http://www.dfranke.us
 |----| =|\     \\\\    
 || * | -|-\---------   Man is free at the instant he wants to be. 
 -----| =|  \   ///     --Voltaire
(Continue reading)

Daniel Kahn Gillmor | 12 Jun 2009 05:19

Re: openpgplint: encouraging best practices for OpenPGP keys today

Thanks for the feedback, Daniel.

On 06/11/2009 10:52 PM, Daniel Franke wrote:
> Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
> 
>> [selfsig-primary]
>>   The most recent self-sig over the User ID identified in [valid-uid]
>> 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.

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?

>> [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
(Continue reading)

David Shaw | 12 Jun 2009 05:56

Re: openpgplint: encouraging best practices for OpenPGP keys today


On Jun 11, 2009, at 11:19 PM, Daniel Kahn Gillmor wrote:

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

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

Daniel Kahn Gillmor | 12 Jun 2009 06:33

how to respect keyserver no-modify ? [was: Re: openpgplint]

Over in ietf-openpgp <at> imc.org on 06/11/2009 11:56 PM, David Shaw wrote:
> 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.

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:

(Continue reading)

Daniel Franke | 12 Jun 2009 07:40
Picon
Favicon

Re: how to respect keyserver no-modify ?


Daniel Kahn Gillmor <dkg <at> fifthhorseman.net> writes:
> 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?

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.

--

-- 
 Daniel Franke         df <at> dfranke.us         http://www.dfranke.us
 |----| =|\     \\\\    
 || * | -|-\---------   Man is free at the instant he wants to be. 
 -----| =|  \   ///     --Voltaire

John W. Moore III | 12 Jun 2009 06:54

Re: how to respect keyserver no-modify ? [was: Re: openpgplint]

Daniel Kahn Gillmor wrote:

> Are there other proposed ways one could implement a keyserver which
> 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)

David Shaw | 12 Jun 2009 18:27

Re: how to respect keyserver no-modify ? [was: Re: openpgplint]


On Jun 12, 2009, at 12:54 AM, John W. Moore III wrote:

> Daniel Kahn Gillmor wrote:
>
>> Are there other proposed ways one could implement a keyserver which
>> 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]  :-\

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  
(Continue reading)

Daniel Kahn Gillmor | 12 Jun 2009 17:46

Re: how to respect keyserver no-modify ?

On 06/12/2009 12:54 AM, John W. Moore III wrote:
> 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]  :-\

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.

> The bottom line is that it is too late to re-invent the Keyserver
> 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?

(Continue reading)


Gmane