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.