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

Phil Pennock <> Thu, 15 November 2018 03:03 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9819512777C for <>; Wed, 14 Nov 2018 19:03:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key) header.b=vSWTc+qs; dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.b=349ebs2L
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cBCDP2vZX5Rq for <>; Wed, 14 Nov 2018 19:03:27 -0800 (PST)
Received: from ( [IPv6:2a02:898:31:0:48:4558:736d:7470]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id E3D1512426A for <>; Wed, 14 Nov 2018 19:03:26 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;; s=d201811; h=In-Reply-To:Content-Type:MIME-Version:References :Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc: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=ZuQG3eJ2qve/BDrDgrBSNWXjOpEd3viYMqzHWKRi9/E=; b=vSWTc+qspNe48TWNIIOAfiTVF4 KdBPXXk5KidUf6ZfoRlkohYqp0U/0HmFJNpFF5aanXH52wUDsmoxEPWvgEzk80fbWmcaQgAZPnD3Q WGLtvwsgzwm1MjVxbo3PMeKcfZ3CykEVFZwLxPCBUwnhQo5VOA0kAnakdFebKNTfsfB3ZSWX/3ACO hykXoMSaANapYuwqZHxvle56C0IxvqWh7qFv8y8tGa94cFLe4OGzalMVJTAY0g0NEtn3J4jGHXpoQ hkdiz9wzAju7IgkNOj1JlKxT1TnU8k0TYQrYC1qaTdB6lzXV8gBcQFq4HIG/p0MSYbIfFZ+yuRmzQ 7s18p7HQ==;
DKIM-Signature: v=1; a=ed25519-sha256; q=dns/txt; c=relaxed/relaxed;; s=d201811e2; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc: 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=ZuQG3eJ2qve/BDrDgrBSNWXjOpEd3viYMqzHWKRi9/E=; b=349ebs2Luuzu1m9Ltq5stHu7g w6Z7sW3DLzmu1FnUysYWHqgvzpEjlh4tVGVuRUBKmzOal/9wCSYp16VPcUhAw==;
Received: from authenticated user by with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) id 1gN7w6-0008tq-Hk; Thu, 15 Nov 2018 03:03:19 +0000
Date: Wed, 14 Nov 2018 22:03:07 -0500
From: Phil Pennock <>
Message-ID: <>
References: <> <> <>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <>
OpenPGP: url=
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 03:03:28 -0000

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).

Because server-side mapping decisions are being held elsewhere, and
because people do change PGP keys (in particular: security teams which
cycle their keys annually) this does suggest that the HTTP cache control
expiration headers might play into SHOULD controls on how the OpenPGP
client expires mappings and puts in place refresh checks.

The spirit of Bart's proposal, as I read it, is a great fit for the
autonomy of mail administrative domains.