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

Bart Butler <bartbutler@protonmail.com> Tue, 13 November 2018 20:35 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 26127130E73 for <openpgp@ietfa.amsl.com>; Tue, 13 Nov 2018 12:35:27 -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 mmfam7RimlAU for <openpgp@ietfa.amsl.com>; Tue, 13 Nov 2018 12:35:23 -0800 (PST)
Received: from mail-40132.protonmail.ch (mail-40132.protonmail.ch [185.70.40.132]) (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 4B69E130E37 for <openpgp@ietf.org>; Tue, 13 Nov 2018 12:35:23 -0800 (PST)
Date: Tue, 13 Nov 2018 20:35:15 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1542141316; bh=kYSkk4SziVLz7l/RWXn+AT6pZcjPeVU9TqEie/QF8qU=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=VY/+cdpYm+SLwVoYA/7ZvgBc6esyIbh67Z7iSpP+oirkfQsY3cHZgx0mteo13VbsW v8J+ei4/LcIIIUPKHsaYO4IeisqLtjW5hVvrtdVKysRizaFS68UbD3WY729NJjn+m9 92MtEz6omaJhSwHntK0+6upwDlMV3a1z1137v1Rc=
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: <9J2v287mmh9FWFLrXjxZGnVjA8HNCHpPc2wyEDDqhGeKAhE7grR6JKFMRoHJfKSq9qcjDGRNfoJ5sEODERtP0Q==@protonmail.com>
In-Reply-To: <878t1xoz37.fsf@wheatstone.g10code.de>
References: <878t1xoz37.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="---------------------2819441be6cb66b394ba59864cb98816"; charset="UTF-8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/JCZ3tDKgXgWsD2b3tzlNAYWLfcc>
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 20:35:35 -0000

Hi Werner,

Thanks for making these changes! On first read my only comment is about this line:

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

I think this statement is a little vague, as one of the reasons for providing the unchanged local part was to allow the server to do routing in the same way for WKD as it does for incoming mail. As such, things like case, subaddresses with +, catch-all, etc. will necessarily sometimes return a key with a UserID packet which does not exactly match the local part used to query.

I was wondering what you think about saying something like:

The key MUST carry a
   User ID packet ([RFC4880]) with what the server considers the canonical form of the requested mail address.

So if I request from ProtonMail Bart.Butler@protonmail.com, I would get a key back with bartbutler@protonmail.com, 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.

-Bart

Sent from ProtonMail, encrypted email based in Switzerland.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
On Tuesday, November 13, 2018 6:02 AM, Werner Koch <wk@gnupg.org> wrote:

> Hi!
> 

> A new revision of the Web Key Directory I-D has been published:
> 

> https://www.ietf.org/id/draft-koch-openpgp-webkey-service-07.txt
> 

> Changes since -06 are:
> 

> -   Specify the advanced method with the openpgpkey sub-domain.
>     

> -   Specify the l=LOCAL-PART query parameter.
>     

> -   Require the provider to filter the key for publication.
>     

> -   Drop the use of DNS SRV records.
>     

>     See below for the gist of the change. GnuPG master implements the new
>     advanced method. You may use my address for testing. For now the SRV
>     method is still used as a fallback by GnuPG.
>     

>     Note that the domain name is now also part of the file name if the
>     openpgpkey sub-domain is used. This should make it easier to server the
>     directory for several domains from a single server. This sub-domain
>     approach is similar to Mozilla's mail auto configuration [1].
>     

>     Shalom-Salam,
>     

>     Werner
>     

>     --8<---------------cut here---------------start------------->8---
>     There are two variants on how to form the request URI: The advanced
>     and the direct method. Implementations MUST first try the advanced
>     method. Only if the required sub-domain does not exist, they SHOULD
>     fall back to the direct method.
>     

>     The advanced method requires a sub-domain with the fixed name
>     "openpgpkey" is created and queried. It constructs the URI from the
>     concatenation of these items:
>     

>     o The scheme "https://",
>     

>     o the domain-part,
>     

>     o the string "/.well-known/openpgpkey/",
>     

>     o the domain-part in lowercase,
>     

>     o the string "/hu/",
>     

>     o the above constructed 32 octet string,
>     

>     o the unchanged local-part as a parameter with name "l" using proper
>     percent escaping.
>     

>     An example for such an advanced method URI to lookup the key for
>     Joe.Doe@Example.ORG is:
>     

>     https://openpgpkey.example.org/.well-known/openpgpkey/
>     example.org/hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe
>     

>     (line has been wrapped for rendering purposes)
>     

>     The direct method requires no additional DNS entries and constructs
>     the URI from the concatenation of these items:
>     

>     o The scheme "https://",
>     

>     o the domain-part,
>     

>     o the string "/.well-known/openpgpkey/hu/",
>     

>     o the above constructed 32 octet string,
>     

>     o the unchanged local-part as a parameter with name "l" using proper
>     percent escaping.
>     

>     Example for a direct method URI:
>     

>     https://example.org/.well-known/openpgpkey/
>     hu/iy9q119eutrkn8s1mk4r39qejnbu3n5q?l=Joe.Doe
>     

>     (line has been wrapped for rendering purposes)
>     

>     [...]
>     The benefit of the advanced method is its greater flexibility in
>     setting up the Web Key Directory in environments where more than one
>     mail domain is hosted. DNS SRV resource records, as used in earlier
>     specifications of this protocol, posed a problem for implementations
>     which have only limited access to DNS resolvers. The direct method
>     is kept for backward compatibility and to allow providing a Web Key
>     Directory even with without DNS change requirements.
>     --8<---------------cut here---------------end--------------->8---
>     

> 

> [1]https://developer.mozilla.org/en-US/docs/Mozilla/Thunderbird/Autoconfiguration
> 

> --
> 

> Die Gedanken sind frei. Ausnahmen regelt ein Bundesgesetz.