Subject: Pre-register info #458470

From: [email-masked]
Date: Tue, 30 Jun 2009 11:08:30 -0700 (PDT)

Tell a friend
|
Download latest version

See this email as a webpage

Hello!

Shipped Privately And Discreetly To Your Door!

We want to put a great big grin on your face in 2009. You'll be to rejoice all year.

Unsubscribe
|
Lost Password |

Account Settings |
Help
|
Terms of Service
|
Privacy

Ottho Heldringstraat 5, 68084 AZ Amsterdam, The Netherlands

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CGS9kn009864 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 09:28:09 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5CGS9Gg009863; Fri, 12 Jun 2009 09:28:09 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CGRvc9009851 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Fri, 12 Jun 2009 09:28:08 -0700 (MST) (envelope-from [email-masked])
Received: from dshaw.nasuni.net (wasabi.nasuni.net [65.202.22.178]) (authenticated bits=0) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n5CGRtgX006819 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Fri, 12 Jun 2009 12:27:56 -0400
Cc: IETF OpenPGP Working Group
Message-Id: <[email-masked]>
From: David Shaw
To: "John W. Moore III"
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: how to respect keyserver no-modify ? [was: Re: openpgplint]
Date: Fri, 12 Jun 2009 12:27:55 -0400
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.935.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

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
date" problem.

David

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CFkiwr006401 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 08:46:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5CFkiGf006400; Fri, 12 Jun 2009 08:46:44 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n5CFkXkV006386 for ; Fri, 12 Jun 2009 08:46:44 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 39906 invoked from network); 12 Jun 2009 15:46:32 -0000
Received: from 216.254.70.154 (HELO ?192.168.23.207?) (216.254.70.154) by relay01.pair.com with SMTP; 12 Jun 2009 15:46:32 -0000
X-pair-Authenticated: 216.254.70.154
Message-ID: <[email-masked]>
Date: Fri, 12 Jun 2009 11:46:29 -0400
From: Daniel Kahn Gillmor
Reply-To: IETF OpenPGP Working Group
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: IETF OpenPGP Working Group
Subject: Re: how to respect keyserver no-modify ?
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9; url=http://fifthhorseman.net/dkg.gpg
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig38AF64C2410E015FF3749DB7"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig38AF64C2410E015FF3749DB7
Content-Type: multipart/mixed;
boundary="------------050207060100010707060203"

This is a multi-part message in MIME format.
--------------050207060100010707060203
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On 06/12/2009 12:54 AM, John W. Moore III wrote:
> Rather than attempt to introduce this much complexity into the Keyserve=
r
> 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?

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

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
> --no-ks-modify falls under the heading of "Accept the things I cannot
> Change" & "Wisdom to know the difference."

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

--------------050207060100010707060203
Content-Type: application/pgp-signature;
name="signature.asc"
Content-Transfer-Encoding: base64
Content-Disposition: inline;
filename="signature.asc"

