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

Ángel <> Fri, 08 January 2021 01:42 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D00833A100A for <>; Thu, 7 Jan 2021 17:42:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.899
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MZe63MbxJqlQ for <>; Thu, 7 Jan 2021 17:42:43 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 009E23A1003 for <>; Thu, 7 Jan 2021 17:42:42 -0800 (PST)
Received: from mailer by with local (Exim 4.80) (envelope-from <>) id 1kxgnZ-0003o6-2a for; Fri, 08 Jan 2021 02:42:41 +0100
Message-ID: <>
From: Ángel <>
Date: Fri, 08 Jan 2021 02:42:36 +0100
In-Reply-To: <>
References: <> <> <> <> <> <>
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: <>
Subject: Re: [openpgp] Possible ambiguity in description of regular expressions: [^][]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-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

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:

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


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