From nobody Tue Jan 5 07:33:40 2021 Return-Path: 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 9F49A3A0E39 for ; Tue, 5 Jan 2021 07:33:38 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 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, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=qylGlAxJ; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=IJbapQZ0 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 HKctGq0j2clw for ; Tue, 5 Jan 2021 07:33:37 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8AD7E3A100D for ; Tue, 5 Jan 2021 07:33:34 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1609860813; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=+K08OVJSO7nABF3by7JJxJjhIeYFOWsZm6t/Qg2d3/8=; b=qylGlAxJhwE6/n8eaFlwAYsz0Z/oka1pe7WiWoXYz2EvYf8pRHOqqjoXqss8GmAZAIAwH Lh4+4c2yL4KANv4Bg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1609860813; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=+K08OVJSO7nABF3by7JJxJjhIeYFOWsZm6t/Qg2d3/8=; b=IJbapQZ09LwitjoiYC5dCmpaRCuod5ZpBNBLNAOh7EAFlOdbItHvDvO/xDJIq+phM8eut Pny4t4tVDpk3C6PCtaY/HsrBQ9ARZ+Mqo4Dv+uyYpeQ/sa96A855aZFUZvtE1sTF0Ffvt+p 69T0frB1OaGRhVxZCoyFBQJFWWEwLehqRzNdQJFPw5lcFuLZk0iq5U8nm3AfediuF9bHTkd EeXvNzYQGV+QEvxtgJu0WD4odPtPDjx5zcYTTZ1Wv5G/EfZyjeTEf+FiFlWofvFt2BJ/vlq 8mK+I/gYBVkuSViJ9lwJz/zvoU4iu+bl14bnp6jUcpc44mCSiJrhW0RIo0SQ== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id 8A2A9F9A5; Tue, 5 Jan 2021 10:33:33 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 93EE020200; Tue, 5 Jan 2021 10:33:31 -0500 (EST) From: Daniel Kahn Gillmor To: "Neal H. Walfield" Cc: openpgp@ietf.org In-Reply-To: <87mtxzv7mr.wl-neal@walfield.org> References: <87r1nguquq.wl-neal@walfield.org> <87tusbuwzp.fsf@fifthhorseman.net> <87mtxzv7mr.wl-neal@walfield.org> 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: Tue, 05 Jan 2021 10:33:30 -0500 Message-ID: <877dor8kl1.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 15:33:39 -0000 --=-=-= Content-Type: text/plain On Sun 2020-12-27 11:57:32 +0100, Neal H. Walfield wrote: > We need to exclude [^] as well. good catch! > Perhaps: > > +A range is a non-empty sequence of characters excluding the optional > leading ^ enclosed in '[]'. This seems like pretty confusing wording to me, because i can't tell how to connect "non-empty" with "excluding" and "optional". Maybe a concrete example of what we're trying to fix would also help? something like: In particular, '[]' and '[^]' are not valid ranges. I'd be happy if folks can exchange wordsmithing ideas on the list here. But beyond the wordsmithing, if anyone thinks that Neal's interpretation (or my proposed clarification) is actually wrong or problematic, please speak up! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX/SGywAKCRDEDyVUMvKB D6cAAQDkkaBmdOSSGzQ77Fo0eC6e0oSw9QTCw20V2p72uYYyygD/UabUwuSIkjv2 i1ALQ4IB07yqUnzq7tXD6ssQB6wLFgM= =JjRv -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 5 09:11:44 2021 Return-Path: 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 DEC633A104A for ; Tue, 5 Jan 2021 09:11:42 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 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, NICE_REPLY_A=-0.262, 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=pass (2048-bit key) header.d=andrewg.com 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 0vVF4pZCl0eU for ; Tue, 5 Jan 2021 09:11:41 -0800 (PST) Received: from xen.andrewg.com (andrewg.com [IPv6:2a01:7e00::f03c:91ff:fe93:aaa]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 759F83A0E8B for ; Tue, 5 Jan 2021 09:11:41 -0800 (PST) Received: from [IPv6:fc93:5820:7375:ee79:1300::1] (fred [IPv6:fc93:5820:7375:ee79:1300::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by xen.andrewg.com (Postfix) with ESMTPSA id A250F5C686 for ; Tue, 5 Jan 2021 17:11:39 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1609866699; bh=FNzivHwn2uGlQKy4Tmlx2B7GEJrR80biQXAdd4UJiFc=; h=To:References:From:Subject:Date:In-Reply-To:From; b=Ai3ICLUBEeaLBvknSZjfFMLnb/oW/0V5Ha596wO5aSD21+WNbHSKqzPLVeB5UFpKS cS1P9vnw8JR8EXDEvyd4nWqKMEN8VFg68Xp/2fKcvKCbWYdIMPUWvso3aHzZGm/75T Lz38xGlEUXaejSa/FxSt0s3ylavS0T+P+/kAlHM8U4QsuRg4KgNQSW7YZyw6AwqMhK qmuFiMuOzQy+22DvI5Ss4cxdJrDXif9ZAdMPTs69We2BHHRE71COw7AhdfRsUf9Ep7 yB0r09zPwzzpViMTg9rN8YrK1hodtK6OWUFBfEhYHyxFCGl8SjK/Sk/UKxb3rcRuxw 53D/G9MMRSlEQ== To: openpgp@ietf.org References: <87r1nguquq.wl-neal@walfield.org> <87tusbuwzp.fsf@fifthhorseman.net> <87mtxzv7mr.wl-neal@walfield.org> <877dor8kl1.fsf@fifthhorseman.net> From: Andrew Gallagher Message-ID: <87456fad-06cd-6605-b5d1-ea5ac49c9ee4@andrewg.com> Date: Tue, 5 Jan 2021 17:11:36 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.1 MIME-Version: 1.0 In-Reply-To: <877dor8kl1.fsf@fifthhorseman.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="AW7ErSGFj1DX559FD7YDOHp6YNp6YRRN1" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 05 Jan 2021 17:11:43 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --AW7ErSGFj1DX559FD7YDOHp6YNp6YRRN1 Content-Type: multipart/mixed; boundary="7dMxIoXFQYffZ5mlYNGYBNdiO22jzqOre"; protected-headers="v1" From: Andrew Gallagher To: openpgp@ietf.org Message-ID: <87456fad-06cd-6605-b5d1-ea5ac49c9ee4@andrewg.com> Subject: Re: [openpgp] Possible ambiguity in description of regular expressions: [^][] References: <87r1nguquq.wl-neal@walfield.org> <87tusbuwzp.fsf@fifthhorseman.net> <87mtxzv7mr.wl-neal@walfield.org> <877dor8kl1.fsf@fifthhorseman.net> In-Reply-To: <877dor8kl1.fsf@fifthhorseman.net> --7dMxIoXFQYffZ5mlYNGYBNdiO22jzqOre Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 05/01/2021 15:33, Daniel Kahn Gillmor wrote: > But beyond the wordsmithing, if anyone thinks that Neal's interpretatio= n > (or my proposed clarification) is actually wrong or problematic, please= > speak up! The original proposed change: "A range is a non-empty sequence of=20 characters enclosed in []" is clear and (mostly) effective, so IMO=20 should be adopted despite the fact that it is insufficient in itself. Now, consider the remaining corner cases: []] : matches a closing square bracket [^]] : matches anything other than a closing square bracket [[] : matches an opening square bracket [^[] : matches anything other than an opening square bracket [][] : matches either square bracket [^][] : matches anything other than either square bracket [^] : is an incorrectly nested sequence To tackle the insufficiency, I propose an additional change: -If the sequence begins with '^', it matches any single character not=20 from the rest of the sequence. +If the sequence begins with '^', it matches any single character not=20 from the rest of the sequence, which must then contain at least one=20 further character following the '^'. When read alongside "To include a literal ']' in the sequence, make it=20 the first character (following a possible '^')", this should be=20 sufficient to cover all corner cases. (I considered "... the rest of the sequence, which must be non-empty",=20 but it is unclear whether "which" refers to "the sequence" or "the rest=20 of the sequence") However... We should probably also explicitly note how to negate the special=20 meaning of '^': +To include a literal '^', locate it somewhere other than the first=20 character of the sequence. Now, this doesn't cover the (contrived) case where we may want to use a=20 literal '^' as the beginning of an ASCII range: [^-~] But if absolutely necessary, one could refactor: [_-~^] While we're at it, we should also clarify range inclusivity: -this is shorthand for the full list of ASCII characters between them +this is shorthand for them and the full list of ASCII characters=20 between them Also, many regex engines support backslash-escaping within a character=20 class. Does RFC4880 support this or not? My reading is that it doesn't,=20 but it may be worth explicitly clarifying this also (even though=20 backslash escaping would be a more elegant solution to [^-~]). Is there anything to be said for referring out to an external regex=20 definition instead of reinventing the wheel? :-) --=20 Andrew Gallagher --7dMxIoXFQYffZ5mlYNGYBNdiO22jzqOre-- --AW7ErSGFj1DX559FD7YDOHp6YNp6YRRN1 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEKR55odxVrielLu+DXB7EBNWQZikFAl/0ncoACgkQXB7EBNWQ Zinf9g//UKpFq0V/0D8FhFfobV3T3OdHWGEp4SM4UTo6IKnBVzLmH53P3l5sGCrx jJbSQFjI9auHnSD7Cps/Q9Ar/v2owJIjXC+FTBwG4KPmeHL4HgHRt/4yn7/B/zdP Wfj3fKcG+DqyIuREdJGvUECCpHXiiLwcUXRwr8ckxbkS6p5LsIHkqVIQAaDquCgd uQldQiYNIAP662ehN1x9RFC3ETlc0LTC3Yw2Xl1njJPFEHkNAgsQ94ALvvNNRSKm zrYgbLJZZ/tEvimjn7d+kNVmYFDkg1gpRXNsomMcRBUyB/RL3TAFSQxsdfdpBUt/ mc5mnoPgKvfmsi/ovScp3vbTVTTQeAwijQYIzzw1QNLpqnPg2juJqCd6x9Sw1T2B lyhpUx7s4lkBAuCrpwBOckcpkiH93eNVa1HtXIxMwnhZ4HNrPI1Ns0Q6V2fNNG4I CVmZsbtVKhvLex9k5LVSf/t0DeumPW3gka3LkmO4cHMvcRqFtvuQ9uUx2hK69xDN Km/7CUQfRpt30zT9hnr62vcRA1wFJXY/XV3MccdEb3lTTnl8bE1WYQd8P9wUBsLR 8Vf/7OlBLHrwK0yps4//x1gTzumFjETxrvTvS81mXRYKm/j+EQCHtUt3prBBNlXG IqfVFUvSEWYjql7Pfy4YWH+pjfxwxZRXuYKQ+VlYwHibrotbyNc= =WQjT -----END PGP SIGNATURE----- --AW7ErSGFj1DX559FD7YDOHp6YNp6YRRN1-- From nobody Thu Jan 7 16:29:44 2021 Return-Path: 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 334893A0EC4 for ; Thu, 7 Jan 2021 16:29:42 -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 vOkc8EtF8j_u for ; Thu, 7 Jan 2021 16:29:40 -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 ECC0F3A0EC8 for ; Thu, 7 Jan 2021 16:29:39 -0800 (PST) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1kxfes-0003D8-JZ for openpgp@ietf.org; Fri, 08 Jan 2021 01:29:38 +0100 Message-ID: From: =?ISO-8859-1?Q?=C1ngel?= To: openpgp@ietf.org Date: Fri, 08 Jan 2021 01:29:36 +0100 In-Reply-To: <87456fad-06cd-6605-b5d1-ea5ac49c9ee4@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> 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 00:29:42 -0000 On 2021-01-05 at 17:11 +0000, Andrew Gallagher wrote: > Is there anything to be said for referring out to an external regex=20 > definition instead of reinventing the wheel? :-) The problem is that there is not a single regex specification. Although it would be beneficial to be able to change the regex definition in some minor ways. On this same topic, I had started the following reply last weekend: On 2020-12-23 at 22:58 +0100, Neal H. Walfield wrote: > Wait... that can also be parsed as match anything (2) followed by > match nothing (1)! >=20 >=20 > Perhaps I'm misreading the standard. I'd appreciate confirmation or > any help clarifying my mistake. >=20 > Thanks, >=20 > :) Neal I think it's kinda implicit in the=20 > To include a literal ']' in the sequence, make it the first character > (following a possible '^'). that a range cannot be "[]" or "[^]" since it is specified that in such case the "]" will be a literal character. The place-]-at-the-start (along make-'-'-first-or-last) is a well-known=20 trick when using old regex flavors which don't support escapes inside ranges. I would say the whole section makes sense. But there's room for improvement. A trickier case would be a regular expression such as: > Werner Koch (dist.* This could be taken as a valid regular expression, with the "(" =ABa single character with no other significance (matching that character)=BB, or a syntax error, since parentheses are 'special' per =ABAn atom is a regular expression in parentheses=BB. Exactly the same case applies to "[foo". Although rfc 4880 makes no reference to invalid regular expressions, I think that's how these should be categorised (another example would be a regular expression beginning with a quantifier).* And since the usage of regular expressions is for trust signatures packets, 5.2.3.15 should probably state that a regular expression that is invalid, or the implementation cannot support for whatever reason e.g. implementations _will_ place a recursion limit), then trust MUST NOT be extended. There's a second definition of the Regular Expressions, which is > The regular expression uses the same syntax as the Henry Spencer's > "almost public domain" regular expression [REGEX] package. with > [REGEX] Jeffrey Friedl, "Mastering Regular Expressions," > O'Reilly, ISBN 0-596-00289-0. However, someone which turned to that book will find that the latest edition (14.5 years old 3rd edition, from August 2006), which is the one readily available, does not describe Henry Spencer regex flavor. It mentions it as historically relevant, and that Perl 2 used an enhanced version of that, but it is not described by itself nor included in the tables comparing different flavors (I guess more details about it might have been removed in the rewrite that went into the second version). It is possible to dig out the original code[1] and actually test how it performs (spoiler: it does reject the above constructs), but one should not need to rely on how that code works. If I had to define the message now from new, I would probably define it as being a POSIX Extended Regular Expressions (ERE)[2] (or a subset of that). Those are relatively similar to the existing definition, are well-known and well-defined, and such definition would allow to simply use existing libraries conforming to that one (including regexec on a POSIX libc). An openpgp client shouldn't really need to care much about creating a regular expression engine. It is a complex part for the tiny usage it would get. In fact, the easier way to implement it would probably be to barely parse the 4880 regex to convert it into an ERE, and then use an existing facility to execute that. The main differences are: Curly brackets { } are special for EREs (used for the range quantifier) but not for 4880 regex, where they would be literals. An empty regex alternation (a | at the beginning or end of an ERE, or of a group inside brackets) is undefined on an ERE. A 4880 regex supports it with the expected meaning. An equivalent regex using ? can be used instead. 4880 regex doesn't support collating expressions inside equivalence sets. 4880 regex allow escaping any character with a backslash. On an ERE you can only escape special characters, an ordinary character preceded by a backslash is undefined (and often used for extensions e.g. \w) Regular expressions are a little-used feature, and the "natural" way to write them would conform to both of those specifications. 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). Equally, it would be strange to needlessly escape characters. So it _may_ be possible the change the definition without adversely affecting existing usage. For full compatibility, changing the regex would need to wait for V5 signatures or, preferably, use a new subpacket type. Happy New Year to all! =C1ngel Gonz=E1lez 1- there is a nice copy preserved at https://github.com/garyhouston/regexp= .old, see https://garyhouston.github.io/regex/ 2- https://pubs.opengroup.org/onlinepubs/007908799/xbd/re.html#tag_007_004 From nobody Thu Jan 7 17:42:46 2021 Return-Path: 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 D00833A100A for ; Thu, 7 Jan 2021 17:42:44 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.899 X-Spam-Level: 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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MZe63MbxJqlQ for ; Thu, 7 Jan 2021 17:42:43 -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 009E23A1003 for ; Thu, 7 Jan 2021 17:42:42 -0800 (PST) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1kxgnZ-0003o6-2a for openpgp@ietf.org; Fri, 08 Jan 2021 02:42:41 +0100 Message-ID: <13c0c640c6a134a6b63e7477681547867e516cbf.camel@16bits.net> From: =?ISO-8859-1?Q?=C1ngel?= To: openpgp@ietf.org Date: Fri, 08 Jan 2021 02:42:36 +0100 In-Reply-To: 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> 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-BeenThere: openpgp@ietf.org 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, =C3=81ngel 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).=20 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.=E2=80=A0 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 Key}"=E2=80=A6). 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: <{chongo,noll}@{toad,sgi}.com> =20 And then exactly twelve email addresses with the character '{' in the local part: <{R}@semolina.org>=C2=B3 <{^_^}@hafner.NL.EU.ORG>=C2=B9 <{pc}@vlaad.co.uk>=C2=B2 <{richard}@the-gog.org>=E2=81=B5 =E2=81=B6 <{ajh}@andrewhill.com>=E2=81=B7 <{richard}@demeseo.com>=E2=81=B4 =C2=B2 =C2=B3 =E2=81=B8 =E2=81=B5 =C2=B2 Of which only one of them works. =E2=80=A0 This basically lets us ignore "bad" user IDs such as html pages. = I also filtered out from the analysis some garbage-looking user ids. =C2=B9 E-mail accepted =C2=B2 NXDOMAIN =C2=B3 No MX/A record =E2=81=B4 No MX record and no SMTP server reachable on A record =E2=81=B5 Recipient address rejected: User unknown in virtual mailbox table =E2=81=B6 550 User unknown. (#5.1.1) =E2=81=B7 550 5.4.1 Recipient address rejected: Access denied. AS(201806281= ) =E2=81=B8 550 Requested action not taken: mailbox unavailable From nobody Fri Jan 8 07:29:39 2021 Return-Path: X-Original-To: openpgp@ietf.org Delivered-To: openpgp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC6C3A105A; Fri, 8 Jan 2021 07:29:37 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: dkg@fifthhorseman.net, kaduk@mit.edu, openpgp-chairs@ietf.org, openpgp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161011977751.21515.945149690712851586@ietfa.amsl.com> Date: Fri, 08 Jan 2021 07:29:37 -0800 Archived-At: Subject: [openpgp] openpgp - New Meeting Session Request for IETF 110 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 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 15:29:38 -0000 A new meeting session request has just been submitted by Daniel Kahn Gillmor, a Chair of the openpgp working group. --------------------------------------------------------- Working Group Name: Open Specification for Pretty Good Privacy Area Name: Security Area Session Requester: Daniel Gillmor Number of Sessions: 1 Length of Session(s): 1 Hour Number of Attendees: 20 Conflicts to Avoid: Chair Conflict: tls saag dprive People who must be present: Stephen Farrell Daniel Kahn Gillmor Benjamin Kaduk Resources Requested: Special Requests: --------------------------------------------------------- From nobody Fri Jan 8 07:42:24 2021 Return-Path: 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 8A8413A1065 for ; Fri, 8 Jan 2021 07:42:16 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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=pass (1024-bit key) header.d=cs.tcd.ie 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 ddqI9xmBKrd0 for ; Fri, 8 Jan 2021 07:42:14 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 329B23A107D for ; Fri, 8 Jan 2021 07:42:13 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id E393FBE50 for ; Fri, 8 Jan 2021 15:42:11 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ttcdSKgwuqR8 for ; Fri, 8 Jan 2021 15:42:10 +0000 (GMT) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id E79E6BE2E for ; Fri, 8 Jan 2021 15:42:09 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1610120530; bh=u8DP/KurxsizAsE6dg+nAQlYcU040tSLL51PD8pHaLk=; h=To:From:Subject:Date:From; b=UY2fykyUdGqDZrkMJ2ThmnmgIMKLiENGjbbWZNpu5mmPC/3ZBGHFnfMcek1K2baUO 9D6J5Vq87/Jp0OQDilVX8URIUbz79trLJHENDBfmGciabY8GoN5AEi67040rKCcyIo lFMhGbRRWvlIWSI2ZPrnelfd/V9tZSRaqHKsocUA= To: "openpgp@ietf.org" From: Stephen Farrell Message-ID: Date: Fri, 8 Jan 2021 15:42:09 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0 MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0WWgceVJMQbNaQd6RBNzED7OOl9hmDjKE" Archived-At: Subject: [openpgp] Poll for OpenPGP WG virtual interim in Feb X-BeenThere: openpgp@ietf.org 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 15:42:23 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --0WWgceVJMQbNaQd6RBNzED7OOl9hmDjKE Content-Type: multipart/mixed; boundary="jYlfyFnRphsewua3GS6v2EJSH8glXRMOy"; protected-headers="v1" From: Stephen Farrell To: "openpgp@ietf.org" Message-ID: Subject: Poll for OpenPGP WG virtual interim in Feb --jYlfyFnRphsewua3GS6v2EJSH8glXRMOy Content-Type: multipart/mixed; boundary="------------231B707FD0818A6953A172D2" Content-Language: en-US This is a multi-part message in MIME format. --------------231B707FD0818A6953A172D2 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hi all, As you've just seen DKG has requested a session for us at IETF110 in March. We think it may also be good to have a virtual interim for the WG as well in mid-late Feb, so I've setup a poll [1] for that - if you could fill that in over the next week, that'd be great. Assume that that'd be a 90 minute meeting. Apologies in advance for the many choices there - since this is our first poll for a time to meet outside of an IETF meeting week, I included timeslots that would be friendly for people in different parts of the world in the hope that that'll help us chairs know the timeslots that tend to work well for our active WG participants. So do feel free to only select the timeslots that work well for you on this one. (And btw - all the times are in UTC.) Thanks, S&D. PS: We're chatting in parallel with some of the people who've volunteered to help co-edit the main draft. (And thanks to all who did volunteer.) We hope to figure that out in the next week or so but as soon as we know, we'll of course let the list know. [1] https://dudle.inf.tu-dresden.de/openpgp-wg-feb21-interim/ --------------231B707FD0818A6953A172D2 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------231B707FD0818A6953A172D2-- --jYlfyFnRphsewua3GS6v2EJSH8glXRMOy-- --0WWgceVJMQbNaQd6RBNzED7OOl9hmDjKE Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl/4fVEFAwAAAAAACgkQWrL68XsXK+r9 Iw/+JD8tLHPI3TqFhbETcHlpLiadlflxiKlcygFPew08aGgJOV3aSlpIaFg1NzbnV5b11uQvUCIc 1MSdhTUwXPiAun34OUMjHt6HaV+54d0jg2dM8I4pcp9XYtj8KjVEtKkv1gfY4AWQKj6IRC7r0jU7 sqiIXidGFse1tFUpdyotVUzKjmm33LKzg/KQzx7BNjki8FJ9vZ1xsJ/tQzFnQcZt9Ek1AXDXlxVl WPGjJrMXmjtIV5QN4Hxxh/eqLXY1mVJbfex+pKYs8e9gF45IDXdeYhop5HDDian/47GJN71WNBko PNofz1rTyLOeFeiZn/28l3hwmHM3YuB6ZX9WoUmPo2h+GZBMaDGldVIWx2yKdfcBt31txm9IQDMT Foivt42NEV7R/AFiUhRQ7460ZmSLOtI8dxMlL7FZBUPBA5Zqea9C1e7O4k32OJaS9O4whPlpXA1k AWCgRpWp2JijCw/ULUl4CzTKJXuh0FnRQD9rrg5caKDS4hwsey/gtItfHw9clEz+V3awrSUzrmc9 WDZF5AhLcmEmXmcyOUyBa6Q3h07hKYv+0Fwzr9rz3wIVvybJW5CKxJisW5jSUzsnn6K5Rq017xtu G666s8fENHWHrhWGtaIcw8wHKcOl5PaLKwB4tPxoq5FeB2EU06KvJCLk2G8Gr7379aEvmHpdaQWP vqc= =vZfG -----END PGP SIGNATURE----- --0WWgceVJMQbNaQd6RBNzED7OOl9hmDjKE-- From nobody Fri Jan 8 08:55:10 2021 Return-Path: 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 855B83A1141 for ; Fri, 8 Jan 2021 08:55:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 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, NICE_REPLY_A=-0.262, 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=pass (2048-bit key) header.d=andrewg.com 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 zaEp36du8bP4 for ; Fri, 8 Jan 2021 08:55:06 -0800 (PST) Received: from xen.andrewg.com (andrewg.com [178.79.140.242]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 810F13A113C for ; Fri, 8 Jan 2021 08:55:05 -0800 (PST) Received: from [IPv6:fc93:5820:7375:ee79:1300::1] (fred [IPv6:fc93:5820:7375:ee79:1300::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) by xen.andrewg.com (Postfix) with ESMTPSA id 0A7EE5C686 for ; Fri, 8 Jan 2021 16:55:04 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=andrewg.com; s=andrewg-com; t=1610124904; bh=H0Mfzh25JmtlD8Yx/sKBAd6oXUZI+oxCLmUMVAH6ctk=; h=Subject:To:References:From:Date:In-Reply-To:From; b=CUfAbJorqebq5at2qDk5+DlFrRtPEpascf1y5NbTeHwGf70et+P7C4XjkzyiqQBjZ c3/LLTx0GmXUIZU4oavmhYEnCvyOQwCkVv023JhZZCXjwrQs1yR9wuQEDxKxxR1Ckp G3VveoU0+WiSUS72Qy2CkkbgNsfedaJcnOS5TLNiK9OIupYQD6Q2ZOgqFpr44yxXHG DET9LFE8b1pElJ2VfDeBjxVcV0qSDrKsXxm5bWtkh6mF95H8PKgNW3arTXfHrHNMjG bAQyX2JgZUu6t7PjxsE8C1BtWEIMUY4aVuAIQqbx1D8DMkKznSp1/erEAKCB6SJ5qy LGtIPmoTLc91w== To: openpgp@ietf.org 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> From: Andrew Gallagher Message-ID: Date: Fri, 8 Jan 2021 16:55:02 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="cJHn8zOVoARsn1k0JTJPBDED4v1YKfpeh" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 08 Jan 2021 16:55:09 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --cJHn8zOVoARsn1k0JTJPBDED4v1YKfpeh Content-Type: multipart/mixed; boundary="onMbNz7tTPYVs0TQLru3CbY4ZLXLxN9qb"; protected-headers="v1" From: Andrew Gallagher To: openpgp@ietf.org Message-ID: Subject: Re: [openpgp] Possible ambiguity in description of regular expressions: [^][] 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> In-Reply-To: --onMbNz7tTPYVs0TQLru3CbY4ZLXLxN9qb Content-Type: text/plain; charset=iso-8859-15; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable On 08/01/2021 00:29, =C1ngel wrote: > Regular expressions are a little-used feature, and the "natural" way to= > write them would conform to both of those specifications. 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). Equally, it would be strange to needlessly escape > characters. It strikes me that regexes are an overengineered solution to a narrow=20 use case, and that a simple *? globbing language would be more than=20 sufficient. Is anything more complex than <*@*.example.com> required in=20 the real world? --=20 Andrew Gallagher --onMbNz7tTPYVs0TQLru3CbY4ZLXLxN9qb-- --cJHn8zOVoARsn1k0JTJPBDED4v1YKfpeh Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEKR55odxVrielLu+DXB7EBNWQZikFAl/4jmYACgkQXB7EBNWQ ZimmIhAAk5+3ON6KMakvmHpxgJ5pdH/uzuc8/AbP0INjaHcAYt73YbBuJTW82XwH 4Y7NrG6256QLonMxlL2spC+X7ciDIwYEU6JHQ34DiRBN3bkEBUTzreLiRb3ZAyQP Z2fSWjfEBQRMlYPGJu9fEQxORR6thYCrCNGhGpX/d3voF3bY3MJQT5g7epWzwzw1 Q50UyJaJ/Bx6t4PKqMtOdhHxFJAe++25Cw41h05UbS28o36ssc/vba0/svOGDY8c JnCdXQRgZQWvkcTZGAXDtRQdEOT/qfu+tzV/TEUt+K+bWc6r1YP3UjmXXwKSpM9x wuWugMHcD6o5XTFNeckVXCLdMK25amA4czuKagYgoLb+ZaRmOs74Xa8H6KbtFyoy EkVZg+pyWpxd56zVuVVoEvgCbHuWbg1XjmWJNkBPnb4lip0nyfuluarKPh93gWKw X7D0FBSZHFAdT2aSBWeTF4DcxCML4cMw5Bf+JcqXB8owYk7zpPWJ6zaoFvL5ddgD zrCgOaW12A4AhfOhtEKMJY68tQqSZ1PU7YlkVX19DYVGw2BHUKgb/ieSql7CQnpO kkHndIE625IPyLmdBf3eEguaL95NzJDf6yB60Qoa1xOPQCvqNN8RFRKkGOaQF18n +Wqwa4fB0KOFXWI2BQcUyuLzypbkymd26EclE308Y4S/L5PIk18= =x++p -----END PGP SIGNATURE----- --cJHn8zOVoARsn1k0JTJPBDED4v1YKfpeh-- From nobody Fri Jan 8 16:08:21 2021 Return-Path: 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 ; 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 ; 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 ; Fri, 8 Jan 2021 16:08:14 -0800 (PST) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1ky1ng-0000ct-DE for openpgp@ietf.org; Sat, 09 Jan 2021 01:08:12 +0100 Message-ID: <7ff8e6cc238ac6f9680e1b3fc32dc7bbff7239c0.camel@16bits.net> From: =?ISO-8859-1?Q?=C1ngel?= To: openpgp@ietf.org Date: Sat, 09 Jan 2021 01:08:10 +0100 In-Reply-To: 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> 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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 From nobody Sat Jan 9 10:11:28 2021 Return-Path: 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 ; 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 ; 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 ; 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 To: =?utf-8?Q?=C3=81ngel?= , 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> <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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2021 18:11:27 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat 2021-01-09 01:08:10 +0100, =C3=81ngel 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 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX/myqgAKCRDEDyVUMvKB D7uEAP0U7r+9AX//ITbKrZ/8ERcGY07FmvL13Toh3zett3lWvwEA+Z0n02Ts9hB3 lCYs1QIQrfr/Q8h1EJZdqS7untkBzgI= =QFxI -----END PGP SIGNATURE----- --=-=-=-- From nobody Sat Jan 9 14:49:44 2021 Return-Path: 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 D87283A0962 for ; Sat, 9 Jan 2021 14:49:41 -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 9lLQBPlhNoXx for ; Sat, 9 Jan 2021 14:49:40 -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 2001C3A0958 for ; Sat, 9 Jan 2021 14:49:39 -0800 (PST) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1kyN3C-0004Ug-L6 for openpgp@ietf.org; Sat, 09 Jan 2021 23:49:38 +0100 Message-ID: From: =?ISO-8859-1?Q?=C1ngel?= To: openpgp@ietf.org Date: Sat, 09 Jan 2021 23:49:36 +0100 In-Reply-To: <87lfd25is6.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> <7ff8e6cc238ac6f9680e1b3fc32dc7bbff7239c0.camel@16bits.net> <87lfd25is6.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: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Jan 2021 22:49:42 -0000 On 2021-01-09 at 08:42 -0500, Daniel Kahn Gillmor wrote: > On Sat 2021-01-09 01:08:10 +0100, =C3=81ngel 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. >=20 > 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). (Hint for future references: that's the =E2=80=9CUser ID conventions (it's = not really a RFC2822 name-addr)=E2=80=9D thread.) Yes. I am aware of that packet not exactly being a formal name-addr. The mention "User ID could contain something else" was trying to convey that there could be completely unstructured User ID packets but in order for this to be useful you would need to be dealing with "common" ones. Looking again at that thread, I would recommend including some plain text examples (non-normative, perhaps) on how User ID would be expected to look like at your MR https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_r equests/23/diffs?commit_id=3Da300afb3aebd1f5645dd3fbdcf14a420c5bc2090 (does gitlab support creating a merge request of a merge request?) Realistically, there are some things that can only be achieved with "structured User ID", and rfc4480bis should probably have some more focus on that. Particularly, if there is an uid has an email address associated, it is crucial that all clients find the same one. > 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) I would probably consider that subpacket over en email address, although it would be very rare for one of them not to begin with "*@" > 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. >=20 > --dkg Are you thinking on a separate RFC or as an amendment that could be combined later into the same document? Best regards From nobody Sun Jan 10 10:52:11 2021 Return-Path: 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 CD55E3A11B0 for ; Sun, 10 Jan 2021 10:52:09 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.306 X-Spam-Level: X-Spam-Status: No, score=-1.306 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, RDNS_NONE=0.793, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=bTsJHYq/; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=Le2ko/ef 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 EoWcWeP4nd6l for ; Sun, 10 Jan 2021 10:52:08 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0CB433A11AF for ; Sun, 10 Jan 2021 10:52:07 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1610304726; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=eu33Xjm+v1FJuiFqCP/YRxqAHAxTJYPU1TW7zZNsZGE=; b=bTsJHYq/UmORFOcXi+H5p/qEi5eLEavekmz5NqGoYfaBrbEwPp7xVbVVTVl4YKNvpra+F DYDpC8IhWdLSAj0Bw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1610304726; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=eu33Xjm+v1FJuiFqCP/YRxqAHAxTJYPU1TW7zZNsZGE=; b=Le2ko/efF+YDfkUq6zkG2y4IYITHvX8sJz4/qWh9e1IFcYV94pDYDg/0N5qdId84CpBOy zJ1NtkAXD0xXSKosqfMrAKyw6yOGXS1PZuG64xU5uY0MzZAEQU5AyZ3rFHbZy/5shwKq1k7 FdtLxhnSC1HMV3YLVG3uetC+p2y8CJf4U7jNcSItp1H0VmnQCVwGUHkIu7dtLUOm9tpcyhM okmucECZq+2MeuPJb7NgjevLRHzBdhU4jGUREJax6dcQicGAR+tjalDQIsAZ1+NojDjFd9T ymDi6HIy0x5DgwmlckuvSop9qw9yay3zkvj8l0PPot5SBK8eSVkMSi41raag== 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 C3657F9A5; Sun, 10 Jan 2021 13:52:06 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id DB46420391; Sun, 10 Jan 2021 09:08:39 -0500 (EST) From: Daniel Kahn Gillmor To: =?utf-8?Q?=C3=81ngel?= , openpgp@ietf.org In-Reply-To: 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> <7ff8e6cc238ac6f9680e1b3fc32dc7bbff7239c0.camel@16bits.net> <87lfd25is6.fsf@fifthhorseman.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: Sun, 10 Jan 2021 09:08:37 -0500 Message-ID: <87im846g0q.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 10 Jan 2021 18:52:10 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On Sat 2021-01-09 23:49:36 +0100, =C3=81ngel wrote: > Realistically, there are some things that can only be achieved with > "structured User ID", and rfc4480bis should probably have some more > focus on that. 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. > Are you thinking on a separate RFC or as an amendment that could be > combined later into the same document? I think this would be a separate draft, which the WG isn't currently chartered to adopt. Assuming that we can effectively complete the cryptographic refresh, though, it seems reasonable to think that the WG would recharter to adopt and publish clarifications/improvements like this one. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQsv6x2UaqQJzY+dXHEDyVUMvKBDwUCX/sKZwAKCRDEDyVUMvKB D7OlAP9synkNEZw6vAa95Tf+DDq2s1ra2h51drGVKHEqgw/o8wEAkTQtPXjv61Lf LQhJi+LtUXJ6hj5nsOo1Xda+VEC9vAo= =fL3d -----END PGP SIGNATURE----- --=-=-=-- From nobody Sun Jan 10 13:37:12 2021 Return-Path: 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 ; 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 ; 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 ; Sun, 10 Jan 2021 13:37:08 -0800 (PST) Received: from mailer by mailer.hiddenmail.net with local (Exim 4.80) (envelope-from ) id 1kyiOZ-0006wV-81 for openpgp@ietf.org; Sun, 10 Jan 2021 22:37:07 +0100 Message-ID: From: =?ISO-8859-1?Q?=C1ngel?= 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> <7ff8e6cc238ac6f9680e1b3fc32dc7bbff7239c0.camel@16bits.net> <87lfd25is6.fsf@fifthhorseman.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: 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." 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. =C2=AF\_(=E3=83=84)_/=C2=AF However, I do think the User ID clarifications would be in scope, as "addressing issues that have been identified by the=20 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 =C3=81ngel 1-=20 https://tools.ietf.org/html/draft-dkg-openpgp-abuse-resistant-keystore-04#s= ection-4.1 From nobody Tue Jan 12 01:48:09 2021 Return-Path: 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 5D5E33A0EA8 for ; Tue, 12 Jan 2021 01:48:08 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.361 X-Spam-Level: X-Spam-Status: No, score=-2.361 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, NICE_REPLY_A=-0.262, 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=pass (2048-bit key) header.d=metacode.biz 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 346GeRng4z-a for ; Tue, 12 Jan 2021 01:48:06 -0800 (PST) Received: from mail-wr1-x42f.google.com (mail-wr1-x42f.google.com [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7AB3F3A0EA0 for ; Tue, 12 Jan 2021 01:48:06 -0800 (PST) Received: by mail-wr1-x42f.google.com with SMTP id i9so1768361wrc.4 for ; Tue, 12 Jan 2021 01:48:06 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=metacode.biz; s=2017; h=to:references:from:organization:cc:subject:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=UZJHCkEhFCDDTj4VhlXL4asWM0wKlKZKLXPkup4ux1M=; b=IrTDlmXsTypkgPvH8SqsSndwBa3Ea0Vaq6RhfBszcY3DeqVrMbyMeA3/5m/BiHveze XNCgVWIIkKM9O+Y8RdcCkvi/6fIeImjqRx8lhOuUfn3Ttg+75GzDWTu+u1Udun0BeQp7 I0uffzWAzSzR+wCg2JEllF+iW/SUexNf2Ay0OnmH0e39KOXJnBMCmIg8vpPK9MlWfNQZ ZGdFbLOShv38V8WPKJ4bwdFApcWfowGjMKL7clMduWhfc0T1IjPRxiZJCuIZunfyUZri BPs6u08gmabDUpZiJtOhinQlY4gsFjKCpFFVDQDKCsZGjVDouizJ7kAbWkgQlaGRMY4q TnPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:references:from:organization:cc:subject :message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=UZJHCkEhFCDDTj4VhlXL4asWM0wKlKZKLXPkup4ux1M=; b=q8Synxubu99i3PQ4MKPkbrac26ovUZVAKkVVTSao+OaBI9ikdpq57nInXjY5hmOEti BGlouZgccSkFJrKb6geLRQhYhDtpJDFe+QOUI35+MubSfrfpujhP7U+GUqBYji2/y9av BTwFKXSCLkutnqxm9Z0imJ/oxYD+XhMvldZvPREVFFmHVo3ovH9ihYf1qgNyownI7taJ +g5DrynScIou1YpStKHrR10OvKDbf3Lse1CJLiIEeMYXYcVZDyHKTGWsF0+t3J9VFduX ulvgdDcUy9KUU9GBuWGkNpv21+AOQiYYYtNp7gEErVJdmYs4Khu7HPx+SHM51EQvAyl6 e2hw== X-Gm-Message-State: AOAM5305NikmAd4bULqQoQ9VDxuVhEls9kNXPqL0cbLp6aG2w97ALKC7 PiEl8TlbLtQ69ynnjrWWqVR58YFbM/p7TA== X-Google-Smtp-Source: ABdhPJwNltYRQngzizPQdoeg+5W6Z1tRSKrLEgnPYkm4sWEEvcKBOhcFNzbjzn+gcZrTHSOhoB1juA== X-Received: by 2002:adf:efc5:: with SMTP id i5mr3210814wrp.377.1610444884271; Tue, 12 Jan 2021 01:48:04 -0800 (PST) Received: from [192.168.1.160] (public-gprs645665.centertel.pl. [5.184.65.98]) by smtp.googlemail.com with ESMTPSA id g192sm2992422wme.48.2021.01.12.01.48.02 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 12 Jan 2021 01:48:03 -0800 (PST) To: =?UTF-8?B?w4FuZ2Vs?= 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> <7ff8e6cc238ac6f9680e1b3fc32dc7bbff7239c0.camel@16bits.net> From: Wiktor Kwapisiewicz Organization: Metacode Cc: openpgp@ietf.org Message-ID: Date: Tue, 12 Jan 2021 10:48:10 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: <7ff8e6cc238ac6f9680e1b3fc32dc7bbff7239c0.camel@16bits.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Archived-At: 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." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 12 Jan 2021 09:48:08 -0000 Hi Ángel, On 09.01.2021 01:08, Ángel wrote: > 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 {} If a new subpacket was added I think it'd make sense to store the entire expression in a binary (tree) form. This way parsing would be more consistent across implementations. Using regexps invites implementers to just reuse whatever regexp library their language has thus inviting incompatibilities. Of course this is not of highest priority but having a binary packet encoding that stores a regexp string that should be parsed with a different parser looks like a design issue with the protocol. Kind regards, Wiktor From nobody Mon Jan 25 19:09:25 2021 Return-Path: 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 5EFF93A1B25 for ; Mon, 25 Jan 2021 19:09:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.199 X-Spam-Level: X-Spam-Status: No, score=-0.199 tagged_above=-999 required=5 tests=[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=xDxSVYXE; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=2+GZSlIb 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 yvmi0DdIDFTA for ; Mon, 25 Jan 2021 19:09:21 -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 7F6823A1B23 for ; Mon, 25 Jan 2021 19:09:21 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1611630560; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=/qgtdjGEvZeCeikMHc7cZ0/qj73YIUaNphATL3oDis4=; b=xDxSVYXE9OjTV+NQDrfwMD7ksLJnl237KqYV4HiYp7CmeAg9lKWVOSw1an0afczQopXQy COBdIte4Il579PMBQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1611630559; h=from : to : subject : date : message-id : mime-version : content-type : from; bh=/qgtdjGEvZeCeikMHc7cZ0/qj73YIUaNphATL3oDis4=; b=2+GZSlIbnHHvAdtNCS4nNh8PFWopukI4vhGZpetw9ul5bhk/cE3pNDZNIN/EpGgJMogMO QaYq6ljinNGRVOjXBrl+qJhRjZo4KK4/XCVhug23U2Q3U52Ps6idy4xaWbMwDXvMX3wt3Fr Bbf7xEIIPTEfljnOOAKDzXU2sFIiYIuZ57rwAYW0wv80+PVrFd/brfrFdMHq9WBwQFVo7sJ Wttmp0AewTVvO5tiniu3+VYxrv8pCORn1m4TTl7zN8ZC7fWz8zV+GbmoGahSPlMMp6Du1ky +Al1lmND2MqdmVUkWbQ0K6fDXDX5O/TYrI6ntGbhflgozmQV+KysMB+Y0ILg== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (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 C9220F9A5 for ; Mon, 25 Jan 2021 22:09:19 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id AB1E62050F; Mon, 25 Jan 2021 22:09:10 -0500 (EST) From: Daniel Kahn Gillmor To: openpgp@ietf.org 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: Mon, 25 Jan 2021 22:09:10 -0500 Message-ID: <87lfcgfl7t.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: text/plain Archived-At: Subject: [openpgp] WG process for getting to a revised RFC 4880 X-BeenThere: openpgp@ietf.org 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: Tue, 26 Jan 2021 03:09:23 -0000 Hi OpenPGP folks! We've talked it over and we've asked Paul Wouters to share the editorship with Werner Koch for the draft that will hopefully become the cryptographic refresh for RFC4880. Many other people also offered to stand in that role, and we thank them for that! Hopefully everyone will keep contributing to the process so we can fulfill our charter. We want to incorporate as much of draft-ietf-openpgp-rfc4880bis-10 as is in-charter, has consensus of the newly-reformed WG, and has multiple, interoperable implementors, plus whatever work remains in our charter. Here's how we're thinking of doing that: - To signal that we're in a "reset", we'll make a new draft, draft-ietf-openpgp-crypto-refresh, with Paul and Werner as editors. This new draft will be marked as a replacement for draft-ietf-openpgp-rfc4880bis-10. - crypto-refresh-00 (that is, the first revision of the new draft) will incorporate just the text of 4880, inconsequential editorial updates, the verified errata of 4880, and incorporation of the relevant text from RFCs 5581 (Camellia) and 6637 (ECC), so all substantive changes from 4880 are things that have already been through the IETF document publication process already. - We hope to be able to point the list to that -00 document shortly, and we hope everyone will review it and confirm that it offers no substantive changes to 4880 beyond those listed above, and that it faithfully mirrors the already-published documents it incorporates. The aim for this initial review is not "is this the best possible text?" but rather "is it a correct integration of already-published work?" - If we can accept that crypto-refresh document as a starting point, we'll have a series of diffs proposed (every week or two) to the WG. Each cycle will aim to incorporate a specific, thematic set of changes from 4880bis-10 into crypto-refresh-xx. The editors will describe the specific theme, propose a coherent diff to the current draft of crypto-refresh, and the WG will have an opportunity to comment on that change. If the comments show rough consensus and we can hammer out any wordsmithing details, the editors will incorporate the changes. If there are concerns that show that there is no consensus, we can put that set of changes aside. Hopefully that won't happen much. - Our initial changesets might be the easier ones, so that the group can get comfortable with the cadence and working together again, focused on the document. Please stay engaged even if the proposed changes look simple/trivial/obvious to you! A simple "I support the inclusion of this change" message to the WG is also an important contribution. (don't worry, we'll get to the harder stuff too). It's possible (indeed, quite likely) that some of the text currently in rfc4880bis-10 won't make it into the eventual version of crypto-refresh that becomes (hopefully) an RFC, whether that's because of a lack of consensus, being out-of-charter, or not having enough implementers to show interoperability. That's OK! If some text that you care about doesn't make into the revised OpenPGP standard, that doesn't mean we've given up on it -- it just means that we need to work on it separately from this chartered work. We encourage WG participants who care about things that might not make the cut for this version to help get this cryptographic refresh out the door in an effective way, so that we can recharter the WG in order to help document the evolving and active OpenPGP ecosystem. For the chairs, --dkg and Stephen Farrell From nobody Tue Jan 26 08:11:24 2021 Return-Path: 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 E7C163A0CD9 for ; Tue, 26 Jan 2021 08:11:23 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[SPF_HELO_NONE=0.001, 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 tos1e07I1Bb4 for ; Tue, 26 Jan 2021 08:11:21 -0800 (PST) Received: from tuna.sandelman.ca (tuna.sandelman.ca [IPv6:2607:f0b0:f:3:216:3eff:fe7c:d1f3]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BF36D3A0CD3 for ; Tue, 26 Jan 2021 08:11:21 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by tuna.sandelman.ca (Postfix) with ESMTP id 14E5E38A15; Tue, 26 Jan 2021 11:13:42 -0500 (EST) Received: from tuna.sandelman.ca ([127.0.0.1]) by localhost (localhost [127.0.0.1]) (amavisd-new, port 10024) with LMTP id nJE-NLWlunw4; Tue, 26 Jan 2021 11:13:41 -0500 (EST) Received: from sandelman.ca (obiwan.sandelman.ca [IPv6:2607:f0b0:f:2::247]) by tuna.sandelman.ca (Postfix) with ESMTP id A583338A04; Tue, 26 Jan 2021 11:13:41 -0500 (EST) Received: from localhost (localhost [IPv6:::1]) by sandelman.ca (Postfix) with ESMTP id CADFD618; Tue, 26 Jan 2021 11:11:19 -0500 (EST) From: Michael Richardson To: Daniel Kahn Gillmor cc: openpgp@ietf.org In-Reply-To: <87lfcgfl7t.fsf@fifthhorseman.net> References: <87lfcgfl7t.fsf@fifthhorseman.net> X-Mailer: MH-E 8.6+git; nmh 1.7+dev; GNU Emacs 26.1 X-Face: $\n1pF)h^`}$H>Hk{L"x@)JS7<%Az}5RyS@k9X%29-lHB$Ti.V>2bi.~ehC0; <'$9xN5Ub# z!G,p`nR&p7Fz@^UXIn156S8.~^@MJ*mMsD7=QFeq%AL4m Archived-At: Subject: Re: [openpgp] WG process for getting to a revised RFC 4880 X-BeenThere: openpgp@ietf.org 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: Tue, 26 Jan 2021 16:11:24 -0000 --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Daniel Kahn Gillmor wrote: > - To signal that we're in a "reset", we'll make a new draft, > draft-ietf-openpgp-crypto-refresh, with Paul and Werner as editors. > This new draft will be marked as a replacement for > draft-ietf-openpgp-rfc4880bis-10. > - crypto-refresh-00 (that is, the first revision of the new draft) > will incorporate just the text of 4880 {PERIOD}, inconsequential edit= orial > updates, the verified errata of 4880, and incorporation of the releva= nt > text from RFCs 5581 (Camellia) and 6637 (ECC), so all substantive > changes from 4880 are things that have already been through the IETF > document publication process already. I suggest that -00 be just rfc4880 be just redo in modern XML. We did that for RFC8514 (DHCPv6bis). So, where I marked {PERIOD} above. Then let -01 be all the rest. If you are using markdown, I also suggest that you start every new sentence on a newline, as that makes the git diff process much easier. > - If we can accept that crypto-refresh document as a starting point, > we'll have a series of diffs proposed (every week or two) to the WG. Perfect. =2D- Michael Richardson . o O ( IPv6 I=C3=B8T consulti= ng ) Sandelman Software Works Inc, Ottawa and Worldwide --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAEBCgAdFiEEbsyLEzg/qUTA43uogItw+93Q3WUFAmAQPycACgkQgItw+93Q 3WVXyQgAuzHxg2D9AhKRbvC7Pkr0Mjr3Oj1aMkUrOJlzLyLLpINIxvAtuk2lXTX0 0hk95rHknOfZIP18TCCi2DjSEzMDS8DDZNHctyEIb1WUwGcfdlcjhkJzC7ZUeV4w VgTqRCM8xcqN+tRqwMui6gp5oaNsBppE4SZA0RTzPdgsun/EDwnKPCBZXr2x9HQa G+c7frakfEX+z9iOKybQH+lE4DbKRzX3NbGMdukjbv8FZjfaPY90d/hXu0FsRaGr fBz2AXErun4Ucu3U1B1dzhfa1Tb90Wnt0UWq9myAk77KQXdbBHRuPbg+ad9tM4bo xguQJb9cEHxMuKhIWiP6GiZBsaDX0w== =gbtg -----END PGP SIGNATURE----- --=-=-=-- From nobody Tue Jan 26 09:16:18 2021 Return-Path: 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 E756B3A0B8F for ; Tue, 26 Jan 2021 09:16:17 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.075 X-Spam-Level: * X-Spam-Status: No, score=1.075 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RDNS_NONE=1.274, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=neutral reason="invalid (unsupported algorithm ed25519-sha256)" header.d=fifthhorseman.net header.b=iUbCkXFU; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=sj6OQcYz 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 GS9oLYB7OMda for ; Tue, 26 Jan 2021 09:16:16 -0800 (PST) Received: from che.mayfirst.org (unknown [162.247.75.117]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id A252A3A0E2D for ; Tue, 26 Jan 2021 09:15:54 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1611681352; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=9Tix/F9VG66dGgVAtPHZmQxQR8wg1t0XvcfCtJc2kTU=; b=iUbCkXFUauhxIQNnLHjbXf5ZeObo30G8w387cvbEFjUBgFAgg8EZqVH/WYKTFltSlWsNO P2jTnBoterNQxRqDA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1611681352; h=from : to : cc : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=9Tix/F9VG66dGgVAtPHZmQxQR8wg1t0XvcfCtJc2kTU=; b=sj6OQcYzzp5v4m9AUTJEv+AgKN5keDRt7Ad0icg7QnvB1R21JU9jxdrjcJWZk+ilK3iaW bDvrc6XZmg7lVP1eQLZZXSemzGi3sTpf1O0P0xZbg5aW+8VtaC+DcEktWUcOfvAGJY5k4IL 1mbIo6mD5GYNEJgQnF6Z9ASQH42Vy7ScUA/ml9AIKVKxprdoY/47z3f8Q69TrMZ5drOJ/IL AdQr6FgCwPcDOnEwxsRVaTj5KTMZPkbNcCTXBIcdRgsZ4CQ+HwJDl83PFbjCDdi1hryfyPO gFR2VxXtQjzkhCnz4I9S57fFcs2R0PPOS2JKHHLlbbxTEgfKhdT4EM7fh9lg== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (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 C97CAF9A5; Tue, 26 Jan 2021 12:15:52 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 9232B202CB; Tue, 26 Jan 2021 12:15:49 -0500 (EST) From: Daniel Kahn Gillmor To: Michael Richardson Cc: openpgp@ietf.org In-Reply-To: <8056.1611677479@localhost> References: <87lfcgfl7t.fsf@fifthhorseman.net> <8056.1611677479@localhost> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Tue, 26 Jan 2021 12:15:48 -0500 Message-ID: <877dnzfwl7.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] WG process for getting to a revised RFC 4880 X-BeenThere: openpgp@ietf.org 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: Tue, 26 Jan 2021 17:16:18 -0000 --=-=-= Content-Type: text/plain On Tue 2021-01-26 11:11:19 -0500, Michael Richardson wrote: > Daniel Kahn Gillmor wrote: > > - To signal that we're in a "reset", we'll make a new draft, > > draft-ietf-openpgp-crypto-refresh, with Paul and Werner as editors. > > This new draft will be marked as a replacement for > > draft-ietf-openpgp-rfc4880bis-10. > > > - crypto-refresh-00 (that is, the first revision of the new draft) > > will incorporate just the text of 4880 {PERIOD}, inconsequential editorial > > updates, the verified errata of 4880, and incorporation of the relevant > > text from RFCs 5581 (Camellia) and 6637 (ECC), so all substantive > > changes from 4880 are things that have already been through the IETF > > document publication process already. > > I suggest that -00 be just rfc4880 be just redo in modern XML. > We did that for RFC8514 (DHCPv6bis). > So, where I marked {PERIOD} above. Then let -01 be all the rest. If the editors decide they want to make a -00 from rfc4880 itself, and make -01 include the other stuff mentioned above, that seems reasonable to me. crypto-refresh.md at git commit 9349ef2c0afe128e35a5172e9d41ed17619ca790 in the "step-by-step" branch on https://gitlab.com/openpgp-wg/rfc4880bis would be a reasonable candidate for a source for that version. > If you are using markdown, I also suggest that you start every new sentence > on a newline, as that makes the git diff process much easier. yep, we're already doing that in the "simplifying-diffs" branch over at https://gitlab.com/openpgp-wg/rfc4880bis I agree that it makes the git diff much clearer, particularly for multi-sentence paragraphs where changes show up in the beginning or middle. the "reflow" script in the git repo makes a number of assumptions about an idiomatic markdown source -- if those assumptions are followed, then it does adopt this newline-per-sentence approach. --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYBBORQAKCRA+nXFzcd5W XO04AQDs7NAhCd35oA1vlPa6LqW02rbxlPORvZvWCN4u9AlEpgD+PoYVwdkJTR5p tZzDTaviBjFwipFL39zGayeMAEcIHQU= =MHCt -----END PGP SIGNATURE----- --=-=-=-- From nobody Fri Jan 29 08:34:49 2021 Return-Path: X-Original-To: openpgp@ietf.org Delivered-To: openpgp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6692B3A1153; Fri, 29 Jan 2021 08:34:44 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: openpgp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: openpgp@ietf.org Message-ID: <161193808437.14457.1252111225434038573@ietfa.amsl.com> Date: Fri, 29 Jan 2021 08:34:44 -0800 Archived-At: Subject: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-00.txt X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 16:34:45 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Open Specification for Pretty Good Privacy WG of the IETF. Title : OpenPGP Message Format Authors : Werner Koch Paul Wouters Filename : draft-ietf-openpgp-crypto-refresh-00.txt Pages : 94 Date : 2021-01-29 Abstract: This document is maintained in order to publish all necessary information needed to develop interoperable applications based on the OpenPGP format. It is not a step-by-step cookbook for writing an application. It describes only the format and methods needed to read, check, generate, and write conforming packets crossing any network. It does not deal with storage and implementation questions. It does, however, discuss implementation issues necessary to avoid security flaws. OpenPGP software uses a combination of strong public-key and symmetric cryptography to provide security services for electronic communications and data storage. These services include confidentiality, key management, authentication, and digital signatures. This document specifies the message formats used in OpenPGP. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/ There is also an HTML version available at: https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-00.html Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Fri Jan 29 08:59:41 2021 Return-Path: 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 2F6113A1174 for ; Fri, 29 Jan 2021 08:59:40 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 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_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nohats.ca 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 Kczv7HIQIodE for ; Fri, 29 Jan 2021 08:59:38 -0800 (PST) Received: from mx.nohats.ca (mx.nohats.ca [IPv6:2a03:6000:1004:1::68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 04C7A3A1171 for ; Fri, 29 Jan 2021 08:59:36 -0800 (PST) Received: from localhost (localhost [IPv6:::1]) by mx.nohats.ca (Postfix) with ESMTP id 4DS3Ty0pj1zCr5 for ; Fri, 29 Jan 2021 17:59:34 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nohats.ca; s=default; t=1611939574; bh=TzsqcJC89NOOhbMEP7HNVnZsB1Pz+D7w9RYkjEf9eA4=; h=Date:From:To:Subject:In-Reply-To:References; b=r+APPWF0olvJEKOli3s14Doey+CY9SZch2SYH8wAyybYe86bbFXr4jov1FqA/KZOw PNU81pLSSOJQNZf3WrLMOAsf89Rs7kYEdPEMLDvfTxqxKGr+XxWCd/LVnUI48MWPzg dUYiDguHoZjWrexwGZFNewB7aWOfYwpcmgT/SL2c= X-Virus-Scanned: amavisd-new at mx.nohats.ca Received: from mx.nohats.ca ([IPv6:::1]) by localhost (mx.nohats.ca [IPv6:::1]) (amavisd-new, port 10024) with ESMTP id wjTTNoVEQaT0 for ; Fri, 29 Jan 2021 17:59:32 +0100 (CET) Received: from bofh.nohats.ca (bofh.nohats.ca [193.110.157.194]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx.nohats.ca (Postfix) with ESMTPS for ; Fri, 29 Jan 2021 17:59:32 +0100 (CET) Received: by bofh.nohats.ca (Postfix, from userid 1000) id 900BB6029B62; Fri, 29 Jan 2021 11:59:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by bofh.nohats.ca (Postfix) with ESMTP id 8ECF566B1E for ; Fri, 29 Jan 2021 11:59:31 -0500 (EST) Date: Fri, 29 Jan 2021 11:59:31 -0500 (EST) From: Paul Wouters To: openpgp@ietf.org In-Reply-To: <161193808437.14457.1252111225434038573@ietfa.amsl.com> Message-ID: <629addad-3dc3-a490-46db-5fafab95c7d5@nohats.ca> References: <161193808437.14457.1252111225434038573@ietfa.amsl.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-00.txt X-BeenThere: openpgp@ietf.org 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, 29 Jan 2021 16:59:40 -0000 On Fri, 29 Jan 2021, internet-drafts@ietf.org wrote: > Subject: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-00.txt > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-openpgp-crypto-refresh/ > > There is also an HTML version available at: > https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-00.html Hi, We have uploaded the first document in the process described by the chairs to fold in the changes of 4880bis into the crypto-refresh document. The -00 document is just the re-generated version of RFC4880. The only changes are the updated boilerplate and generating code differences of the xml tools over the years, as well as the document author, role and name/time of the draft. You can see the diff with RFC4880 using this url: https://tools.ietf.org//rfcdiff?url1=https://tools.ietf.org/rfc/rfc4880.txt&url2=https://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refresh-00.txt Since this document is marked a succeeding the rfc4880bis-10 draft, using the diff between the "last two versions" is not very helpful in this case. Please let us know if you see any issue of this document representing the state of RFC4880. We will send out the -01 version in the next couple of days. Paul & Werner From nobody Fri Jan 29 09:36:57 2021 Return-Path: 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 918B23A11B8 for ; Fri, 29 Jan 2021 09:36:56 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2 X-Spam-Level: X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, NICE_REPLY_A=-0.001, 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=pass (1024-bit key) header.d=cs.tcd.ie 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 4tlvS6encUkh for ; Fri, 29 Jan 2021 09:36:54 -0800 (PST) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4BBA53A11B7 for ; Fri, 29 Jan 2021 09:36:53 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id 4B7ECBE50 for ; Fri, 29 Jan 2021 17:36:52 +0000 (GMT) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUruGIvQlYRb for ; Fri, 29 Jan 2021 17:36:47 +0000 (GMT) Received: from [10.244.2.242] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id CB328BE4C for ; Fri, 29 Jan 2021 17:36:47 +0000 (GMT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1611941807; bh=nkszXyOwCla1/bxZroN4qIoGOiJPV8rkMIrsWhYtE+s=; h=Subject:From:To:References:Date:In-Reply-To:From; b=Cz3wsH+wYfop5NcOLp4JZ4kQ1cRvzMobn+xCyvvPVs01c6p5fNjCBsMzNXA2qJvrU yZHUQ2xC3xqMvwZeza34xHfZC21NoDHOak9VZ6+l6wbUYMn+zj41EKetz4BbD6azNE WA9dpsT8HfhykaRFyeKGOj0rX1XXZ6oUQYd71Axw= From: Stephen Farrell To: "openpgp@ietf.org" References: Message-ID: Date: Fri, 29 Jan 2021 17:36:47 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="ISmehY6OtyOn7x5w0lOpziRHotUI2VnEH" Archived-At: Subject: Re: [openpgp] Poll for OpenPGP WG virtual interim in Feb X-BeenThere: openpgp@ietf.org 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, 29 Jan 2021 17:36:57 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --ISmehY6OtyOn7x5w0lOpziRHotUI2VnEH Content-Type: multipart/mixed; boundary="em8G1avOCbarTiGoblCbuADiPhlezibmL"; protected-headers="v1" From: Stephen Farrell To: "openpgp@ietf.org" Message-ID: Subject: Re: Poll for OpenPGP WG virtual interim in Feb References: In-Reply-To: --em8G1avOCbarTiGoblCbuADiPhlezibmL Content-Type: multipart/mixed; boundary="------------5C1C3F4E02CAC5AEDD18C239" Content-Language: en-US This is a multi-part message in MIME format. --------------5C1C3F4E02CAC5AEDD18C239 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Hiya, Thanks to all who filled in that poll. Now that we have a WG draft, dkg and I and the editors figured that having this meeting on Feb 26th from 1500-1630 UTC seems best. We'll sort out the formalities and you'll see some mail on that but you can put that in your calendars now. Cheers, S. On 08/01/2021 15:42, Stephen Farrell wrote: >=20 > Hi all, >=20 > As you've just seen DKG has requested a session for us at > IETF110 in March. We think it may also be good to have a > virtual interim for the WG as well in mid-late Feb, so I've > setup a poll [1] for that - if you could fill that in over > the next week, that'd be great. Assume that that'd be a 90 > minute meeting. >=20 > Apologies in advance for the many choices there - since this > is our first poll for a time to meet outside of an IETF > meeting week, I included timeslots that would be friendly > for people in different parts of the world in the hope > that that'll help us chairs know the timeslots that tend > to work well for our active WG participants. So do feel > free to only select the timeslots that work well for you > on this one. (And btw - all the times are in UTC.) >=20 > Thanks, > S&D. >=20 > PS: We're chatting in parallel with some of the people > who've volunteered to help co-edit the main draft. (And > thanks to all who did volunteer.) We hope to figure that > out in the next week or so but as soon as we know, we'll > of course let the list know. >=20 > [1] https://dudle.inf.tu-dresden.de/openpgp-wg-feb21-interim/ >=20 > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp >=20 --------------5C1C3F4E02CAC5AEDD18C239 Content-Type: application/pgp-keys; name="OpenPGP_0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="OpenPGP_0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- xsFNBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh5= Cg8 gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+QtaFq= 978 CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGu= D/Q 9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4= tNn cejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqB= wV+ 4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghVB5Uir= 1GC YChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5FmBKjG7cGcpBGmWav= ACY Ea7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK7uB7E7HlVE1IM1zNkVTYYGkKreU8D= VQu 8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER= 8la 5lsEEPbU/cDTcwARAQABzSFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT7CwX0EE= wEI ACcFAlo9UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qGC= xAA pYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKkrRl8beJ7j1CWX= Az9 +VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBrsjC+1uULaTU8zYEyET//GOGPL= F+X +degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZsdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4= g1U QAcCA4xlucY8QkJEyCrSNGpGnvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advre= k3U P71CKxpgtPmkd3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2= niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBGFEZYJGuaL= 4Nw tBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wVN3p46RyBQuXqJV8ccE11m= 6vt ZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8vovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7= +8A CcxRU3b9Ihd7WYjJ+pQPCoWYKozvtEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQ= LvC wFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8= rpK o9OkCz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqmuKhYr= qJs CcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMTAAr2p7PSaHgo+hIVa= W/r KSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQIAQlFxtgvOqpPOZNzeKBa/+KbE8TG= gMW rkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3u= rqR 1cLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/= 0A9 J9nrnBMqZpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5hc= JBD EN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPpMyEs04zvsbsl4= vrp 2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouBur45UDKTZkMZrr9FGrtkyXCGA= xvK dcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQyoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaK= xlf tjO+Bj3Jj73Cr5eqej3qB5+V4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjg= Uky o1s4vjUOY8DyI+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIO= aHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg2YVf0izSp= yyz JeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc/MoSjTS65vNWbpzONZWMZ= uLE FraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5w= sDc BBABCgAGBQJbxcflAAoJEGo7ETk8pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer= 3UM TVQg10vpa7pmqOGhjIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCP= jt5 uAxmbBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6+uWyK= 171 RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh5EQsn0pIh9wZIAbMR= Lpg RKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6KLChn2aEHQd+PdY1GBpZEcmNEUPuov= wza tM0h64hCzTm41eDqRfihZVBT7TbfXQnv8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0= zG3 6VdZTQF7TF/4Lz7/3cJ56jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQ= eah r2ez3DRBg3qsHEjBV80yU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxsQ= GNz LnRjZC5pZT7CwYAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AFAlo+o= 3cC GQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeOM3P7SW3C3UQYdCgZ/TlvxGgKo= w5o DSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3h= Rcs RvuPKHfl5+6oOi0+xqx3jX/s/69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmC= Y98 iD+EeiIMAWBjMw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jd= h2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSlAblGjwZe4= EIk CXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNgvDxZvuXssEjvz9X5JfcIZ= DIJ pdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/rwWcpGr/MfVPTOik4H7F8rcVJelceZTzC4= tvy a7M+jM4fyFWWt8Y4atTixUiP7U9o4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4= ul3 qvjYe8ye8DXEDjKAxo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIc= G9g ivQd8MxYNAbNYgSPtkbhZ8TCwFwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6NXEGt= w/r 1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYcJf+RyiH1nMoqUIZiZ= Jaf 3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbYtWgsYtRqHLD4IWi37MZrVyjBuF7u1= 4Q0 7+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGf= qtu Sw6CPBYLdbikqML6FZ7EDuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/C= gHw 26293tlve2Q6UTrmHxP5U22DlsLBfQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkKC= wIE FgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiPGYnh/CXxIF8eL= rfb e5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dTMrEGn8QWKx2iNuz9rZMXyOSWF= etu O01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8= v39 +qIHHRjuiwxBBCAOhHtHRsZXripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr= 1oD 3RxYNhuWgyGFL64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Pr= m2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCbhrC3+yoby= y/A UOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10MSU8GEZu9ayU4M3o3N9yxO= jao P0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXtGKvJtFAEppGEYezB+bLKIm6XlpPkhnwYz= leL Z7AMEco2C6QM8QPB3g3JpS3sqRhA5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC= 2X4 pbZDRvGIUKaGSB4+ksZgUUnNyvfQr2p7jsLBcwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g= 1MS BQJbtySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/l//34= YT0 auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX4Iec8+9ot6tIVg4sb= edD Sgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo7kD9FDHCjRN8XfhHQ4Q9cYyt06uF3= 1qG /aumgWYC9geCGgAwiHgwxNYb9GoJ0iZjCROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcV= YW6 R0a3Ra8KudX+nt25H5DRGd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg= 4Im VOLGqsUgVm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGxm= qyH eLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88zllsqhZAFQjNx= qnk SzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2EtMBhgojWwrGMvdLN6X3mnzNJ= Esc YyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezIz60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n= 2Hw xyRL5dVMyMdyQmntubbctfqrZ0tIwsDcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4F= eIY jlIXGghFWzsB4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8E= AuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwlvpNwiiBr4= 2AY R751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGkbPlPkztahsFqktgacIgXH= X5v aT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joBp823L7r5KfpqWTPpSCzVstQKZUGmmoE1q= Csw Y/Ud5wvp9SccpIILkRXj0rZRtfnE5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tq= yA4 3niUMy2n6q690of3berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7m= Eer 0rCL3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP80uU3RlcGhlbiBGYXJyZWxsI= Dxz dGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPsLBfQQTAQgAJwUCWj1RWgIbAwUJCZQmAAULC= QgH AgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jscEADEcB0WQEZn2AkrzDs1RhL0Lp6cZ= i0B igofkbcGfdhJyMSs19C0dhvncrAFClVI6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhn= i9g OJLlUpXViQtgrlstjk7hqVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTy= sIg pMw0bA1yBU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1n= 66v xxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIqhCljJ9x40Fkn/= 3r2 BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw2AbeXfr57f5zYsN3IqfbQLUjM= YtU N1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nYm2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr= 5iW XO3qx1HtEiGEqkporMQCTh3T5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/= zek ZyXRdS/oDKrBLUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78b= a0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdMLAXAQQAQgABgUCWj1SoAAKCRAvP= Ic2 gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06TQgW5wsqtNcrwn81yZTq6= XE6 i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I1= 16u /HwA9/FXsPo5isbh4ZqD4t0VHpWkmfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/J= G9a SSYvk3lznNiH41x9M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IW= OMq N2woDjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBwsFzBBABCAAdFiEEfhcKBFyEz= 0YO K3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0H6FJ23A9Ftpy+aXZ4= vYl zkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQOJSSHbQ49BFRLwb1J/wBZG4bbmrkLx= nNb KDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrhB+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+= 5HN HltSL3DF1c2fFOf2JrgBKVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq= 4hn l5+VC/48ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPwn= Zbg JO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2MvoolsW08FiZh3Ej4d= nJj j25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJlMbVLrMo2GXeo03OzNyvbs+u8= WLI aGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilc= dPC Yk4BsOlzpwwO74hNG7iyl0KdAlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTX= o4+ Ira2JUErL2cYzQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YvCwNwEEAEKAAYFAlvFx+UACgkQajsRO= Tyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04fZ2Ry4nF9= hZM 0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4NkC9JMpecfq62/teOAU2e5= P3f WYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOosp= cL2 lJTmy8e3r79R24hPlSB4LDe0wEN8AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbk= etP GRmWvx5xUvb2ALFBBdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3= zRq k3mttto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+QgevYE0= 20q pKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7vxflUEDuzsFNBFo9U= DIB EAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuBHmpvceBRZgRasdbaMc4HJee+R9+5x= /nL PCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHE= hOV fBZO59ipSeZL5iQC6T5MsK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1D= VI9 DYo2D/zE4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7PbT= uW/ eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3vDUew1h5QU1yD= aWT 3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcmoazpiKZt91CrFPOaoXDPck/Q6= 1df mr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r+oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8= MAv 2TGXmxpVJ8Nu4je6wf96Z22fQ0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOA= HZR 5iCunYghx8b7Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQo= qj1 gwARAQABwsFlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF6TeR83xD6= Mas qXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfdn3BmvqGyh8+ouHX9jMOxi= RkM dNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx252HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB= ++/ KAmi5UJV7zsZ7uYJ5jm97LV5SLjNJIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lX= xMD rvKnXMkjseQ2oKjwrIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrf= ZtA ZAGsokRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqYo3pcN= 2OE 0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQkd0YjcqlB1E0svODHT= zcS oRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmUyXBIeq6I5z8xBcd+BQ/n/9Frkm6K7= IKP 3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhkvMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeW= Iys s6uTiyF+ZbJSo2XOKVc3YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3D40Nd -----END PGP PUBLIC KEY BLOCK----- --------------5C1C3F4E02CAC5AEDD18C239-- --em8G1avOCbarTiGoblCbuADiPhlezibmL-- --ISmehY6OtyOn7x5w0lOpziRHotUI2VnEH Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsF5BAABCAAjFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAmAUR68FAwAAAAAACgkQWrL68XsXK+oZ kg//dMTu7qDjnD6SHPQSHNSYy80acl/FhbXxQG3VZZ0mrsTZNZ4KU/ydxq+Wo/vpVV1bBiYz/VwN 6GSupOKvpXg6yjxgRtamTIm0pirriqf4b5isWXIv08KsaMWZ2eQuldvIoITe1WOHGcL7fW6hMUWs UZJmNiiad7E1GYQiOdxAg9/MO8o4nyrs2bdY2TK0txAUHuCe9XVibfaiRPeknpjABXp/pak+uCJJ wwj5z1/fSV4OaLUYENY3T6RT5I0NZx4Aw8LZt2S5Rosl81N21e/loHbUShuQQ6FrwOKtHaobzik3 cAa/7otZiZ3NOnQe6n8fhKduJJcffhuDMaEyANLJPtR5GVHjx0+xm0PS0Hwudu/tUSdnmy4n/2Kb JUTenMd/TR7y/X17zJvaNxmUWvzli2lNxg4xxwnGjogl8mSV03K0R1nVpmoIp6uD7RejA1cf9oyy c3/+X9FEA7Q/k9/mfIXkGy+ZBklYuF9jROFPG0LBG0iV0oPHpV7kvuNgxH+1lRFmRJ2b4Qq/8UC4 k4IARIBuhkTlvcvPgf6I9FmfH8izlKiVvvtWymc3MxeUJ4+eyxx3QSvY8SqafNNcF0hzHuI30Tat /VwT8wiEWigeXqI4LaAq7yGR65UNTgiKzuL9tryJ1aPedlIGMAD3IoK1pLb2Hxw7riNZFQpRRQzi ilM= =T9sn -----END PGP SIGNATURE----- --ISmehY6OtyOn7x5w0lOpziRHotUI2VnEH-- From nobody Fri Jan 29 09:51:30 2021 Return-Path: X-Original-To: openpgp@ietf.org Delivered-To: openpgp@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 209E53A11CD; Fri, 29 Jan 2021 09:51:24 -0800 (PST) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IESG Secretary To: "IETF-Announce" Cc: openpgp@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 7.24.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <161194268407.15178.3534496090978401841@ietfa.amsl.com> Date: Fri, 29 Jan 2021 09:51:24 -0800 Archived-At: Subject: [openpgp] Open Specification for Pretty Good Privacy (openpgp) WG Virtual Meeting: 2021-02-26 X-BeenThere: openpgp@ietf.org X-Mailman-Version: 2.1.29 List-Id: "Ongoing discussion of OpenPGP issues." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Jan 2021 17:51:24 -0000 The Open Specification for Pretty Good Privacy (openpgp) WG will hold a virtual interim meeting on 2021-02-26 from 15:00 to 17:00 Europe/Dublin (15:00 to 17:00 UTC). Agenda: Agenda tbd Information about remote participation: https://ietf.webex.com/ietf/j.php?MTID=m1b3bb4269a2ef10b9995442e09426b84 From nobody Fri Jan 29 18:14:59 2021 Return-Path: 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 5F5243A14AA for ; Fri, 29 Jan 2021 18:14:57 -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=63430gAe; dkim=pass (2048-bit key) header.d=fifthhorseman.net header.b=i28cF9lN 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 LonIxKVCRSRC for ; Fri, 29 Jan 2021 18:14:55 -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 645053A14A9 for ; Fri, 29 Jan 2021 18:14:55 -0800 (PST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019; t=1611972893; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=4SRmEAuspVMEyqS4jmUudtCumUtjh52pP3YhVzxSmko=; b=63430gAe8iwI6yb+W0G6RdcBI+JjsWe9eNAwS30ocEe+9CjBT0+RDIqBqQ8WNKE3hX4DN YTIcMS0anJ2k9L2Aw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=fifthhorseman.net; i=@fifthhorseman.net; q=dns/txt; s=2019rsa; t=1611972893; h=from : to : subject : in-reply-to : references : date : message-id : mime-version : content-type : from; bh=4SRmEAuspVMEyqS4jmUudtCumUtjh52pP3YhVzxSmko=; b=i28cF9lNkqQlio5YLMyOHjyaepuaSEqj+eiFn3JScNCxEDQ+fH9kgWQaY7/CRHAWn3FvI Y9I5HxgYStPuFNempsXDayGuUTkZI3qLg/DYpwpk45aIMfyFde7hYq3FPcSvegcRjy1jLNJ xBII/iPKJDmpuGZouXfx2Gc6vBgxiwRNwbIo6ArB09jNHbWQP7v8k2gOw3HWhN062mFxzfQ 9ByVeHjksUWkrpqTYtQU4Qtdk5uiaW+BJBcKo7bqTBN5u3oeXgPvI8Z5f/LyPRt7Z51yN5b xRsSpWY3i5e2oZWQLk9q/sk8YILMTcfjB9c3Pqz+ixckQRZfxRO+EY56Oi+Q== Received: from fifthhorseman.net (lair.fifthhorseman.net [108.58.6.98]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (No client certificate requested) by che.mayfirst.org (Postfix) with ESMTPSA id D2F1AF9A5; Fri, 29 Jan 2021 21:14:52 -0500 (EST) Received: by fifthhorseman.net (Postfix, from userid 1000) id 9553A20296; Fri, 29 Jan 2021 21:14:50 -0500 (EST) From: Daniel Kahn Gillmor To: Paul Wouters , openpgp@ietf.org In-Reply-To: <629addad-3dc3-a490-46db-5fafab95c7d5@nohats.ca> References: <161193808437.14457.1252111225434038573@ietfa.amsl.com> <629addad-3dc3-a490-46db-5fafab95c7d5@nohats.ca> Autocrypt: addr=dkg@fifthhorseman.net; prefer-encrypt=mutual; keydata= mDMEX+i03xYJKwYBBAHaRw8BAQdACA4xvL/xI5dHedcnkfViyq84doe8zFRid9jW7CC9XBiI0QQf FgoAgwWCX+i03wWJBZ+mAAMLCQcJEOCS6zpcoQ26RxQAAAAAAB4AIHNhbHRAbm90YXRpb25zLnNl cXVvaWEtcGdwLm9yZ/tr8E9NA10HvcAVlSxnox6z62KXCInWjZaiBIlgX6O5AxUKCAKbAQIeARYh BMKfigwB81402BaqXOCS6zpcoQ26AADZHQD/Zx9nc3N2kj13AUsKMr/7zekBtgfSIGB3hRCU74Su G44A/34Yp6IAkndewLxb1WdRSokycnaCVyrk0nb4imeAYyoPtBc8ZGtnQGZpZnRoaG9yc2VtYW4u bmV0PojRBBMWCgCDBYJf6LTfBYkFn6YAAwsJBwkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3Rh dGlvbnMuc2VxdW9pYS1wZ3Aub3JnL0Gwxvypz2tu1IPG+yu1zPjkiZwpscsitwrVvzN3bbADFQoI ApsBAh4BFiEEwp+KDAHzXjTYFqpc4JLrOlyhDboAAPkXAP0Z29z7jW+YzLzPTQML4EQLMbkHOfU4 +s+ki81Czt0WqgD/SJ8RyrqDCtEP8+E4ZSR01ysKqh+MUAsTaJlzZjehiQ24MwRf6LTfFgkrBgEE AdpHDwEBB0DkKHOW2kmqfAK461+acQ49gc2Z6VoXMChRqobGP0ubb4kBiAQYFgoBOgWCX+i03wWJ BZ+mAAkQ4JLrOlyhDbpHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3Jnfvo+ nHoxDwaLaJD8XZuXiaqBNZtIGXIypF1udBBRoc0CmwICHgG+oAQZFgoAbwWCX+i03wkQPp1xc3He VlxHFAAAAAAAHgAgc2FsdEBub3RhdGlvbnMuc2VxdW9pYS1wZ3Aub3JnaheiqE7Pfi3Atb3GGTw+ jFcBGOaobgzEJrhEuFpXREEWIQQttUkcnfDcj0MoY88+nXFzcd5WXAAAvrsBAIJ5sBg8Udocv25N stN/zWOiYpnjjvOjVMLH4fV3pWE1AP9T6hzHz7hRnAA8d01vqoxOlQ3O6cb/kFYAjqx3oMXSBhYh BMKfigwB81402BaqXOCS6zpcoQ26AADX7gD/b83VObe14xrNP8xcltRrBZF5OE1rQSPkMNy+eWpk eCwA/1hxiS8ZxL5/elNjXiWuHXEvUGnRoVj745Vl48sZPVYMuDgEX+i03xIKKwYBBAGXVQEFAQEH QIGex1WZbH6xhUBve5mblScGYU+Y8QJOomXH+rr5tMsMAwEICYjJBBgWCgB7BYJf6LTfBYkFn6YA CRDgkus6XKENukcUAAAAAAAeACBzYWx0QG5vdGF0aW9ucy5zZXF1b2lhLXBncC5vcmcEAx9vTD3b J0SXkhvcRcCr6uIDJwic3KFKxkH1m4QW0QKbDAIeARYhBMKfigwB81402BaqXOCS6zpcoQ26AAAX mwD8CWmukxwskU82RZLMk5fm1wCgMB5z8dA50KLw3rgsCykBAKg1w/Y7XpBS3SlXEegIg1K1e6dR fRxL7Z37WZXoH8AH Date: Fri, 29 Jan 2021 21:14:49 -0500 Message-ID: <87o8h7cgrq.fsf@fifthhorseman.net> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha256; protocol="application/pgp-signature" Archived-At: Subject: Re: [openpgp] I-D Action: draft-ietf-openpgp-crypto-refresh-00.txt X-BeenThere: openpgp@ietf.org 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: Sat, 30 Jan 2021 02:14:57 -0000 --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable On Fri 2021-01-29 11:59:31 -0500, Paul Wouters wrote: > The -00 document is just the re-generated version of RFC4880. The only > changes are the updated boilerplate and generating code differences of > the xml tools over the years, as well as the document author, role and > name/time of the draft. Thanks for this, Paul! > You can see the diff with RFC4880 using this url: > > https://tools.ietf.org//rfcdiff?url1=3Dhttps://tools.ietf.org/rfc/rfc4880= .txt&url2=3Dhttps://www.ietf.org/archive/id/draft-ietf-openpgp-crypto-refre= sh-00.txt I've reviewed this diff and I don't see any substantive changes from RFC 4880 -- just minor formatting differences. I hope other folks on the list will take a minute or two to confirm that they're also seeing the same situation. I've proposed some document editing workflow clarifications over on https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/31, including an ephemeral section (to be removed when we make it to an RFC) that describes how to collaborate on the document. The proposed ephemeral section merely echos what we've discussed here, saying: >> # Document Workflow >>=20 >> This document is built from markdown using [ruby-kramdown-rfc2629](https= ://rubygems.org/gems/kramdown-rfc2629), and tracked using [git](https://git= -scm.com/). >> The markdown source under development can be found in the file `crypto-r= efresh.md` in the `main` branch of the [git repository](https://gitlab.com/= openpgp-wg/rfc4880bis). >> Discussion of this document should take place on the [openpgp@ietf.org m= ailing list](https://www.ietf.org/mailman/listinfo/openpgp). >>=20 >> A non-substantive editorial nit can be submitted directly as a [merge re= quest](https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/new). >> A substantive proposed edit may also be submitted as a merge request, bu= t should simultaneously be sent to the mailing list for discussion. >>=20 >> An open problem can be recorded and tracked as [an issue](https://gitlab= .com/openpgp-wg/rfc4880bis/-/issues) in the gitlab issue tracker, but discu= ssion of the issue should take place on the mailing list. >>=20 >> \[Note to RFC-Editor: Please remove this section on publication.\] The merge request also includes a nice contribution to the Makefile from Vincent Breitmoser for how someone comfortable with docker can build the draft from source. Thanks, Vincent! If the editors are comfortable with this change, it'd be great to merge it into the main branch before we release -01. > We will send out the -01 version in the next couple of days. Looking forward to it! --dkg --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQQttUkcnfDcj0MoY88+nXFzcd5WXAUCYBTBGgAKCRA+nXFzcd5W XJlLAP93i64qtKe8WaK35PHwnFClkDIW1fiVtTF4/O8TPEFC4wEApy9ax+BTngnm HSOY6WBtTcrnql/+lgFHPgeAX1R7KQ8= =uju2 -----END PGP SIGNATURE----- --=-=-=--