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

Paul Fawkesley <paul@fluidkeys.com> Thu, 08 November 2018 11:08 UTC

Return-Path: <paul@fluidkeys.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 896F9130DE1 for <openpgp@ietfa.amsl.com>; Thu, 8 Nov 2018 03:08:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.121
X-Spam-Level:
X-Spam-Status: No, score=-1.121 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_MED=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=fluidkeys-com.20150623.gappssmtp.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 DMxLF8jyhOSc for <openpgp@ietfa.amsl.com>; Thu, 8 Nov 2018 03:08:28 -0800 (PST)
Received: from mail-wm1-x32d.google.com (mail-wm1-x32d.google.com [IPv6:2a00:1450:4864:20::32d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 48797130DC6 for <openpgp@ietf.org>; Thu, 8 Nov 2018 03:08:28 -0800 (PST)
Received: by mail-wm1-x32d.google.com with SMTP id f19-v6so1283403wmb.0 for <openpgp@ietf.org>; Thu, 08 Nov 2018 03:08:27 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=fluidkeys-com.20150623.gappssmtp.com; s=20150623; h=subject:to:references:from:openpgp:autocrypt:message-id:date :user-agent:mime-version:in-reply-to; bh=npx1isZ1B/PEyypUBJRm88C2IMkWhnKK+sb7yCVUCXU=; b=sZuUziTUjTeu7onOkF9sHobwvSpk4/UcsU3Wiv8h7xPmfNcnfIDFRNX6uHa9YGoPMl EgqdtkGWDoS7cz2b1al38sgDCcG+ha8TnD4QECq042K7pcAQ3RTp+L3HsAljby+04Wr6 NBqzWcWg58LVXHOr3N7u+p4L+Yt06/F38NCUBAQHvIO5VYIDNKknClggfAjHJ12UNGT0 Sp7Sxx4XZE4CPE4yz5nFgk5N2a62vGFESOY6jEY3K1ix7JvIuRnZhy2RBh4T/zIgdzfE Vy0A38hC+JvkdufTtYHRowhc8ancqECvcBPE3FB0c/B/ApYcqooDGnPMSvi4WwLxBmgY xMSA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:openpgp:autocrypt :message-id:date:user-agent:mime-version:in-reply-to; bh=npx1isZ1B/PEyypUBJRm88C2IMkWhnKK+sb7yCVUCXU=; b=FKeNegLQbP5Z6f8b7v8TRzD37rzZ42OCTDB6AFDVJ0oHpcQ8Z8a/k47I5sYoCDB7id WX090SiyRnnZJmTh3M+QD4rRgwmpVDg83Q2wdpw48gMmrBOAvK5FbiV6bDomj7/VUJNz vthqLN06UNbddrymNevvX3tMol3YZKs9TXeYcwoDcJrwb96FqQDk/5fJGYa1SXi1RVKj 9dd4SXg/S+fXNdd3UaSeGBGaZdnRjMAXghFrjgpTUp7XB9pWqlBKVKfDiBgclvNKWifX Zv0nt/dvpr7rsSnc4jrkVpht1Q3GVrXhLMOiEHemH+8WKU6yp9XYJXWa03LLN920N7f7 A2sw==
X-Gm-Message-State: AGRZ1gIhU5T8+qlMNAg6xNLDhYh8DCHNFg/VniolcGxBiPLV3UU2yFEi 9bSipaQi5rL+8/chhLK8/3JeEeNpAyL/
X-Google-Smtp-Source: AJdET5evYRkjHoo3yImaOc8BscQLx+UKLGe++wUMhVdjYpuMZYNvVUftFHM1sG4U26x+en9+2Rm2Tw==
X-Received: by 2002:a1c:9dc5:: with SMTP id g188-v6mr776283wme.141.1541675305791; Thu, 08 Nov 2018 03:08:25 -0800 (PST)
Received: from ?IPv6:2001:8b0:d5c:9cbd:495f:f7e6:35cb:3566? (6.6.5.3.b.c.5.3.6.e.7.f.f.5.9.4.d.b.c.9.c.5.d.0.0.b.8.0.1.0.0.2.ip6.arpa. [2001:8b0:d5c:9cbd:495f:f7e6:35cb:3566]) by smtp.gmail.com with ESMTPSA id l140-v6sm7505927wmb.24.2018.11.08.03.08.24 for <openpgp@ietf.org> (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 08 Nov 2018 03:08:25 -0800 (PST)
To: openpgp@ietf.org
References: <23523.16831.292658.490356@chiark.greenend.org.uk> <874lcsyr3p.fsf@wheatstone.g10code.de>
From: Paul Fawkesley <paul@fluidkeys.com>
Openpgp: preference=signencrypt
Autocrypt: addr=paul@fluidkeys.com; keydata= xsFNBFuOr7IBEADj5wnhRc07sX1rNNqEvMEZIXYZgElhxNRpN4qc4ES4Xp9rlckLIgqARyiY Nc87arYP3CIgfbTFJTy7g7q3jjbm7jmYSvpxe1J40kgbKMOjAtula2vdKzddXcgNkmDiWHsc bvoG2cxNSqx5lUU9SsPO2lVU1C44g3k0A1NgueEwus9blb2/qwHB6Zn7L/jOSM+AV6zpWeSH gRWigN+1m21GE2i09Um0W/W8WhFJDV5M4+IfYVvysReLcfFvzGJjZMlkVWOfE/nWPhBQpQOC u4Wtu5490hmtTt4/hXBrqYBDOgXFYDZAsyUgTctXUiH0/bBNWZ2hHrMWeMOvGI0p6DhGfuAk M793lttcjsWX1ff6Nz+vBSucqZnXD/tOAhFjTaWggFEMPwb8Shvy79a+0F+LP8Qk0e88y9Jn 5wSlstMee7EYx8CH1KaJuvSchyK3Dvf2QQLVJ1axPTsDrqvbtmETUN5Wo/G/sKwlXcdn8rd9 Z9iCuvremUddN75LcRSOEg2drncK95b08JP0mn4oDrmVLVskEtF24IXxkmyPVE8yH51sMpRf B7VUDS3SftCINOmH0Xh3qtRQapmMp6HJ/Bs2P3DPDLS1NK+8gPA/2vd6zlLwTqWJVJvlKoIZ GShxBb8XI7zriY6Bgmn4OaMJUB9vj3dNjjj7Cvic5gwGzEJWdQARAQABzRQ8cGF1bEBmbHVp ZGtleXMuY29tPsLBeQQTAQoALQUCW8DK0AkQcyekTCFXp1gCGwMFCQBzH04CGQEFCwkIBwMF FQoJCAsEFgIBAAAArSYQAJA3oxxceY+spH+TgTMe35R+oVquZOzdqCCyM5DLVMt7mx0LV7pX VYJwY7TweqnL5rMnz+65W6VRkluE/XQYH7Kdy7EI2KWICmAs7z1IaMZXB7KYzWB3l2YUttmf RBtgdq4xanEFKhRbFX9XyRmh1kXD/MFLHqH4F1Nkn5ZT6TtGsMc1tpTBkWOWmMbnQetSQfrQ UYCTM7o0c3S11lhqNA47uk8rAcj+DS8HRZHz5S2b4/BUVpOHqxuKGVXGqTsMY4woTPzm++jB +UYDuCVAw1HPpMIPUmmnAETyikIfyaK58v0owwn97Wdi4mFTWftEVjYbDsvfLLa0d3THTxO3 GmaVRbLCbSWisCrUP678jUfJUqalN8ZrdBBXjUMtabaVxF/gK020czCxiZIm88PzG8sxO4ln WUqqw9p1zUCV6mzFR+VmB0S4GYLsWHm9jCcdrzF397zMSNlySBE21tcNcFi1sbRKnC8hcdcT qtNx/KpNvxVAC0nvDKS6XYG3VWK6N+Aa4XAamrITu5ZG6U1AkWp7PcyXorTK9IONAEroxX99 0ANE0Bd+IKWt6baO0D5LKXXdKtpjwKSe2PZoCXd5orK/hVgamSp7GEcNUBULha9k4O8OMj8N cFXO2rJ9NgK1KFhF/1WDEcv4rskIclRhqLZ9Cz/XLzbIs9BAtOz4kRIrzsBNBFu12cIBCADN I/U4wOQzsbrXSgCj5ARkqvHYnOwtybXVi5ufP7xvnUMzghjo5QbiChVk4owYNL2sOTCl+UGw qcr0cAONFvKY04340kXHrvqbJOgY27HEs1SiopmDQ2sANydz6HB4tKrh1KXjZz9xPtEllGeq LgByGES78ZuLS8KcDWLXZ5BL2TUkT9SiULsgejqNF7DXM+8bBihTO7YolVPk9iI7dVi3NHTQ D0EVil5Ta2Ni65TfRNRvcvhH1E4bGfF84hbmmZddyq7muc0qR3xiFXIeWifxSq0iINaMjGkQ eTyWBSQA9oLJCfzBPXSt+whr8Iiu8O8fP7UcK7+lRPu5m+HJe3ghABEBAAHCwWUEGAEIABkF Alu12cIJEHMnpEwhV6dYAhsMBQkAS/U9AAAGeQ//XhOKIg04EfrMjnZ4OhLfmXZNHpzGnel1 6UWLWcXWkplO1nFi1dHnyKSedCIvMTIs3G26CCpVGF89/46ChHfKTLkwkgyhk0Lfk+5xEd4b I47KVfPGAyrfzp2NVwk6iOZ1nxM8Wo2OvmmXpSYlI2bxGj0VWDOzB0KZwyJhAUKnLf3xF3kG lZWG5hJrJidbOrAzfXDrb633oxksAl1ScSbzZ82MkJ5xEVfPSvVP+U/0vWPplIZO3f/MPI4D Yy0RmsuYqmtYxoDf3YrIC1S+mvjCRnCPzD5TfHID4iuLA3/rfvJ18aFAQGprG6IyTvm0xAnx lDu3sh6hfN1/Ugt/nrAuirXh+Ub2RFX/ZgUva4quNtiLY0kMTXgEFh1lZWaN0cdvU9s8Es33 iRUSIq3BWm6ZEd4NeqI/el3FZ7+1eLQagARUgnLKa21jyBkTyuv+LA/qKAcAJI7AelzoL2SY iBKrPzcohmfnduNM7uBmMh4TLNKCVeMd6DITqTz4xD+DMdgC32i5r/9Cgc1HT5oP+637rrcX /GS54l2EGsEvK27KhD0EiYDSbzLCHQmtS83Q1HogSHRk2GeNLC97b+eDVaa4tAaxWVU5SU5x i+pL5T+m8gsZR7wC0WZY52pCIcgmUOq4HTbu4K5zFxHCQF1taHSkwpiU1ZPm0GiG+mp3FOHz uEw=
Message-ID: <2bc2bffb-86f5-1457-c19c-bf8a541b8e92@fluidkeys.com>
Date: Thu, 8 Nov 2018 11:08:23 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.2.1
MIME-Version: 1.0
In-Reply-To: <874lcsyr3p.fsf@wheatstone.g10code.de>
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="YEoUCiQDU8DjDesd7JBCnLYkHtNZQwNHC"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/f6V8W9wKY6dt2wAq4FBOWk8wtos>
Subject: Re: [openpgp] OpenPGP Web Key Directory I-D
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: Thu, 08 Nov 2018 11:08:31 -0000

On 08/11/2018 07:18, Werner Koch wrote:
> On Wed,  7 Nov 2018 20:49, ijackson@chiark.greenend.org.uk said:
> 
>> 1. SHA-1 is obsolete.
> 
> |   The use of SHA-1 for the mapping of the local-part to a fixed string
> |   is not a security feature but merely used to map the local-part to a
> |   fixed-sized string made from a well defined set of characters.  It is
> |   not intended to conceal information about a mail address.
> 
>> 2. The use of a cryptographic hash here makes it harder for a server
>>    to conduct an appropriate lookup.  For example, if a server defines
>>    that all email addresses
>>        alice+<something>@example.com
>>    are owned by Alice, and Alice tells the server `please advertise
>>    my one OpenPGP key for all my email addresses', it is not clear how
>>    the server could implement that.
> 
> The problem here is that the client needs to know how the server handles
> this.  This is because the client should filter the returned key for a
> matching mail-addresses.

The requirement for the client to filter the return key for matching
user IDs is a fairly big blocker for us.

We (and previous large organisations I've worked in) use + aliases
feature extensively to distinguish different services, for example:

* paul+github@fluidkeys.com
* invoices+hetzner@fluidkeys.com

>  Actually we have had a discussion about this
> recently in Brussels with the outcome that for experiments we now
> appened "?l=joe.hacker" to the request.  Currently implemented servers
> will just ignore these parameters.

For experimenting, fine, but I'd prefer to get to a "production"
solution ASAP.

> 
>>
>> Suggested modification: Replace this part of the URL with the
>> URL-encoded email address.
> 
> Nope: That breaks existing implementations and would not allow to serve
> the data from static files.

To stay compatible, keep supporting static files *and* resolve the case
and aliasing issues, I'd support:

1. keep supporting sha1-z-base-32 identifier

2. additionally start supporting z-base-32 identifier with no SHA1

   2.a maybe put them at different path
   2.b don't lowercase anything before searching for these
   2.c in the client, don't filter on the user id for these

Ian, apart from z-base-32 not being exactly mainstream, does 2. work for
you?

>> II. URL domain name part
>>
>> The mail system for some domain, and its web server, are not
>> necessarily on the same host or under the same practical
>> administration.  Often webservers are outsourced.
> 
> That is rarely the case but given that I know a pretty large provider
> which has this problem, SRV records are used to overcome this problem.

Given that SRV records can't be accessed by Javascript implementations,
I don't think we can point to that as a solution

I'm recalling a large organisation I worked in that were heavy users of
PGP. I can see two options for how I could have implemented WKD there:

1. request an HTTP redirect on the root domain (this one change would
take weeks of "change control" process, with lots of signing off by line
managers etc.) Then I can run a WKD service wherever I like.

  (the hosting for different subdomains and mail server were sprawling
across many different systems and providers)

2. use a subdomain e.g. wkd.example.com (also through a lengthy change
control process to get the subdomain)

Given that we can't rely on SRV records:

> 
>> Suggested modification: the domain name part should have a fixed
>> string prepended.
> 
> This is an open question but for a different reason: Current web
> browsers have no way to lookup SRV records.

I'd support this.

I'd also support dropping the whole SRV records part to simplify the spec.

Paul