Re: [openpgp] Possible ambiguity in description of regular expressions: [^][]

Ángel <angel@16bits.net> Fri, 08 January 2021 01:42 UTC

Return-Path: <angel@16bits.net>
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 D00833A100A for <openpgp@ietfa.amsl.com>; Thu, 7 Jan 2021 17:42:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.899
X-Spam-Level:
X-Spam-Status: No, score=-1.899 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
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 MZe63MbxJqlQ for <openpgp@ietfa.amsl.com>; Thu, 7 Jan 2021 17:42:43 -0800 (PST)
Received: from mailer.hiddenmail.net (mailer.hiddenmail.net [199.195.249.9]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 009E23A1003 for <openpgp@ietf.org>; Thu, 7 Jan 2021 17:42:42 -0800 (PST)
Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from <angel@16bits.net>) id 1kxgnZ-0003o6-2a for openpgp@ietf.org; Fri, 08 Jan 2021 02:42:41 +0100
Message-ID: <13c0c640c6a134a6b63e7477681547867e516cbf.camel@16bits.net>
From: Ángel <angel@16bits.net>
To: openpgp@ietf.org
Date: Fri, 08 Jan 2021 02:42:36 +0100
In-Reply-To: <a061d617a22416638bf1fb0a1f7d66b7495f9b82.camel@16bits.net>
References: <87r1nguquq.wl-neal@walfield.org> <87tusbuwzp.fsf@fifthhorseman.net> <87mtxzv7mr.wl-neal@walfield.org> <877dor8kl1.fsf@fifthhorseman.net> <87456fad-06cd-6605-b5d1-ea5ac49c9ee4@andrewg.com> <a061d617a22416638bf1fb0a1f7d66b7495f9b82.camel@16bits.net>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
User-Agent: Evolution 3.30.5-1.1
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/jfySWXXQeX06Ko81zXSWfm8E8Kg>
Subject: Re: [openpgp] Possible ambiguity in description of regular expressions: [^][]
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: Fri, 08 Jan 2021 01:42:45 -0000

On 2021-01-08 at 01:29 +0100, Ángel wrote:
> It is unlikely that someone would have restricted a trust value based
> on the presence of curly brackets on an User ID (they are legal in
> the local part of email addresses, even unquoted, but it would be
> very rare to find one). 

I have done a small review on the keyservers for User ID containing
curly brackets.
First, I restricted it to User ID containing email addresses.† Most
curly brackets on user id appear on the display-name of the user-id, as
part of a nick or used as brackets (e.g. "{Corporate Key}", "{RSA
Key}"…).

Someone might want to restrict a signature based on the display name,
such as trusting "John Doe" key for signing any key of someone named
"John Doe" (presumably other keys of himself), thus breaking for
names/nicks restricted in such way that contained "{".

But the real benefit of this feature imho would be for delegating the
trust on a subset of users, based on their email address.

For example, trust on a protonmail "master" openpgp key could (should?)
be qualified for "@protonmail\.(com|ch)>$" to only cover their users.


This reduces a lot the number of user ids with curly braces. There are
a few people that surrounded the email address with curly braces
instead of angle ones, or added a name/comment with those. Such emails
wouldn't be recognised by mail clients, though.

There are three instances where curlies appear on the domain part, in
order to cover multiple domains:
<{chongo,noll}@{toad,sgi}.com>        
<dz@{pd.dialnet,rd.relcom}.msk.su>
<colinp@{jolt.mpx,nms.otc}.com.au>

And then exactly twelve email addresses with the character '{' in the
local part:

<{R}@semolina.org>³
<{^_^}@hafner.NL.EU.ORG>¹
<{pc}@vlaad.co.uk>²
<{richard}@the-gog.org>⁵
<tao{tones@ivwnet.com>⁶
<{ajh}@andrewhill.com>⁷
<{richard}@demeseo.com>⁴
<c}{s@moyind.dhs.org>²
<lunam2{dhwtowers/towers2/lunam2}@dhw.state.id.us>³
<odal14{@gmx.net>⁸
<alise{TW}@computer-netsolutions.com>⁵
<c}{s@moyind.com>²


Of which only one of them works.



† This basically lets us ignore "bad" user IDs such as html pages. I
also filtered out from the analysis some garbage-looking user ids.

¹ E-mail accepted
² NXDOMAIN
³ No MX/A record
⁴ No MX record and no SMTP server reachable on A record
⁵ Recipient address rejected: User unknown in virtual mailbox table
⁶ 550 User unknown. (#5.1.1)
⁷ 550 5.4.1 Recipient address rejected: Access denied. AS(201806281)
⁸ 550 Requested action not taken: mailbox unavailable