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

Ángel <angel@16bits.net> Sat, 09 January 2021 00:08 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 DA7C53A13DE for <openpgp@ietfa.amsl.com>; Fri, 8 Jan 2021 16:08:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, 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 k9iumcFEuLrY for <openpgp@ietfa.amsl.com>; Fri, 8 Jan 2021 16:08:14 -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 A8DA03A13D6 for <openpgp@ietf.org>; Fri, 8 Jan 2021 16:08:14 -0800 (PST)
Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from <angel@16bits.net>) id 1ky1ng-0000ct-DE for openpgp@ietf.org; Sat, 09 Jan 2021 01:08:12 +0100
Message-ID: <7ff8e6cc238ac6f9680e1b3fc32dc7bbff7239c0.camel@16bits.net>
From: Ángel <angel@16bits.net>
To: openpgp@ietf.org
Date: Sat, 09 Jan 2021 01:08:10 +0100
In-Reply-To: <b7a318d1-b6d0-e71e-28fe-197923185a38@andrewg.com>
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> <b7a318d1-b6d0-e71e-28fe-197923185a38@andrewg.com>
Content-Type: text/plain; charset="ISO-8859-15"
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/Ezs1MX3kSueVExbg-dJ0eJAANPA>
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: Sat, 09 Jan 2021 00:08:20 -0000

On 2021-01-08 at 16:55 +0000, Andrew Gallagher wrote:
> It strikes me that regexes are an overengineered solution to a
> narrow use case, and that a simple *? globbing language would be more
> than sufficient. Is anything more complex than <*@*.example.com>
> required in the real world?

That's a good point. It indeed looks as overengineered, but I'm not
aware of the dicussion that led to that being included.

I would probably include {} alternatives, to cover multiple tlds, so
resusing my previous example, that could be expressed as:
 "*@protonmail.{com,ch}>"

but I don't think that is required if the same can be expressed with
multiple subpackets.
Note that currently it isn't specified what happens if multiple Regular
Expression subpackets are present.
> Only signatures by the target key on User IDs that match the regular
> expression in the body of this packet have trust extended by the
> trust Signature subpacket.

If I made a signature with by TWO Regular Expressions
".*@andrewg.com>$" and "Andrew.*", would that cover user ids matching
ANY of them, or only those matched by BOTH?


If a new "Globbing expression" subpacket was added, allowing user ids
covering any of them would be a simple solution (and probably cleaner
as well) to not require that {}


Another fine point would be if * should expand across dots or,
following the same rulesprecedent as SSL certificates not expand
through several labels (see rfc6125 section-6.4.3 rule 2)


Finally, another point to consider would be whether to match only the
email address portion. Yes, User ID could contain something else, but
this delegation of partial trust only seem useful when combined with a
hierarchical structure, such as those to be found on the email address
part. It seems rare to require a matching on the display name part.
And allowing that would greatly decrease its security. Basically a
wildcard not on the left-most side could be bypassed by including the
required characters on the display name.


Best regards