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

Ángel <> Sun, 10 January 2021 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 621B43A1308 for <>; Sun, 10 Jan 2021 13:37:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
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 ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id VXlvbgCsWWuF for <>; Sun, 10 Jan 2021 13:37:08 -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 9ABF33A1307 for <>; Sun, 10 Jan 2021 13:37:08 -0800 (PST)
Received: from mailer by with local (Exim 4.80) (envelope-from <>) id 1kyiOZ-0006wV-81 for; Sun, 10 Jan 2021 22:37:07 +0100
Message-ID: <>
From: Ángel <>
Date: Sun, 10 Jan 2021 22:37:03 +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: Sun, 10 Jan 2021 21:37:10 -0000

On 2021-01-10 at 09:08 -0500, Daniel Kahn Gillmor wrote:
> Given our charter, i'm not convinced that any of this (including my
> merge request, mentioned above) is in scope for the intended
> cryptographic refresh of RFC 4880, so i dont think it belongs
> ultimately in rfc4880bis.

Adding a new subpacket filter format is clearly out of scope of the
current charter. Let's call it "rfc4880tris material". :-)
Maybe, if rechartered before the publication, some low-hanging changes
completely uncontroversial might be included in the document. We could
all be shouting each other much earlier as that, as well. Or only very
difficultly reaching a consensus for rfc 4880 bis. It's too early in
the process. ¯\_(ツ)_/¯

However, I do think the User ID clarifications would be in scope, as
"addressing issues that have been identified by the 
community since the working group was originally closed."

Not that your merge request really changes existing convention. It only
documents it. In fact, I think it should additionally state that user
"SHOULD NOT be larger than XYZ", or at least warn about the attacks
with a note that an implementation "MAY choose to implement a maximum
Usuer ID size" (or even packet size, basically [1])

Best regards