Re: [openpgp] keyserver protocol

John Clizbe <> Wed, 08 May 2013 04:02 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EE2E021F8AE2 for <>; Tue, 7 May 2013 21:02:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -0.199
X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_32=0.6, J_CHICKENPOX_51=0.6, J_CHICKENPOX_72=0.6, J_CHICKENPOX_82=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id HlPXIBMT+PZy for <>; Tue, 7 May 2013 21:02:33 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D799A21F8B38 for <>; Tue, 7 May 2013 21:02:32 -0700 (PDT)
X-Authority-Analysis: v=2.0 cv=JqNzXbEC c=1 sm=0 a=ulbKWX+3DyaA8G8Ha9A3Bw==:17 a=ehAo5EXnqZIA:10 a=XqBCkJwx3yUA:10 a=05ChyHeVI94A:10 a=M0ekKXdxTI4A:10 a=IkcTkHD0fZMA:10 a=ayC55rCoAAAA:8 a=48vgC7mUAAAA:8 a=hvCv-v4cZ4kA:10 a=69wJf7TsAAAA:8 a=q34bkTyjAAAA:8 a=pGLkceISAAAA:8 a=jFpR5k_0AAAA:8 a=QfKxxUxMAAAA:8 a=QZHjU0VWhBe4lku4iAIA:9 a=QEXdDO2ut3YA:10 a=22Nk3EchLcgA:10 a=a9n_x6BPe_4A:10 a=0QJAjy8SXTUA:10 a=hB6TBpPrBZUA:10 a=MSl-tDqOz04A:10 a=AoHxI1HT9TUA:10 a=Sat1diPe-X4v6ftc:21 a=kugy_II1io-qu3kb:21 a=ulbKWX+3DyaA8G8Ha9A3Bw==:117
X-Cloudmark-Score: 0
Received: from [] ([] helo=[]) by (envelope-from <>) (ecelerity r()) with ESMTP id F0/FB-16585-65EC9815; Wed, 08 May 2013 04:02:31 +0000
Message-ID: <>
Date: Tue, 07 May 2013 23:02:25 -0500
From: John Clizbe <>
Organization: GingerBear Conspiracy Theories To Go
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:20.0) Gecko/20100101 Firefox/20.0 SeaMonkey/2.17.1
MIME-Version: 1.0
References: <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Subject: Re: [openpgp] keyserver protocol
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 08 May 2013 04:02:37 -0000

Hash: SHA256

Daniel Kahn Gillmor wrote:
> On Thu 2013-01-03 17:53:15 -0500, David Shaw wrote:
>> I actually wrote this up at one point as an informational draft, but 
>> for one reason or another didn't finish submitting it.  If there is 
>> interest, I can clean it up and submit:
> David, i would like to see this picked back up if possible.  Is there a 
> way that i can help?
> In particular, I would like to see the error signalling and semantics be 
> more clearly and explicitly defined, so that (for example) when a 
> keyserver has a problem the user agents (e.g. client tools like gpg 
> --refresh) have a clear way to distinguish between cases like:
> 0) "I have no key material matching this name/keyid at all"
> 1) "I have too many keys that match this search to bother you with an 
> insanely long list"

You /must/ mean documenting how those two are already implemented?

X-HKP-Results-Count: number of matching keys
Content-Length: number of bytes in resulting keys

- From the SKS CHANGELOG(+) and Mercurial commit log(+>):

+ 1.1.4
+   - Fix X-HKP-Results-Count so that limit=0 returns no results, but include
+     the header, to let client poll for how many results exist, without
+     retrieving any. Submitted by Phil Pennock. See:

+> changeset:   115:47835fd59b63
+> parent:      113:73ba20267254
+> user:        Phil Pennock <>;
+> date:        Sat Apr 21 18:24:46 2012 -0500
+> files:
+> description:
+> Limit fix for limit=0
+> Return real status text strings, rather than confusing "500 OK".
+> Handle No_results as an exception type, giving 404 instead of 500.
+> Treat limit of -1 (or <0) as "unlimited".
+> Handle limit=0 so that can ask for number of results without getting results.
+> From email submission:
+> Back when X-HKP-Results-Count: was discussed, David Shaw suggested that
+> limit=0 should return no results, but include the header, to let a
+> client poll for how many results exist, without retrieving any.  See:
+> Please find attached a patch. Plus a couple of related cleanups in HTTP error
+> response handling.

+ 1.1.2:
+  - Johan van Selst's patch implementing Phil Pennock's suggestion
+       of an X-HKP-Results-Count: header to returned web server queries
+   - Johan van Selst's patch to add Content-length header to web results

+> changeset:   49:68f88ae59b6a
+> user:        John Clizbe <>;
+> date:        Thu Nov 04 02:37:31 2010 -0500
+> files:
+> description:
+> Johan van Selst's patch implementing Phil Pennock's suggestion
+> of an X-KHP-Results-Count: header to returned web server queries
+> changeset:   48:e6d918ac4c66
+> user:        John Clizbe <>;
+> date:        Wed Nov 03 21:58:51 2010 -0500
+> files:
+> description:
+> Johan van Selst's patch to add Content-length header to web results

> 2) "something is broken in my database, and I'm confused"

Could you /maybe just possibly/ tie this down to something like a real error
condition instead of something so ambiguous?  Taking a look at lines 245-307
of may be helpful.

- -John

PS: Dan, please DO NOT CC me on replies to the list.

- -- 
John P. Clizbe                      Inet: John (a) Gingerbear DAWT net
SKS/Enigmail/PGP-EKP                  or: John ( @ ) Enigmail DAWT net
FSF Assoc #995 / FSFE Fellow #1797  hkp://  or

Q:"Just how do the residents of Haiku, Hawai'i hold conversations?"
A:"An odd melody / island voices on the winds / surplus of vowels"

- -- 
John P. Clizbe                   Inet:   JPClizbe(a)comcast DOT nyet
Golden Bear Networks             PGP/GPG KeyID: 0x608D2A10
"Be who you are and say what you feel because those who mind don't matter
and those who matter don't mind." - Dr Seuss, "Oh the Places You'll Go"

Version: GnuPG v1.4.9 (Darwin)
Comment: When cryptography is outlawed, bayl bhgynjf jvyy unir cevinpl!
Comment: Be part of the £33† ECHELON -- Use Strong Encryption.
Comment: It's YOUR right - for the time being.
Comment: Using GnuPG with SeaMonkey -