Re: [openpgp] Possible ambiguity in description of regular expressions: [^][]
Ángel <angel@16bits.net> Sun, 10 January 2021 21:37 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 621B43A1308 for <openpgp@ietfa.amsl.com>; Sun, 10 Jan 2021 13:37:10 -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 VXlvbgCsWWuF for <openpgp@ietfa.amsl.com>; Sun, 10 Jan 2021 13:37:08 -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 9ABF33A1307 for <openpgp@ietf.org>; Sun, 10 Jan 2021 13:37:08 -0800 (PST)
Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from <angel@16bits.net>) id 1kyiOZ-0006wV-81 for openpgp@ietf.org; Sun, 10 Jan 2021 22:37:07 +0100
Message-ID: <abc6e18a9eef6c1419df8df3e220d63eb36d4fa0.camel@16bits.net>
From: Ángel <angel@16bits.net>
To: openpgp@ietf.org
Date: Sun, 10 Jan 2021 22:37:03 +0100
In-Reply-To: <87im846g0q.fsf@fifthhorseman.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> <87lfd25is6.fsf@fifthhorseman.net> <b8bc0722114cb6367e8d9172b10a6d6df0c3c146.camel@16bits.net> <87im846g0q.fsf@fifthhorseman.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/wiH1iUYLpKy_tTzURiEQ_Nh6wT4>
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: 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 Ángel 1- https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-04#section-4.1
- [openpgp] Possible ambiguity in description of re… Neal H. Walfield
- Re: [openpgp] Possible ambiguity in description o… Daniel Kahn Gillmor
- Re: [openpgp] Possible ambiguity in description o… Neal H. Walfield
- Re: [openpgp] Possible ambiguity in description o… Daniel Kahn Gillmor
- Re: [openpgp] Possible ambiguity in description o… Andrew Gallagher
- Re: [openpgp] Possible ambiguity in description o… Ángel
- Re: [openpgp] Possible ambiguity in description o… Ángel
- Re: [openpgp] Possible ambiguity in description o… Andrew Gallagher
- Re: [openpgp] Possible ambiguity in description o… Ángel
- Re: [openpgp] Possible ambiguity in description o… Daniel Kahn Gillmor
- Re: [openpgp] Possible ambiguity in description o… Ángel
- Re: [openpgp] Possible ambiguity in description o… Daniel Kahn Gillmor
- Re: [openpgp] Possible ambiguity in description o… Ángel
- Re: [openpgp] Possible ambiguity in description o… Wiktor Kwapisiewicz