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

Bart Butler <bartbutler@protonmail.com> Tue, 13 November 2018 21:37 UTC

Return-Path: <bartbutler@protonmail.com>
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 B90E8130DE7 for <openpgp@ietfa.amsl.com>; Tue, 13 Nov 2018 13:37:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.7
X-Spam-Level:
X-Spam-Status: No, score=-1.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLYTO=1, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=protonmail.com
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 87jc1_uTqNOm for <openpgp@ietfa.amsl.com>; Tue, 13 Nov 2018 13:37:48 -0800 (PST)
Received: from mail2.protonmail.ch (mail2.protonmail.ch [185.70.40.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 C9F01130DEE for <openpgp@ietf.org>; Tue, 13 Nov 2018 13:37:47 -0800 (PST)
Date: Tue, 13 Nov 2018 21:37:33 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1542145059; bh=XRYYzcsLk9ek1dRX3vPBgFifnGnOriJ/PvOvcnGJ7uE=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=MwH/HgtslZfW7QYIz7DW+UiDNH5pZQXB4XATMRqcpGo4/9gVx0K0lYpl6HLDBPecO v5JXtw7fYW+8md48KxL0iA3mHmvcf5pijIIflM5WMr9LlZmQVeuFpiG4E1coqKCKHy CPvACT5NOeayo5+dda/vNXGxcv5tl6M0YTNAz36Y=
To: Werner Koch <wk@gnupg.org>
From: Bart Butler <bartbutler@protonmail.com>
Cc: "openpgp\\@ietf.org" <openpgp@ietf.org>
Reply-To: Bart Butler <bartbutler@protonmail.com>
Message-ID: <lVvFGxVUkBNCpL2ek6IOg0IR5V0Y94sscgd72rcoZ_obkE-9WZ6L-wz9BXlxclZ8dXoc9dCMLndA8-LVMG5vcA==@protonmail.com>
In-Reply-To: <875zx0n0j9.fsf@wheatstone.g10code.de>
References: <878t1xoz37.fsf@wheatstone.g10code.de> <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com> <875zx0n0j9.fsf@wheatstone.g10code.de>
Feedback-ID: XShtE-_o2KLy9dSshc6ANALRnvTQ9U24aqXW2ympbGschdpHbU6GYCTUCtfmGhY9HmOyP1Uweyandwh1AVDFrQ==:Ext:ProtonMail
MIME-Version: 1.0
Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha512; boundary="---------------------d791f192715410c32a6803b573952746"; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/PJjN9oswFjBnxxtGUhdWLfxVuj8>
Subject: Re: [openpgp] Web Key Directory I-D -07
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: Tue, 13 Nov 2018 21:37:51 -0000

Hi Werner,

I don't think I was very clear before so I'll try to clarify a bit. I think we are in agreement that the MUA should do all of this kind of processing exclusively and we should not do any funny business in the WKD spec about secondary UserIDs or the like. My concern was that this language:

"The key needs to carry a
   User ID packet ([RFC4880]) with that mail address."

could be read as requiring that the UserID packet in the key match the queried address exactly, and I'd like to relax that requirement to make it clear that servers can essentially serve up whichever key they choose based on how they want to route mail. Whatever checks the MUA does on this UserID is not the business of the WKD spec. Here's another suggestion:

"The key MUST carry a User ID packet ([RFC4880]) containing the email address to which mail sent to the queried email address will be routed."

which should take care of this case without implying that requested mail address must match the mail address in the UserID.

-Bart

Sent from ProtonMail, encrypted email based in Switzerland.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 13, 2018 1:13 PM, Werner Koch <wk@gnupg.org>; wrote:

> On Tue, 13 Nov 2018 21:35, bartbutler=40protonmail.com@dmarc.ietf.org
> said:
> 

> > routing in the same way for WKD as it does for incoming mail. As such,
> > things like case, subaddresses with +, catch-all, etc. will
> 

> We had some internal discussion and came to the conclusion that it is
> best to not care about sub-addresses in the protocol. It should be a
> MUA only thing and nobody should create a key for a subaddress.
> 

> With the help of Kristian I took a look at the 5.3 million keys on the
> SKS servers and we found only 3055 unique mailboxes with a '+' in it.
> After removing leading and trailing '+' as well as multiple '+'
> (e.g. "c++" or "foo+bar+baz") 2697 were left which seem to be valid
> sub-addresses.
> 

> Now this is definitely a minority and there oweners can be asked (or
> gpg-wks-client does it on the fly) to create another user-id without the
> subaddress.
> 

> To help MUAs, I started to change gpg to strip off sub-addresses; at
> least for WKD queries.
> 

> > So if I request from ProtonMail Bart.Butler@protonmail.com, I would
> > get a key back with bartbutler@protonmail.com, and the clients could
> 

> I doubt that we can do anything about this except for adding another
> user id to the key. There would be just too many cases and that simple
> protocol would be much complex to implement and also fully lose the
> property of a simple one to one match.
> 

> Shalom-Salam,
> 

> Werner
> 

> --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
> 

> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.