Re: [openpgp] Privacy-preserving Transferable Public Keys
Werner Koch <wk@gnupg.org> Fri, 14 June 2019 08:40 UTC
Return-Path: <wk@gnupg.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 0169C120110 for <openpgp@ietfa.amsl.com>; Fri, 14 Jun 2019 01:40:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.999
X-Spam-Level:
X-Spam-Status: No, score=-6.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OPfsnp2rvkwM for <openpgp@ietfa.amsl.com>; Fri, 14 Jun 2019 01:40:10 -0700 (PDT)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::22]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 45F73120086 for <openpgp@ietf.org>; Fri, 14 Jun 2019 01:40:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=x80Hncl4gCHKQPPYqq8glKa/KI+5c/cdHr219k+7PzY=; b=dAdFHZUbIaxzkUbu9t1SK74mYJ 0dlmQjwN6zDJiT4Sp9R8aZFZeVN78x0M0NVFH7FPXgbZ6o83x7XFMRWYB/DrgaSsBoXqOgnVb9mJA M9UjLDpnO29mjLZe+8JD6L0Ba32ldf72lZNY843hlLlXwibjFqZgasSzMn9qn9oEkI0Y=;
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1hbhkm-00051C-Ik for <openpgp@ietf.org>; Fri, 14 Jun 2019 10:40:08 +0200
Received: from wk by wheatstone.g10code.de with local (Exim 4.92 #5 (Debian)) id 1hbhhn-0004As-Kv; Fri, 14 Jun 2019 10:37:03 +0200
From: Werner Koch <wk@gnupg.org>
To: Vincent Breitmoser <look@my.amazin.horse>
Cc: openpgp@ietf.org
References: <3LBKVNEMXC3DV.3JS3W5ZE7TFEZ@my.amazin.horse>
Organisation: GnuPG e.V.
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Mail-Followup-To: Vincent Breitmoser <look@my.amazin.horse>, openpgp@ietf.org
Date: Fri, 14 Jun 2019 10:36:57 +0200
In-Reply-To: <3LBKVNEMXC3DV.3JS3W5ZE7TFEZ@my.amazin.horse> (Vincent Breitmoser's message of "Fri, 31 May 2019 09:42:21 +0200")
Message-ID: <875zp8r2ae.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=Defcon_nuclear_sneakers_FSF_Forte_TDR_Meth_Lab_CBNRC_Islamist_Nogale"; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/KNkdWqho9MGjAOPiH-WB3_8aA20>
Subject: Re: [openpgp] Privacy-preserving Transferable Public Keys
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.29
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: <https://mailarchive.ietf.org/arch/browse/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: Fri, 14 Jun 2019 08:40:12 -0000
On Fri, 31 May 2019 09:42, look@my.amazin.horse said: > A) Distribute updates to subkeys and the primary key (expiry, revocation, etc), > without revealing the key's UserIDs. Easy for new and revoked subkeys. For full revocations gpg has always allowed to import a standalone revocation self-signature. For changing expiration or preferences the user id is required or the client needs to trial verify all new self-signatures. The server won't be able to check the self-signatures if it has no access to the user-id. This will spam the users and server with bogus self-signatures. Right, direct key signatures can be used but I we have not much experience with them. > B) Distribute updates to UserIDs (expiry, revocation, etc) without revealing the > UserID itself. This is the same as A modulo direct key signatures. > C) Create, distribute, and use keys without attaching UserIDs or other > designation metadata at all Why should one want to do that? The user id (i.e. mail address or DNS name) is important meta data. However, it is better to use a direct mapping from the user id to the key than any arbitrary mapping as done by keyservers. Then any updates to the user id can be retrieved via that userid->keyblock service. > done in dkg's "abuse resistant keyserver" document, recently on this list. The simplest way to avoid DoS on keyservers is to disallowing searching by user id. That is for about 20 years standard at MTAs and although not a perfect solution it has helped a lot against mail address harvesting by asking MTAs. Shalom-Salam, Werner -- Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.
- [openpgp] Privacy-preserving Transferable Public … Vincent Breitmoser
- [openpgp] Optional User IDs Neal H. Walfield
- Re: [openpgp] Privacy-preserving Transferable Pub… Heiko Stamer
- Re: [openpgp] Privacy-preserving Transferable Pub… Werner Koch
- Re: [openpgp] Privacy-preserving Transferable Pub… Vincent Breitmoser
- Re: [openpgp] Privacy-preserving Transferable Pub… Werner Koch
- Re: [openpgp] Privacy-preserving Transferable Pub… Vincent Breitmoser