Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP certificate "Intevation File Distribution Key <distribution-key@intevation.de>"
Bernhard Reiter <bernhard@intevation.de> Wed, 07 August 2019 07:53 UTC
Return-Path: <bernhard@intevation.de>
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 8BF6F120288 for <openpgp@ietfa.amsl.com>; Wed, 7 Aug 2019 00:53:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.897
X-Spam-Level:
X-Spam-Status: No, score=-1.897 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 fDnlF_YtPyPQ for <openpgp@ietfa.amsl.com>; Wed, 7 Aug 2019 00:53:38 -0700 (PDT)
Received: from kolab.intevation.de (kolab.intevation.de [212.95.107.133]) by ietfa.amsl.com (Postfix) with ESMTP id C294312024C for <openpgp@ietf.org>; Wed, 7 Aug 2019 00:53:37 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 4B6E7629E1 for <openpgp@ietf.org>; Wed, 7 Aug 2019 09:53:34 +0200 (CEST)
X-Virus-Scanned: by amavisd-new at intevation.de
Received: from kolab.intevation.de ([127.0.0.1]) by localhost (kolab.intevation.de [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 9kuy_iprF7r0 for <openpgp@ietf.org>; Wed, 7 Aug 2019 09:53:32 +0200 (CEST)
Received: from localhost (localhost [127.0.0.1]) by kolab.intevation.de (Postfix) with ESMTP id 2E30F62A07 for <openpgp@ietf.org>; Wed, 7 Aug 2019 09:53:32 +0200 (CEST)
Received: from ploto.hq.intevation.de (ploto.hq.intevation.de [192.168.11.18]) (Authenticated sender: bernhard.reiter@intevation.de) by kolab.intevation.de (Postfix) with ESMTPSA id 09DBC629D3; Wed, 7 Aug 2019 09:53:32 +0200 (CEST)
From: Bernhard Reiter <bernhard@intevation.de>
To: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Date: Wed, 07 Aug 2019 09:53:24 +0200
User-Agent: KMail/1.9.10 (enterprise35 0.20141209.518c4af)
Cc: gpg4win-users-en@wald.intevation.org, Thomas Arendsen Hein <thomas@intevation.de>, openpgp@ietf.org
References: <87ftmnro0l.fsf@fifthhorseman.net> <201908061658.09774.bernhard@intevation.de> <87k1bqp8fx.fsf@fifthhorseman.net>
In-Reply-To: <87k1bqp8fx.fsf@fifthhorseman.net>
X-KMail-QuotePrefix: >
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="nextPart7385087.78WdL7rBIZ"; protocol="application/pgp-signature"; micalg="pgp-sha1"
Content-Transfer-Encoding: 7bit
Message-Id: <201908070953.28760.bernhard@intevation.de>
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/B6qJ1NibV2VVIG1mgjfXPZYrIng>
Subject: Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP certificate "Intevation File Distribution Key <distribution-key@intevation.de>"
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: Wed, 07 Aug 2019 07:53:41 -0000
Am Dienstag 06 August 2019 18:25:38 schrieb Daniel Kahn Gillmor: > I agree that this should be clarified one way or the other. From my reading it is clear from the whole document. I agree that the phrasing can be improved at the place you were pointing out. > > If the contents is highly sensitive, the user will decide to not send. > > Otherwise the user will not care, not paying attention to the display and > > send anyway (not caring if it is encrypted or not). > > I'd love to see some studies about the usability of such a warning. The idea is not to have a "warning", but to show the state next to reach recipient and in addition combined in vicinity close to the send action element. The user can pay attention to it, but is not hassled by it either. (It would be fun and very useful to have more usability studies, but this seems unrealistic as we yet do not know how to get a solid funding for important parts of the core infrastructure like the keyserver implementation. OpenPGP implementations and the software and infrastructure for a good user experience are underfunded and have been underfunded for many years.) > how many fine gradations of "valid" is the user able to distinguish between > in an actionable way? Many, I believe, because: This is more close to how people model talking about diffent things in "real life". If you happen to say something sensitive who will check whom you are talking to and where. You would not say something bad about your school with the teacher on the next table for example. > fwiw, i agree that more explicit and opinionated guidance for > implementers would be useful here too. I would be pretty sad if that > guidance was to specify some sort of "you should be worried, but > probably you can't do anything differently to address that worry" alarm. > Alarm fatigue is a real and well-studied thing: > > https://en.wikipedia.org/wiki/Alarm_fatigue It shall be modelled not like an alarm, but as a normal situation as there are many reasons why a trust can be reduced. The issue is, that if you are really sending something sensitive you'll double check, most of the time you won't pay much attention. > > The idea with the current WKD is to solve the main use case first and > > well. And simple to implement. Other use cases can be considered > > afterwards. > > Here we have a concrete use case for an important vendor of > OpenPGP-related software, who has found that WKD didn't align with their > standard practice until an outside party brought it to their attention. Which use case and which vendor? (So far I was not aware of a use case in this conversation. The only vendor I was aware of was Gpg4win which would be us.) Getting other active pubkeys or old pubkeys can be handled by the public keyserver network. (On gnupg-devel@ I've pointed out how an improved keyserver implementation can handle necessary data privacy requirements, be de-central, transport third-party signatures, including searchable non-email ones, and defend against spamming and flooding attacks. Regards, Bernhard -- www.intevation.de/~bernhard +49 541 33 508 3-3 Intevation GmbH, Osnabrück, DE; Amtsgericht Osnabrück, HRB 18998 Geschäftsführer Frank Koormann, Bernhard Reiter, Dr. Jan-Oliver Wagner
- Re: [openpgp] WKD for OpenPGP certificate "Inteva… Daniel Kahn Gillmor
- Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP … Bernhard Reiter
- Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP … Daniel Kahn Gillmor
- Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP … Bernhard Reiter
- Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP … Bernhard Reiter
- Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP … Daniel Kahn Gillmor
- Re: [openpgp] [Gpg4win-users-en] WKD for OpenPGP … Daniel Kahn Gillmor