Re: [openpgp] Web Key Directory I-D -07

Benjamin Kaduk <> Thu, 15 November 2018 04:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E155E12F295 for <>; Wed, 14 Nov 2018 20:57:53 -0800 (PST)
X-Quarantine-ID: <Tu2uJg4AEubr>
X-Virus-Scanned: amavisd-new at
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by[...]
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Tu2uJg4AEubr for <>; Wed, 14 Nov 2018 20:57:51 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 26A941271FF for <>; Wed, 14 Nov 2018 20:57:50 -0800 (PST)
X-AuditID: 12074424-143ff70000002c2a-cf-5becfccb3c4a
Received: from ( []) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 11.A7.11306.CCCFCEB5; Wed, 14 Nov 2018 23:57:48 -0500 (EST)
Received: from (OUTGOING-AUTH-1.MIT.EDU []) by (8.14.7/8.9.2) with ESMTP id wAF4vkm7015261 for <>; Wed, 14 Nov 2018 23:57:47 -0500
Received: from ( []) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) œby (8.14.7/8.12.4) with ESMTP id wAF4vhNs008789 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT) for <>; Wed, 14 Nov 2018 23:57:46 -0500
Date: Wed, 14 Nov 2018 22:57:43 -0600
From: Benjamin Kaduk <>
Message-ID: <>
References: <> <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFrrGIsWRmVeSWpSXmKPExsUixCmqrXvmz5tog4XbrSwa/j1kd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXRtf3j+wFL8Qr3ky4wtTAOF+4i5GTQ0LAROJ37ybGLkYuDiGB NUwSnb/XMkM4Jxgl2tovskA4X5gkpqzZwgLSwiKgKtH86w8biM0moCLR0H2ZGcQWERCRaJu9 ix3EFhYwkJgy8x9YDS/QiqPLdjJBDOphkrh9/CMrREJQ4uTMJ2BDmQW0JG78ewlUxAFkS0ss /8cBEuYUcJLoOnsUbKaogLLE3r5D7BMY+Wch6Z6FpHsWQvcCRuZVjLIpuVW6uYmZOcWpybrF yYl5ealFuuZ6uZkleqkppZsYQcHH7qKyg7G7x/sQowAHoxIP7wmrN9FCrIllxZW5hxglOZiU RHnTwl5FC/El5adUZiQWZ8QXleakFh9ilOBgVhLhXVADVM6bklhZlVqUD5OS5mBREuf9I/I4 WkggPbEkNTs1tSC1CCYrw8GhJMH78zdQo2BRanpqRVpmTglCmomDE2Q4D9Dw+j8gw4sLEnOL M9Mh8qcYFaXEeWeBNAuAJDJK8+B6QclBInt/zStGcaBXhHmXgVTxABMLXPcroMFMQINPTH0N MrgkESEl1cCYbnRp7ZqjJu/2aW5bsi3KK1FJNLfi7fWtSp6eV324Ptyo2hgXdC3D8q+8x43X 5yMz64pKL4kGnvC/yu8Wrpnn9OzJRu75J1o3705UTH/y+qb1/WD3zZabKlnM3myLUOx2nGty m7PoWCazV/qFg/NK93WZXvrw+VzUurd+i+Yx7klUebqcf5ayEktxRqKhFnNRcSIABhlyVekC AAA=
Archived-At: <>
Subject: Re: [openpgp] Web Key Directory I-D -07
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 15 Nov 2018 04:57:54 -0000

On Wed, Nov 14, 2018 at 10:03:07PM -0500, Phil Pennock wrote:
> On 2018-11-14 at 10:26 -0500, Paul Wouters wrote:
> > On Tue, 13 Nov 2018, Bart Butler wrote:
> > > So if I request from ProtonMail, I would get a key back with, and the clients could then prompt on unrecognized types of mismatches if desired because they would know that the server is returning the canonical form of the address.
> > 
> > We went through this with OPENPGPKEY and SMIMEA. You will get the SMTP
> > people blocking your draft when you try to interpret (or like above,
> > even rewrite) addresses based on "common mail provider rewrites". Their
> > firm believe is only receiving SMTP servers can interpret email addresses.
> Bart isn't suggesting encoding common rewrites into OpenPGP, although I
> believe that Werner might be.  As an MTA maintainer, I think Bart's
> suggestion is entirely appropriate and inline with the ethos of
> federated SMTP.  I'll proceed on the assumption that my analysis of
> Bart's intent is correct.  Bart, please correct me if wrong.
> In Bart's suggestion, the WKD server, run within the same autonomous
> mail-system (or email administrative domain) as the SMTP servers, can
> decide to map addresses and return a key suitable for use for that email
> address.  This does not change where the MUA should send email, but does
> adjust how a well-integrated MUA might choose an appropriate OpenPGP key
> for use for a given email address.
> This is entirely in line with the federated design and only the owner of
> the systems at that location getting to make such decisions.  There are
> implications around caching, because such a rewrite becomes a long-term
> commitment if it's to be stored as ancillary data in the keyring for
> choosing the correct key.
> Thus if presented with a new address and needing
> to get a key for it, with Bart's proposal, the MUA and the OpenPGP
> client software can make no assumptions.  It must not normalize anything
> to the left of the '@' sign.  But the MUA can use WKD and get back a key
> for <>;; the software can then record a mapping of
> -> in OpenPGP recipient key
> selection preferences.  When later sending email to
>, the SMTP transaction proceeds unmodified: the MUA
> does not rewrite the recipient, you have to preserve the address
> as-given.  The remapped OpenPGP key selection proceeds as suggested
> though.  If sending email to then another WKD
> lookup needs to be made.  (Future work might look at protocols for
> indicating patterns to avoid repeated lookups).

I'm probably confused, but is this implying that WKD would insert a new
"lookup" operation such that a compromised WKD could cause me to encrypt a
message to an attacker-controlled key (with different UID) when I am trying
to encrypt to a non-attacker peer?