Re: [openpgp] keyserver protocol

Daniel Kahn Gillmor <> Wed, 08 May 2013 04:32 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9780321F8E62 for <>; Tue, 7 May 2013 21:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=-0.600, BAYES_00=-2.599, J_CHICKENPOX_72=0.6, J_CHICKENPOX_82=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cSkB8lT7AdlT for <>; Tue, 7 May 2013 21:32:42 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id D77ED21F8E2C for <>; Tue, 7 May 2013 21:32:41 -0700 (PDT)
Received: from [] ( []) by (Postfix) with ESMTPSA id 54330F979 for <>; Wed, 8 May 2013 00:32:40 -0400 (EDT)
Message-ID: <>
Date: Wed, 08 May 2013 00:32:36 -0400
From: Daniel Kahn Gillmor <>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130413 Icedove/17.0.5
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.5.1
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="----enig2QTCAAXGGIMIFEGPWWJAJ"
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:32:46 -0000

Thanks for these details, John.  This is exactly the sort of thing that
i wanted to start getting fleshed out.

On 05/08/2013 12:02 AM, John Clizbe wrote:
> Daniel Kahn Gillmor wrote:
>> 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?

well, this is how they're implemented in SKS, which is the defacto
reference implementation, for sure.  so yes, documenting this in the
only public spec of the HKP protocol would be good.

> X-HKP-Results-Count: number of matching keys

This header (i think you're implying that it is an HTTP response header)
doesn't seem to be used at all in GnuPG if i'm searching
git:// properly.

I know there are other HKP client implementations but (like sks on the
server side) gnupg is a sort of defacto reference implementation.  If
it's not making use of this header, then it probably needs to be better
documented and patches pushed to gpg.

What should a responsible client do or assume if this header is absent
from an HKP response?

How should a responsible client respond if X-HKP-Results-Count is
greater than the limit query parameter?  for that matter, limit itself
doesn't seem to be documented in draft-shaw-openpgp-hkp-00.  This seems
like another detail worth including in any update.  looking in, i don't see any corresponding offset= query parameter.  so
if X-HKP-Results-Count == limit + 2, if an HKP client wants to get the
last two that were beyond the limit, they have to re-fetch the whole
list of keys.  Is that right?

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

I'm thinking here of the protocol from the perspective of an HKP client;
i don't think a client should need to know the gory details of how any
particular HKP server is implemented in order to be able to interact
with it robustly.  While we may decide that there are certain error
cases that are common enough (or dangerous enough) to call them out
specifically in the protocol spec, it seems simplest to start by
specifying a general error code that we expect to be interpreted as
"Server broken, please try again later or try someone else" (perhaps
this is HTTP's "500 Internal Server Error").  It would also be useful to
provide guidance for how we expect a responsible HKP client to respond
to that error state.

For those of us who run sks or other keyservers behind reverse proxies,
there may also be system errors that come into play at the proxy level.
 So having an explicit understanding of what sorts of errors HKP clients
expect to see and how they should handle them would help to inform best
practices for reverse proxy configuration.

It might turn out that these answers are all very simple.  that's great!
 in that case, let's document them explicitly, and then we can set about
testing the various HKP clients and reverse proxies to ensure that they
behave reasonably in the face of the expected range of responses.