Re: [openpgp] keyserver protocol

"Daniel A. Nagy" <nagydani@epointsystem.org> Tue, 07 May 2013 15:44 UTC

Return-Path: <nagydani@epointsystem.org>
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 1932A21F8F53 for <openpgp@ietfa.amsl.com>; Tue, 7 May 2013 08:44:52 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.599
X-Spam-Level:
X-Spam-Status: No, score=-3.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
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 5UKhWpbXC6YD for <openpgp@ietfa.amsl.com>; Tue, 7 May 2013 08:44:47 -0700 (PDT)
Received: from mail-ee0-f46.google.com (mail-ee0-f46.google.com [74.125.83.46]) by ietfa.amsl.com (Postfix) with ESMTP id EDA7C21F8F26 for <openpgp@ietf.org>; Tue, 7 May 2013 08:44:43 -0700 (PDT)
Received: by mail-ee0-f46.google.com with SMTP id b57so403711eek.19 for <openpgp@ietf.org>; Tue, 07 May 2013 08:44:43 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:message-id:date:from:organization:user-agent :mime-version:to:subject:references:in-reply-to:x-enigmail-version :content-type:x-gm-message-state; bh=HBeKWL+a06YeCVCdXCKv3dJdPVViQOerq/r64jkf6Cs=; b=VA7JY9QUd2GSKoyJk/EHJ56jsdOA3oQ89OcbmTpucbhQnHQesOnAKO1WHrMzdyGEvV KKdKND7gjjINtAorAlKyMR55N5HHEw6Ox3qj4EGzT3hORkPYx99aWaGFVHy5pI4O8w41 Gp4Hddbwvoay4pLT+6wRBBWJVlKTJB5p1ImcBslYOY9tTVHcyGN6JfX71IjbZp/LzVMn htSHaXWfs0f19kEIUDLJKRXbaERCuzpcqm08CBCkCZz86fQ3jFwWpvqV3ehdwnOHKN/+ 8r1R7CR62cooMxZvBfQz9nvtHbO6q2rdN12ZYiJxVWx+MZqB6GJvUlhL7nrFGJvAHOWu uASQ==
X-Received: by 10.14.172.197 with SMTP id t45mr6475447eel.37.1367941482971; Tue, 07 May 2013 08:44:42 -0700 (PDT)
Received: from [192.168.1.225] (catv-178-48-114-85.catv.broadband.hu. [178.48.114.85]) by mx.google.com with ESMTPSA id x41sm31420789eey.17.2013.05.07.08.44.41 for <openpgp@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 07 May 2013 08:44:41 -0700 (PDT)
Message-ID: <51892168.3080703@epointsystem.org>
Date: Tue, 07 May 2013 17:44:40 +0200
From: "Daniel A. Nagy" <nagydani@epointsystem.org>
Organization: ePoint Systems Ltd.
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130330 Thunderbird/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>
In-Reply-To: <87zjw6keoe.fsf@alice.fifthhorseman.net>
X-Enigmail-Version: 1.4.6
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enigEE546F3FC1C5CAE64F6D2BA1"
X-Gm-Message-State: ALoCoQk9lZrgHyUAv7QEsifF8xeiVexDwTE2Go/3eQLetpM+1BvaBXx6wcWdzLXkJf3buGD3HXzg
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: Tue, 07 May 2013 15:44:52 -0000

On 05/07/2013 05:11 PM, 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:
>>
>>   http://tools.ietf.org/id/draft-shaw-openpgp-hkp-00.txt
> 
> 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"
> 
>  2) "something is broken in my database, and I'm confused"

Also, I think that it makes sense to explicitly allow for partial
implementations of the protocol. For example, one that only allows for
searching by keyID's or even just long keyID's and fingerprints. I
think, there should be a clear way to communicate that the use of an
unsupported part of the protocol has been attempted.

Bests,

Daniel