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

Werner Koch <wk@gnupg.org> Thu, 08 November 2018 07:20 UTC

Return-Path: <wk@gnupg.org>
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 275D51294D7 for <openpgp@ietfa.amsl.com>; Wed, 7 Nov 2018 23:20:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7
X-Spam-Level:
X-Spam-Status: No, score=-7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=gnupg.org
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 Mm65Q4rt2nYr for <openpgp@ietfa.amsl.com>; Wed, 7 Nov 2018 23:20:10 -0800 (PST)
Received: from kerckhoffs.g10code.com (kerckhoffs.g10code.com [IPv6:2001:aa8:fff1:100::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 776FD1294D0 for <openpgp@ietf.org>; Wed, 7 Nov 2018 23:20:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnupg.org; s=20181017; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To: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=K6L3YYI+UkYetvHDsfH+iv98SmJ37d3+h3X4vpb0o/w=; b=fuOA/qgIXXjKsHKC5IGY+w2U64 THZKmBhMLQrClvtiUr1BKcPQKBZ5yaSgxoQfCYBTNNQd+J5BZeecISDj6etwSEd+ycJdXsQDB9khF 2i9LatN8e3Q3VW43abdqU0oTQ/pLsDrS9j0xkYX9fenRz1z64CQZSeUjPuI5oDDETyZE=;
Received: from uucp by kerckhoffs.g10code.com with local-rmail (Exim 4.89 #1 (Debian)) id 1gKebo-0008Ri-Vn for <openpgp@ietf.org>; Thu, 08 Nov 2018 08:20:09 +0100
Received: from wk by wheatstone.g10code.de with local (Exim 4.84 #3 (Debian)) id 1gKeaJ-0002n1-Ce; Thu, 08 Nov 2018 08:18:35 +0100
From: Werner Koch <wk@gnupg.org>
To: Ian Jackson <ijackson@chiark.greenend.org.uk>
Cc: openpgp@ietf.org
References: <23523.16831.292658.490356@chiark.greenend.org.uk>
Organisation: GnuPG e.V.
X-message-flag: Mails containing HTML will not be read! Please send only plain text.
Mail-Followup-To: Ian Jackson <ijackson@chiark.greenend.org.uk>, openpgp@ietf.org
Date: Thu, 08 Nov 2018 08:18:34 +0100
In-Reply-To: <23523.16831.292658.490356@chiark.greenend.org.uk> (Ian Jackson's message of "Wed, 7 Nov 2018 19:49:19 +0000")
Message-ID: <874lcsyr3p.fsf@wheatstone.g10code.de>
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=top_secret_Roswell_Ortega_Firefly_president_data_haven_United_Nation"; micalg=pgp-sha256; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/3IQQZkZHFXj5vVRDCPvsOGIYkE8>
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 07:20:12 -0000

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

> 2a. The cryptographic hash does not, however, provide any significant
>    degree of useful obfuscation since a search will usually be able to
>    reverse it.

See above

> 2b. The cryptographic hash is not needed for space reasons since URLs
>    can easily be as long as email addresses.

Right.  A constant length can make implementations easier. YMMV.
Further there is no limit on the length of the local part of the
addrspec.  It may well exceed the max. length of file names.


> 3. Supposing the hash were to be retained, choice of base-32 rather
>   than base-64 is unusual and needs to be justified.

Easy: The standard Base-64 includes a slash and thus the has can't be
used as a file name.

> 4. The lowercasing of the email address is contrary to the Internet
>    mail specifications, where case-sensitivity of the email address
>    is up to the mail domain in question.  If the email address were
>    not obfuscated by hashing it would be easy for the webserver to
>    handle case-sensitivity by URL remapping.

See my reply to Brian and above.

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

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

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

> III. Normative status of this document

|   Internet-Drafts are draft documents valid for a maximum of six months
|   and may be updated, replaced, or obsoleted by other documents at any
|   time.  It is inappropriate to use Internet-Drafts as reference
|   material or to cite them other than as "work in progress."

OTOH, it is a standard practise that RFCs are based on existing
implementations and we have that implemented in in GnUPG 2.1.12 (May
2016) and thus for example also in Debian Stretch


Salam-Shalom,

   Werner


-- 
Die Gedanken sind frei.  Ausnahmen regelt ein Bundesgesetz.