LS0tLS1CRUdJTiBQR1AgU0lHTkFUVVJFLS0tLS0KVmVyc2lvbjogR251UEcgdjEuNC45IChH
TlUvTGludXgpCkNvbW1lbnQ6IFVzaW5nIEdudVBHIHdpdGggTW96aWxsYSAtIGh0dHA6Ly9l
bmlnbWFpbC5tb3pkZXYub3JnCgppUUlWQXdVQlNqSHBjY3pTN1pUU0Z6bnBBUXFrc0JBQWgw
WCtxM3dqSXVwOXJScFBhcmlsYVBVandLL25UVXF0ClVOYWNRMUlxMG9BYkExQzdBaE9QaE1u
YVpWT085SXJocEduV2dsOFVaN0FyTURIc3NzU2UxdThqNzZ3QkdVdmUKcWdDakd1bDlhSmZH
MGwxRU9rVjF2WEVOc2h2bW1ET29FdE85WVhvMTlmeDhUM2M1UG83ZWZBcEpFNGczM0d4UAp5
bFVzSVJQWFVXbVh6bGRYUlhEbTNpSmFobzhzQzdpaDBUekwxYXFOTmRrWGxkb3lpRzBOb3VS
aXdGSG1nTXluCmpyUVIvcEhXOEoyczRKQk1waENYWEMvNkdXUWNJSjc2dk9aREhBL2ZWSk5V
RDkyb3NIUEk0aGN3TXJmWDNqdzgKbWFPOXJ5WkZ5TUJmS0dHR21mWWlNYnRjRjBBN0x3eFNB
YTU2YS82YlFhMEh2T0NUaWxLYXZVY1Fua05SYUlzNAp1K3hybHdMTTUxbHpIcEZjdWVvOWNB
cG1hNHZoQVpVMGthUHBITC84S1hFdko2TExmcUxtRDFTajZjUWpOcjc4CmluUkJFZm9KajNL
QnpPN241L1plNWNaZHZrRkk1Tys2MGhsNnlscUdiNThkdkVWMDlVdWdpQWVnbGdseDJleU0K
cTFJS3lFaHVFTXJObGJmYWNyOEtHSU9HR2tQTjlwM1VLVnU5Z0thYWZQOE1zV0pGZm9sdW9C
UmVvWm1meXpvZApKNWRGOWRkcnJ3ZU9BYUJhSVUyVVhuRkVsS0E4QzZCMk8zYWNMa2Q2YXZW
ckVJVlFtS3E3anl2M0huaWNWeHhmCnZxZEpyam83dTFVRllFK1ZuTGVhWmsxSTA5NHFtWkdn
WnRzczNmZGFzV3A0VURnNmZTWHBYSTJRVlhQSU54RjgKTjlYQmt0elFZWEk9Cj03U2kvCi0t
LS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQoK
--------------050207060100010707060203--

--------------enig38AF64C2410E015FF3749DB7
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSjJ4VszS7ZTSFznpAQpYHRAAjOIpwWy34WLDZq7xHcLCaSX71WcqlIjn
O4vLZpfKiI6uM/x/KO1mVqeH4fGCIWxU3du6BMQLthSZemFL1oVenrBo7CoWemcD
LxhN2QLYJG4ygGV0TORQWjQhlG6ygWZIAvo5POrBbL5O4XMmP3NKoHMEyncHL/Ec
eNesch2uamah2AcGues5xoZkgDByvDQKsxr9PR5j/r9ArI2mYfw2Bfgh2GOKMAOR
B9FV7Tqm6UxyCMSc+cNVdI6Wu3To6D0HytIRVfHSxWgbZCzuQKFX0v8HsCY3ngol
HqWnFU+a+KPf08qOd1Di67Sor6cW3Jy/AAwJ8J+0IxxCG8/QVlk+XK0DupfGdbWl
1mOWmYfLN73fttsYWHcTtyrEOBd8LtGKFDt3U/NDK4bNyK00JGsH/RM1wfdbSjYp
+bJ1o+wKjXfnIbLTq7pfktXN+eOs20+IohmxSdOf16jeRdBpsiDSl1ec4/ezi5AW
52rHGf20QAVC+GpT1Vp/Bw3lXPGCaz6J/ulx0iVEP/dqpMGmdTQobynftijwuzbx
1CpAULqjJmSGTQB5gr6CthEZNUtqxE3xUX1zJVXukcwP92n0hnmCaqW8+MZxO42t
Mm9uk5ZM2LNTxyylsAqaftxWKi0Kk0MfP55iBJO9SMdaEeqYUBiTAalTTba4QFGu
GFw2slukBng=
=YO7O
-----END PGP SIGNATURE-----

