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

Daniel Kahn Gillmor <dkg@fifthhorseman.net> Sat, 09 January 2021 18:11 UTC

Return-Path: <dkg@fifthhorseman.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 2CB323A11A4 for <openpgp@ietfa.amsl.com>; Sat, 9 Jan 2021 10:11:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=fcwLvkfN; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=qBZ6pudS
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 4du5mI7Qct7c for <openpgp@ietfa.amsl.com>; Sat, 9 Jan 2021 10:11:25 -0800 (PST)
Received: from che.mayfirst.org (che.mayfirst.org [IPv6:2001:470:1:116::7]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 433043A119A for <openpgp@ietf.org>; Sat, 9 Jan 2021 10:11:24 -0800 (PST)
DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1610215883; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=ug6YXXL5ZMuyjr5kxuQ3rGHYboGuo8O4DY9IC4b+weA=; b=fcwLvkfNB6n/inVbGZH41IchPzEthTabWGUKXyhKikInjbLY32rkUfGmY7kWiIy0v0T8f GYeiZdvLLKN4lBxDg==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1610215883; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=ug6YXXL5ZMuyjr5kxuQ3rGHYboGuo8O4DY9IC4b+weA=; b=qBZ6pudSawr7Gcsd5I65LLvz+QXtuGWpmjwBOR2YeTZk8h0+xeIe5zbW66LbqALSKXY6j L8bGjP4tELbxsF8L9JeB47EuyR2vzxQnyvjrunlv4QvYJaevawq7+WVEf2q5R9U4Qzi6DWp 7QELAEFj9Q68JQ7XIwWrCg+++4u2glqaYANHIoIpi5FdLgcGHfpYwwU3jW0Rm1KBPIIMkA+ Uek0CgNyvaxWXxRR+daROUZnib0Ej/soJXvUExMQIBafCd6wvGfeFEMtISqfybsekkTDjQ1 DwBFCZ3rGTUKvS8W6zcjj9Sbu9i6F/3xsOs/XMkNFoOp1MiwePywY5kOo7TA==
Received: from fifthhorseman.net (unknown [64.234.56.87]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 9F9ECF9A5; Sat, 9 Jan 2021 13:11:23 -0500 (EST)
Received: by fifthhorseman.net (Postfix, from userid 1000) id 5E4E520391; Sat, 9 Jan 2021 08:42:03 -0500 (EST)
From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>
To: Ángel <angel@16bits.net>, openpgp@ietf.org
In-Reply-To: <7ff8e6cc238ac6f9680e1b3fc32dc7bbff7239c0.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> <b7a318d1-b6d0-e71e-28fe-197923185a38@andrewg.com> <7ff8e6cc238ac6f9680e1b3fc32dc7bbff7239c0.camel@16bits.net>
Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEXEK/AhYJKwYBBAHaRw8BAQdAr/gSROcn+6m8ijTN0DV9AahoHGafy52RRkhCZVwxhEe0K0Rh bmllbCBLYWhuIEdpbGxtb3IgPGRrZ0BmaWZ0aGhvcnNlbWFuLm5ldD6ImQQTFggAQQIbAQULCQgH AgYVCgkICwIEFgIDAQIeAQIXgAIZARYhBMS8Lds4zOlkhevpwvIGkReQOOXGBQJd5Hw3BQkFpJWB AAoJEPIGkReQOOXGDYEA/j0ERjPxDleKMZ2LDcWc/3o5cLFwAVzBKQHppu0Be5IWAP0aeTnyEqlp RTE7M8zugwkhYeUYfYu0BjecDUMnYz6iDLgzBF3kewUWCSsGAQQB2kcPAQEHQK1IuW0GZmcrs2mx CYMl8IHse0tMF8cP7eBNXevrlx2ZiPUEGBYIACYCGwIWIQTEvC3bOMzpZIXr6cLyBpEXkDjlxgUC XeR7TwUJAiGl/gCBdiAEGRYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCXeR7BQAKCRDEDyVU MvKBD7KmAQCHs+7588C4jto6fMje0Nu97zzoppjJM7lrGF2rVnbHvwD+MgmGUbHzPSUrTWnZBQDi /QM595bxNrBA4N1CiXhs2AMJEPIGkReQOOXGpp0BAM7YeBnt/UNvxJAGm4DidSfHU7RDMWe6Tgux HrH21cDkAQC9leNFXJsQ7F2ZniRPHa8CkictcQEKPL8VCWpfe8LbArg4BF3ke5wSCisGAQQBl1UB BQEBB0Cf+EiAXtntQMf51xpqb6uZ5O0eCLAZtkg0SXHjA1JlEwMBCAeIfgQYFggAJhYhBMS8Lds4 zOlkhevpwvIGkReQOOXGBQJd5HucAhsMBQkCIaVkAAoJEPIGkReQOOXGdYcBANYnW7VyL2CncKH1 iO4Zr0IwfdIv6rai1PUHL98pVi3cAP9tMh85CKGDa0Xi/fptQH41meollLW5tLb/bEWMuUNuBQ==
Date: Sat, 09 Jan 2021 08:42:01 -0500
Message-ID: <87lfd25is6.fsf@fifthhorseman.net>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-="; micalg="pgp-sha256"; protocol="application/pgp-signature"
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/5Mr0dLLnZR7-deMUpyN85t1EtzY>
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 18:11:27 -0000

On Sat 2021-01-09 01:08:10 +0100, Ángel wrote:
> 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.

This stuff is very rarely used in the wild, and to the extent that it
is, it's used as a hierarchical match on the domain side of an e-mail
address, as found in the user ID (which itself is not typically treated
as a true RFC 2822 name-addr, despite the text in the spec, see
id:87woe7zx7o.fsf@fifthhorseman.net and related discussion).

Seems like the right way to address the most common (though still
uncommon) use case is to make a new explicit subpacket that is just
about handling a DNS suffix; to clearly define the interaction between
multiple subpackets; and to deprecate the regex for that particular use
case. (maybe deprecate the regex subpacket in general, as i've not seen
any other legit use, and there are clearly gaps in the spec for it)

That work is not really in-scope given our current charter, but if
someone wants to write something like that down in a more formal way, i
can imagine it being something for the WG to take on after we finish the
cryptographic refresh and consider re-chartering.

              --dkg