Re: [openpgp] keyserver protocol
Daniel Kahn Gillmor <dkg@fifthhorseman.net> Wed, 08 May 2013 04:32 UTC
Return-Path: <dkg@fifthhorseman.net>
X-Original-To: openpgp@ietfa.amsl.com
Delivered-To: openpgp@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9780321F8E62 for <openpgp@ietfa.amsl.com>; Tue, 7 May 2013 21:32:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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 mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id cSkB8lT7AdlT for <openpgp@ietfa.amsl.com>; Tue, 7 May 2013 21:32:42 -0700 (PDT)
Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108]) by ietfa.amsl.com (Postfix) with ESMTP id D77ED21F8E2C for <openpgp@ietf.org>; Tue, 7 May 2013 21:32:41 -0700 (PDT)
Received: from [192.168.13.156] (lair.fifthhorseman.net [108.58.6.98]) by che.mayfirst.org (Postfix) with ESMTPSA id 54330F979 for <openpgp@ietf.org>; Wed, 8 May 2013 00:32:40 -0400 (EDT)
Message-ID: <5189D564.4000604@fifthhorseman.net>
Date: Wed, 08 May 2013 00:32:36 -0400
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130413 Icedove/17.0.5
MIME-Version: 1.0
To: openpgp@ietf.org
References: <50E5E6AE.5050201@jcea.es> <3C32E4F1-6B48-4561-94FF-7489D44E36CC@jabberwocky.com> <87zjw6keoe.fsf@alice.fifthhorseman.net> <5189CE51.3050208@tx.rr.com>
In-Reply-To: <5189CE51.3050208@tx.rr.com>
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-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/openpgp>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=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://git.gnupg.org/gnupg.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 dbserver.ml, 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 wserver.ml 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. Regards, --dkg
- [openpgp] keyserver protocol Jesus Cea
- Re: [openpgp] keyserver protocol David Shaw
- Re: [openpgp] keyserver protocol Daniel Kahn Gillmor
- Re: [openpgp] keyserver protocol Daniel Kahn Gillmor
- Re: [openpgp] keyserver protocol Daniel A. Nagy
- Re: [openpgp] keyserver protocol John Clizbe
- Re: [openpgp] keyserver protocol Daniel Kahn Gillmor
- Re: [openpgp] keyserver protocol John Clizbe