--------------enig38AF64C2410E015FF3749DB7--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CAJi7H086950 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Fri, 12 Jun 2009 03:19:44 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5CAJiYZ086949; Fri, 12 Jun 2009 03:19:44 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mail-fx0-f215.google.com (mail-fx0-f215.google.com [209.85.220.215]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5CAJgnj086940 for ; Fri, 12 Jun 2009 03:19:43 -0700 (MST) (envelope-from [email-masked])
Received: by fxm11 with SMTP id 11so205234fxm.10 for ; Fri, 12 Jun 2009 03:19:41 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=QpRdLgpIA9246FONbR+ih4A63qPhcl0JWS2P+pXpUtA=; b=hK5zQbtrkn/34z2gUor0gpcelLupkYXSEqD8T3APBRTyRiyqooOaO6jL+Cm8Q1YuLK ofal/YpEtGoI1kIBcPgddGyrB0/Up4cMXd/xy3wpHhlXArN6hCP/3oHPscYGYMU5ya7M yhg5veCMJP0lz4gP4MAd7RUPL9UopXCLn+trA=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=ON2gDUlqKEtzWXT2I7/UCamleYLdmqofBxZYvjm3XGcswRnRUJc9uoQk+Pv22BSQK1 2etlJHVMwNazRqbJfh6w0LotGWll51ogkZtSbbxP7fDO4z24vdf07V9iELWYQVdEoBnc 6ntk4lOIaT7xIrNrQrb403C5CLgKSYcYCrU4Y=
MIME-Version: 1.0
Received: by 10.204.67.66 with SMTP id q2mr3464030bki.161.1244801981678; Fri, 12 Jun 2009 03:19:41 -0700 (PDT)
In-Reply-To: <[email-masked]>
References: <[email-masked]>
Date: Fri, 12 Jun 2009 11:19:41 +0100
Message-ID: <[email-masked]>
Subject: Re: openpgplint: encouraging best practices for OpenPGP keys today
From: David Crick
To: Daniel Kahn Gillmor
Cc: IETF OpenPGP Working Group
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

On Fri, Jun 12, 2009 at 3:14 AM, Daniel Kahn
Gillmor wrote:
> [subkey-encryption]
> =A0There 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]
> =A0The 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? =A0which of the above tests do you think i=
s
> bad or wrong? =A0What improvements would you make? =A0Any 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. =A0Perhaps specific failures or specific tests
> could be ranked for each situation as well (e.g. critical, bad, warning,
> pedantic). =A0Suggestions for help text (either generic for a test, or fo=
r
> a specific tool for a test) would also be welcome.
>
>
> Thanks for any feedback you might have,
>
> =A0 =A0 =A0 =A0--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.

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C5f7vQ072499 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 22:41:07 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5C5f7AV072498; Thu, 11 Jun 2009 22:41:07 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mho-02-ewr.mailhop.org (mho-02-ewr.mailhop.org [204.13.248.72]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C5etGd072484 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Jun 2009 22:41:06 -0700 (MST) (envelope-from [email-masked])
Received: from adsl-99-185-244-26.dsl.pltn13.sbcglobal.net ([99.185.244.26] helo=feanor.dfranke.us) by mho-02-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1MEzVX-0003OY-EV for [email-masked]; Fri, 12 Jun 2009 05:40:55 +0000
Received: by feanor.dfranke.us (Postfix, from userid 1000) id DB02C2D63EB; Thu, 11 Jun 2009 22:40:51 -0700 (PDT)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 99.185.244.26
X-Report-Abuse-To: [email-masked] (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX186t5mb74t0U62hEQXgfUJo
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dfranke.us; s=default; t=1244785251; bh=AjEXV91UBv1TwKuTtQaotFkNQnLt7HWUXeCvVQXozSI=; h=From:To:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=fftBAZ9vPxbCE7xkagf+xdty9PGcCziCUAMUO truFwRJksW57LB1zQMUBVKJm6b0isJ6FNbJJ6OWYsjb8VIi7IKtkJ8wAUhyeRm1kxml SMyNZK4KWPhQHBXS52vfJPC57sb1q0cemKuyHTfA9AHJXP48VIbTilsGEi6jhJ+G89q 0sOw+shIr6M2gGQYcJjFoMof2e/x9vpK6oO+vrJutINOkBm9MtaGqL61aUXGRS7rXBa OWBnhW/300H9TEVTIStBkq3VjRAtesANtEskA02kUgrDjYtre93+c3KMtBq54qyvD8s 87BfZlw+aKdhtEoJPGTPjhtiOedmRPPevCIjg==
From: Daniel Franke
To: IETF OpenPGP Working Group
Subject: Re: how to respect keyserver no-modify ?
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
X-Hashcash: 1:26:090612:[email-masked]::fbyIZhIvKPych0WS:00000000000000000000000000000000000000000GqNN
Date: Thu, 11 Jun 2009 22:40:51 -0700
In-Reply-To: <[email-masked]> (sfid-20090611_21395_1621E0E3) (Daniel Kahn Gillmor's message of "Fri, 12 Jun 2009 00:33:22 -0400")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Daniel Kahn Gillmor 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 [email-masked] http://www.dfranke.us
|----| =|\ \\\\
|| * | -|-\--------- Man is free at the instant he wants to be.
-----| =| \ /// --Voltaire

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C4svj3070019 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 21:54:57 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5C4svlH070018; Thu, 11 Jun 2009 21:54:57 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from fmailhost05.isp.att.net (fmailhost05.isp.att.net [207.115.11.55]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C4skk0070008 for ; Thu, 11 Jun 2009 21:54:56 -0700 (MST) (envelope-from [email-masked])
DKIM-Signature: v=1; q=dns/txt; d=bellsouth.net; s=dkim01; i=[email-masked]; a=rsa-sha256; c=relaxed/relaxed; t=1244782486; h=Content-Type:In-Reply-To:References:Subject:To: MIME-Version:From:Date:Message-ID; bh=LGMbOy2WfUcJqvoPRqKuf5OOXfJPz QLFtEOWMOAS2tw=; b=P5cgU5+3O4tzhuexPw1422SCEscSv+UHAEijvsnFd4FmhdlA E1na3rshbmUNZxxHCgSMi3uNMK4Ax/VSs54B1g==
Received: from [192.168.1.96] (adsl-176-68-190.asm.bellsouth.net[74.176.68.190]) by isp.att.net (frfwmhc05) with ESMTP id <20090612045445H0500qeve8e>; Fri, 12 Jun 2009 04:54:45 +0000
X-Originating-IP: [74.176.68.190]
Message-ID: <[email-masked]>
Date: Fri, 12 Jun 2009 00:54:42 -0400
From: "John W. Moore III"
Organization: Gossamer Spider Web of Trust
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.22pre) Gecko/20090611 Lightning/0.9 Thunderbird/2.0.0.22pre Mnenhy/0.7.6.0
MIME-Version: 1.0
To: IETF OpenPGP Working Group
Subject: Re: how to respect keyserver no-modify ? [was: Re: openpgplint]
References: <[email-masked]> <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.96b
OpenPGP: id=80B42B0F; url=http://tinyurl.com/8cpho
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig9966962E1BA8B07F914CFB3A"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9966962E1BA8B07F914CFB3A
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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)

--------------enig9966962E1BA8B07F914CFB3A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10-svn5042: (MingW32)
Comment: Public Key at: http://tinyurl.com/8cpho
Comment: Gossamer Spider Web of Trust: https://www.gswot.org
Comment: Homepage: http://tinyurl.com/yzhbhx

iQEcBAEBCgAGBQJKMd+SAAoJEBCGy9eAtCsP/7wIAJYKV2VCYJay6ORGvYvcK9jN
do7eEtc80cz0u8iXneM6v4N2J8vujo34VS0qoipYhm7bwySkG7G3y6t43IAy/mfX
AB95nNStFHQqwHFMLa6G+W4yAddbV+KYHUDNY5WvGdIYRaOnAlnYWqIxjRqN3KBA
mxHIblHe4DujD14s/Urzp0ZTp+y4wy7KKqTj253EEcOAJPwEj5fEazkpXaEmdwes
DqBVla5oV5WUbwdQG1PUAwZYNLnSAr3WimH1eFIS0Mw6uKBZd/9YnB/Z2X5i+XWA
llgGi0Zxdmv+RKteYrw3kSCQGarM5FpE35oCT8MdZ+asrjiTW830k+q8UTwWKy0=
=OTrM
-----END PGP SIGNATURE-----

--------------enig9966962E1BA8B07F914CFB3A--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C4Y0Co069360 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 21:34:00 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5C4Y0JI069359; Thu, 11 Jun 2009 21:34:00 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay02.pair.com (relay02.pair.com [209.68.5.16]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n5C4Xntm069349 for ; Thu, 11 Jun 2009 21:33:59 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 78094 invoked from network); 12 Jun 2009 04:33:45 -0000
Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay02.pair.com with SMTP; 12 Jun 2009 04:33:45 -0000
X-pair-Authenticated: 216.254.116.241
Message-ID: <[email-masked]>
Date: Fri, 12 Jun 2009 00:33:22 -0400
From: Daniel Kahn Gillmor
Reply-To: IETF OpenPGP Working Group
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: IETF OpenPGP Working Group
Subject: how to respect keyserver no-modify ? [was: Re: openpgplint]
References: <[email-masked]> <[email-masked]> <[email-masked]>
In-Reply-To:
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigA38797289E0C0497241873A8"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA38797289E0C0497241873A8
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Over in [email-masked] 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" =3D=3D 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

--------------enigA38797289E0C0497241873A8
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSjHamMzS7ZTSFznpAQrIjBAAlMNrZtzyjOkI05/tLZ91talAB3eT/WQA
NNZ2GccQi5mrYEKr7RIHWQHP4manE5pUeBZrPpk98hL78Wc7uwjB76JYzFlx/OxY
8x3CO+0viync6IYV6aJ6+9OIlBsTwqPo7fp9Ec9Pqk2IAC0DzOmaT23Ln0EO5+lp
svHvJNHYFgGcd7S7G94cLoo6eElYDbhCdWjNiCZPixWqeD/DMowRQV71WtD0Zx4y
uQsM2CQE8bFc79EFsiH74jkyzUJv0R4saEVBZ7ysgL4YaD6n4yRK8+h7myb5Xown
uJypJbr0ivrQVJrP/mI+bmcDvONxTKeKqAZsJR0jToLpJxPyIAZ8MI1rRtO8y8ln
qBr0JP1RGyfg5/RyG33UM25o85Nlyg5u47dV7pv5IcQ+AUi0uaP2XS/cdFcUeK+i
lLDAZhB1xTa0njSgYHGMKqcM6WdDgg+RsAtsUkfytxGauOA971jWxj9y0JNzBLU8
p+rbwSig/sWwbXuvX87strIvNljdoMzJilzvCU7tU+B94zo8+4nGFSDhp9/NbS2X
6rT6+ZPf6RRUN0c1qUQKUivHRv0nv1126psRBPGeIIu2pm6f9l9opRnYjSbUz2+6
7146zhUJaHyC82y+Hz2MBDbQ8ou8vG8aPWmP1qYFDTrSJ/WsG4KDWnjSoiLvncUH
mGmTKEqr+GU=
=AdaB
-----END PGP SIGNATURE-----

--------------enigA38797289E0C0497241873A8--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C3v77E067479 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 20:57:08 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5C3v7Jh067478; Thu, 11 Jun 2009 20:57:07 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C3uuH1067466 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Jun 2009 20:57:07 -0700 (MST) (envelope-from [email-masked])
Received: from grover.home.jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n5C3utA5001273 for ; Thu, 11 Jun 2009 23:56:55 -0400
Message-Id:
From: David Shaw
To: IETF OpenPGP Working Group
In-Reply-To: <[email-masked]>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Re: openpgplint: encouraging best practices for OpenPGP keys today
Date: Thu, 11 Jun 2009 23:56:55 -0400
References: <[email-masked]> <[email-masked]> <[email-masked]>
X-Mailer: Apple Mail (2.935.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

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

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C3Joj6065989 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 20:19:50 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5C3Jn0J065988; Thu, 11 Jun 2009 20:19:49 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n5C3JmW5065981 for ; Thu, 11 Jun 2009 20:19:49 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 73044 invoked from network); 12 Jun 2009 03:19:48 -0000
Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay01.pair.com with SMTP; 12 Jun 2009 03:19:48 -0000
X-pair-Authenticated: 216.254.116.241
Message-ID: <[email-masked]>
Date: Thu, 11 Jun 2009 23:19:40 -0400
From: Daniel Kahn Gillmor
Reply-To: IETF OpenPGP Working Group
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: IETF OpenPGP Working Group
Subject: Re: openpgplint: encouraging best practices for OpenPGP keys today
References: <[email-masked]> <[email-masked]>
In-Reply-To: <[email-masked]>
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enigE003C9B51021878112973C12"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigE003C9B51021878112973C12
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Thanks for the feedback, Daniel.

On 06/11/2009 10:52 PM, Daniel Franke wrote:
> Daniel Kahn Gillmor writes:
>=20
>> [selfsig-primary]
>> The most recent self-sig over the User ID identified in [valid-uid]
>> should be marked as the primary User ID.
>=20
> 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 thei=
r
>> most recent binding signatures) should be visible from keyservers in t=
he
>> current Web of Trust (maybe this would be a network check against the
>> SKS pool?).
>=20
> 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 uploa=
d
> it. Some people might only use PGP among a small, well-delineated grou=
p
> 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.

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?

=46rom 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 sa=
ys:

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

--------------enigE003C9B51021878112973C12
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSjHJUczS7ZTSFznpAQr8bg/+OCfkoL56RwCJY9YZuJLqyVh1UjOtk5Pn
UT0BLOrtu27ZM+ihGGtLHuel2/D6hx6B2NR3ntzqHyhkBq95vseyGo7vV4NV24E2
O1kJRpDXc1WbYYiRZL6WFkufcQS5zWlNbPFY/Ei5Vam4DFBXd/dOKuD9Kn2YBCk5
rYphbhu2hEicLT6wPAXAip5kEhPkid14Sjq+3DcZWG0GfuCrs66XxnIpqWNLZSDx
JFY8akPQDyRKYyZ5USVveBrhphYOdrhY893+rdeCqXCB2N/h4/HskIw6SkFACvwD
DwUy1wgrVd/gpM89Een1WwUV8CNS/Tr4NzQ/p0PqvCpAdkz3XPdPxLbp7ZxLWDpn
TIOcSkIqxwYHnLHtqQQyWHwC3HjuzM+CAINLzc+CrrNKVJOsZboRs7aEvBHTYuvx
UkCwxnKqQCl+bGNF31zOmqEEohBrk29s1ytbJKT8WzIMychvv+hiIG0hyAt1xbfM
GhM1Mg3BlbcXl+uzZSgCDJQzwRkMJf7vajODix/xUz4WzRYDGpl6cbDXqThAyvs3
9UDOMPx+DP5kOUm/alAqEySkqYuKcphXsF3nGTJUZp5yIPy/NT9SXutJZza6TKZt
c99B0+n9sND0C3oXpsZ1vpzNLEG0n9cH4bHVKtsfE7Tx6pdFNAzZzVsCQn775+LD
LqzpzApesCk=
=IcgO
-----END PGP SIGNATURE-----

--------------enigE003C9B51021878112973C12--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C2r7bY064621 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 19:53:07 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5C2r74b064620; Thu, 11 Jun 2009 19:53:07 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from mho-01-ewr.mailhop.org (mho-01-ewr.mailhop.org [204.13.248.71]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C2qrCE064603 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 11 Jun 2009 19:53:07 -0700 (MST) (envelope-from [email-masked])
Received: from adsl-99-185-244-26.dsl.pltn13.sbcglobal.net ([99.185.244.26] helo=feanor.dfranke.us) by mho-01-ewr.mailhop.org with esmtpa (Exim 4.68) (envelope-from ) id 1MEwsv-000DcM-1F; Fri, 12 Jun 2009 02:52:53 +0000
Received: by feanor.dfranke.us (Postfix, from userid 1000) id 443982D63EB; Thu, 11 Jun 2009 19:52:49 -0700 (PDT)
X-Mail-Handler: MailHop Outbound by DynDNS
X-Originating-IP: 99.185.244.26
X-Report-Abuse-To: [email-masked] (see http://www.dyndns.com/services/mailhop/outbound_abuse.html for abuse reporting information)
X-MHO-User: U2FsdGVkX198dp7dJ+Zw/0K+jIOwF/Q2
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=dfranke.us; s=default; t=1244775169; bh=U87Q4aIJa5dX4mPUaapUbJ7mRMdxrMvKZWvDsDU4J8w=; h=From:To:Cc:Subject:References:Date:In-Reply-To:Message-ID: MIME-Version:Content-Type; b=oAkF+VpuMCXYDtxxPsYnti9Tr8M04xRYAF7mh VntqWFGgomZ12EOrPk8DGjgqaiXegm5hOVCI7iMKQaE9F1bEjAF5yFH8qyv3Db89O44 a/TNpm26Lm8O/XPdhqmQ40Hz58HXapZNQkAeVklk8FTnzRQmmhn2hAQksc0r88zDvOT Eh6VPFwiizkC9Dwr2PQ7vm/spkaS5XmfhtsOITlEbYulWTybAOjwMyleeV0zuXeitWp L+UJsufIoAzlDeCHGydoNZKs5Y4KU1RT32IWHgo3CIXbFiUmmQgmXObHknJ3gCO/EbH jWSjACiZGe2olaijBHNZ3Q0WBYnf9G4d+cMAQ==
From: Daniel Franke
To: Daniel Kahn Gillmor
Cc: IETF OpenPGP Working Group
Subject: Re: openpgplint: encouraging best practices for OpenPGP keys today
References: <[email-masked]>
X-Hashcash: 1:26:090612:[email-masked]::9dJu0191HtlkAi6J:00000000000000000000000000000000000000000+bs
X-Hashcash: 1:26:090612:[email-masked]::U1ci30/8jYiZt3MI:00000000000000000000000000000000000000001IDqn
Date: Thu, 11 Jun 2009 19:52:49 -0700
In-Reply-To: <[email-masked]> (sfid-20090611_19231_D5F99169) (Daniel Kahn Gillmor's message of "Thu, 11 Jun 2009 22:14:49 -0400")
Message-ID: <[email-masked]>
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.94 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

Daniel Kahn Gillmor 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 [email-masked] http://www.dfranke.us
|----| =|\ \\\\
|| * | -|-\--------- Man is free at the instant he wants to be.
-----| =| \ /// --Voltaire

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n5C2FB65063165 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 11 Jun 2009 19:15:11 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n5C2FB8c063164; Thu, 11 Jun 2009 19:15:11 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from relay01.pair.com (relay01.pair.com [209.68.5.15]) by balder-227.proper.com (8.14.2/8.14.2) with SMTP id n5C2F0BG063147 for ; Thu, 11 Jun 2009 19:15:10 -0700 (MST) (envelope-from [email-masked])
Received: (qmail 63791 invoked from network); 12 Jun 2009 02:14:58 -0000
Received: from 216.254.116.241 (HELO ?192.168.13.75?) (216.254.116.241) by relay01.pair.com with SMTP; 12 Jun 2009 02:14:58 -0000
X-pair-Authenticated: 216.254.116.241
Message-ID: <[email-masked]>
Date: Thu, 11 Jun 2009 22:14:49 -0400
From: Daniel Kahn Gillmor
User-Agent: Mozilla-Thunderbird 2.0.0.19 (X11/20090103)
MIME-Version: 1.0
To: IETF OpenPGP Working Group
Subject: openpgplint: encouraging best practices for OpenPGP keys today
X-Enigmail-Version: 0.95.7
OpenPGP: id=D21739E9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="------------enig4AF5005E42E5756B979B7A5C"
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig4AF5005E42E5756B979B7A5C
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

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

--------------enig4AF5005E42E5756B979B7A5C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQIVAwUBSjG6H8zS7ZTSFznpAQpG2A//dYF08e3hfPLn1w4EJtup4Vg02x/O8qph
jEmmGLlbP1U8VyL2PS43mIKP2WkAi0M2cb3btOv5tmaHgYOBJv4uMCYgRwnvHgdD
FYQutCLS7KGKjvnEKDt78/DS2Tuu4zXrz7QfwQAmXz3QQ0WHqg6txdTGEBb6rXIj
XYZYWoVCAaATqZWrvZRclWuCRHJnc8/ecGmCmMlpw3inaKNoSxjqtgyRRuw9AKer
VcGEz+Icj0CWGVDyYtKKcrxEkH0OwGDTiwDJLzQUhcGzybB7zzVxmuF8tTzL3PeR
oPuOVkACVfgokN1O6dZc26o5CGmY3EOnp2KF3bHAXhdifYS5wX2XtCwsxoNYYO8N
rfRWTXGnlS4+BL8LPj/jkAqqJQpSjRSNmf5qCg8YMc/+O3lz2EFzo7xBROZYmglo
dxlTjbiicNPs50QvG075mUz/AZbZhdPQCR21S8N5VXNBcZ9vjmzBlkcTXimY7yu/
roVZjiUiG/Lr+6/f88T/bjRltz2pN6bu7F+D5AVQRrsEEi6wrkrc1mhGNvQzdf5L
2KwXa+wUrQQsIcD/ukqygeA8HlZiDMAUj+ZC+L+e+TKPcLRifSQ6dVCAamVJWIpU
BboX+kBJgDHP1RQXlZfGH8y6JgpGVmcooKrQ+Yz28jVXU3Nk+7VcBriGmIIEqLzf
IlPFf9BhqIU=
=FZy/
-----END PGP SIGNATURE-----

--------------enig4AF5005E42E5756B979B7A5C--

Received: from balder-227.proper.com (localhost [127.0.0.1]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n54CqG2l046538 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 4 Jun 2009 05:52:17 -0700 (MST) (envelope-from [email-masked])
Received: (from majordom@localhost) by balder-227.proper.com (8.14.2/8.13.5/Submit) id n54CqG5Z046537; Thu, 4 Jun 2009 05:52:16 -0700 (MST) (envelope-from [email-masked])
X-Authentication-Warning: balder-227.proper.com: majordom set sender to [email-masked] using -f
Received: from walrus.jabberwocky.com (walrus.jabberwocky.com [173.9.29.57]) by balder-227.proper.com (8.14.2/8.14.2) with ESMTP id n54Cq5Jh046528 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 4 Jun 2009 05:52:16 -0700 (MST) (envelope-from [email-masked])
Received: from grover.home.jabberwocky.com (grover.home.jabberwocky.com [172.24.84.28]) by walrus.jabberwocky.com (8.14.3/8.14.3) with ESMTP id n54Cq4EK011301 for ; Thu, 4 Jun 2009 08:52:04 -0400
Message-Id: <[email-masked]>
From: David Shaw
To: IETF OpenPGP Working Group
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Subject: Camellia for OpenPGP RFC published
Date: Thu, 4 Jun 2009 08:52:04 -0400
X-Mailer: Apple Mail (2.935.3)
Sender: [email-masked]
Precedence: bulk
List-Archive:
List-Unsubscribe:
List-ID:

A new Request for Comments is now available in online RFC libraries.

RFC 5581

Title: The Camellia Cipher in OpenPGP
Author: D. Shaw
Status: Informational
Date: June 2009
Mailbox: [email-masked]
Pages: 3
Characters: 5129
Updates: RFC4880

I-D Tag: draft-ietf-openpgp-camellia-04.txt

URL: http://www.rfc-editor.org/rfc/rfc5581.txt

This document presents the necessary information to use the Camellia
symmetric block cipher in the OpenPGP protocol. This memo provides
information for the Internet community.

INFORMATIONAL: This memo provides information for the Internet
community.
It does not specify an Internet standard of any kind. Distribution of
this memo is unlimited.