Re: [openpgp] Guidance for Designated Expert?
Stephen Farrell <stephen.farrell@cs.tcd.ie> Fri, 17 February 2023 17:07 UTC
Return-Path: <stephen.farrell@cs.tcd.ie>
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 E5B14C151546 for <openpgp@ietfa.amsl.com>; Fri, 17 Feb 2023 09:07:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Level:
X-Spam-Status: No, score=-1.998 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, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=cs.tcd.ie
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pqihlnuIycsx for <openpgp@ietfa.amsl.com>; Fri, 17 Feb 2023 09:07:50 -0800 (PST)
Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on0716.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe0e::716]) (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 536F5C15152E for <openpgp@ietf.org>; Fri, 17 Feb 2023 09:07:49 -0800 (PST)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Alc3jxJ9lTb4kAl5t0wHz/zTaT91y0b6m7VKZp1LmLu+8OZ2sGNn3PhFRtCZUYkjTHpGnKvZ9SxhfQ+LFYFl439wrLGNL3q/iHNtEOGdG4Tobtw1Vzw9OpOwYfrcJnFaZqmoLoku6FvNuT1U22X2GHQvg0omMR26DjMLRKl/IXhukYmBqODFL3aHy+AOeTmfF7SfU1N73l/070owtfO6D1PXLf9wNtB2U+OmoHw+SCNDKPv3ulQpTdc6jFHWx+3bq+IiQUYkMT1YI3q0tWsRuBTfPK4splZXZOUbKE/idQcVvIBrGYGlqU/JOKoYTArliLKlm19L5x1Sc0kS4HiwdA==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=J6AVTaYP4h21BJakfJ1aEt5nD39SfRYmHcOn4hcNgF8=; b=PaPMkMTL6Lvmzc4Rc7HIS2yxbU8Wk6U75R+9iKRcScEjJsOaplQkNeiy/sZ+ddK2sQcVNIOJ4hurUO30F5CFJAG0kbolb9/jwQbitHXZko2zyPp06TU00RRGWKaipaPqpKvtXHrSH+hudvARVMe2FROKYpGZl/dyMoFtiTqxVyvzI1trE8CGR+6vqvRN55U4SUvoTBKOvCCxwdk8Et+nZUD8TaL3tNhIwEgrQDoIMGOyzDP9hMJEJYW39RvxdRCtgpbOuN5lmxt2KxbwZPi+J+r5qVlYhCgietBo/Ln5pFG31fyGEwQnUzeqvr68j5KQVF6SOlTVSCzBkCOie51PBg==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cs.tcd.ie; dmarc=pass action=none header.from=cs.tcd.ie; dkim=pass header.d=cs.tcd.ie; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cs.tcd.ie; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=J6AVTaYP4h21BJakfJ1aEt5nD39SfRYmHcOn4hcNgF8=; b=UdFGwCkK2PM0m6gd26vwzlVFmScVdBfAWJPd2eLLmKlg2UeDTznEdVQfGbWJuG/3bzlndgx/SWP6ehntcJmQsnaFukPi96/cPRg852Sl/u3lDQF+LxM3wb5cQsry9daZU8sshAyHWsPcwigLLdg+Tbq1L1niVivB4nuqrKpC8RitisEj13tiHpEb1vsbHyHzAXYwBr+bPZwpSYWILQ7y7ZoVWp1zwXfbdSd8x3KVRtKitzVbQrLWXexd2CfxbLdjFBbQoeqsy/wE1JbwSpV7lvgC0wYnVMdlt/Cbu83yFEjlNXydPRj131wpyRyhjBESGJsaIvIfzq/vVfYPkmx0Xw==
Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=cs.tcd.ie;
Received: from DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15) by AS8PR02MB6536.eurprd02.prod.outlook.com (2603:10a6:20b:25d::13) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6111.12; Fri, 17 Feb 2023 17:07:43 +0000
Received: from DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::cd:791c:5e7a:a678]) by DB7PR02MB5113.eurprd02.prod.outlook.com ([fe80::cd:791c:5e7a:a678%4]) with mapi id 15.20.6111.012; Fri, 17 Feb 2023 17:07:43 +0000
Message-ID: <d89f3c5e-1f90-fa8f-af04-c5dfb3ad48c4@cs.tcd.ie>
Date: Fri, 17 Feb 2023 17:07:42 +0000
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.1
To: Paul Wouters <paul@nohats.ca>, Daniel Kahn Gillmor <dkg@fifthhorseman.net>
Cc: openpgp@ietf.org
References: <87v8kgm3ah.fsf@fifthhorseman.net> <87sffhkvjb.fsf@fifthhorseman.net> <ad3d14d0-e876-060f-38d6-e3c43a6601ce@nohats.ca>
From: Stephen Farrell <stephen.farrell@cs.tcd.ie>
In-Reply-To: <ad3d14d0-e876-060f-38d6-e3c43a6601ce@nohats.ca>
Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="------------0LYHxoHNRxB9SGMYPjfp37VY"
X-ClientProxiedBy: DB8PR09CA0032.eurprd09.prod.outlook.com (2603:10a6:10:a0::45) To DB7PR02MB5113.eurprd02.prod.outlook.com (2603:10a6:10:77::15)
MIME-Version: 1.0
X-MS-Exchange-MessageSentRepresentingType: 1
X-MS-PublicTrafficType: Email
X-MS-TrafficTypeDiagnostic: DB7PR02MB5113:EE_|AS8PR02MB6536:EE_
X-MS-Office365-Filtering-Correlation-Id: f9b486c6-8fc3-412a-1f6f-08db11097bed
X-MS-Exchange-SharedMailbox-RoutingAgent-Processed: True
X-TCD-Routed-via-EOP: Routed via EOP
X-TCD-ROUTED: Passed-Transport-Routing-Rules
X-MS-Exchange-SenderADCheck: 1
X-MS-Exchange-AntiSpam-Relay: 0
X-Microsoft-Antispam: BCL:0;
X-Microsoft-Antispam-Message-Info: 0XKBJv2EK9ymxf5VrONDJlpP5+joV/bdArkxWwOd+UL0whXdPHLlJxCcN6m32jcvyIkN040/kqQ6246SqdHARl+5RNW47OUujAYw8MM8KT7XJeJ/ZqwH9VzsZWi3pTNoUxVUW5IQ9A61r1YRJ2A9ZLbKBVfXLejqEqqpGEa0s0Pt3+Yf2VHp86ZxYVQPyLw7DdyHMpbnVLy7Y6Mjy2oInWfF7brYs1Fx2VQrzVJpgXCiXACCbxHEb3itVrlkOXICyaRpSbLmgnAgMNakRp5bsZXsBCE4myeEcnzei1Xv20XYjpgPFC6RSoQ6m3DZH1u7VqPMayg4EGd0z/k00h7CYUgYH9JJRCNr17WLeyuOHtd1zRiG23ABw57v80Icl20ujIC9+YAdDfB6X5Em/ukeqUGRDodI5Mx+HTRCTjdjY3xXXIGotxWCodWTgdMhU0BfovI8sfl7Tbyvpn3W56ijdAieWh55u5mGpl9aLX8wnv1L60ALANUrKQI/idWzqAuoN6vldYy9x113YAIsdOV/4rIqkc+kXjT7hz3J++/MxYDmWpUxPt/Sc1VuAgVSDETbNKWhbi71fLA18ECG+cMlQHGOEZ1I8G8i2KYHlrGTosRcdd3Vwd+ie6SWFMUz25w39s7EYTAj1spoORd3JS+vSquVrF9+CAFz9yIbOuw6GvcMOV1z8e++q97XcLJ02l6MSQsV/4rAv6F4itlab1Fdr6/q5+g4qVvyHSYoVskLwPU=
X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:DB7PR02MB5113.eurprd02.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230025)(4636009)(136003)(39860400002)(346002)(366004)(376002)(396003)(451199018)(5660300002)(235185007)(31686004)(44832011)(41300700001)(2906002)(4326008)(316002)(66556008)(110136005)(66476007)(8676002)(66946007)(786003)(478600001)(966005)(6486002)(33964004)(2616005)(53546011)(6506007)(21480400003)(186003)(26005)(6512007)(8936002)(36756003)(31696002)(86362001)(41320700001)(83380400001)(38100700002)(43740500002)(45980500001); DIR:OUT; SFP:1102;
X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1
X-MS-Exchange-AntiSpam-MessageData-0: 3IhXONmfO++qH5eMwyD+8lY7ZEKhpabu571SsVAxh4pQHcf0HNVAkytrTJ158MELYOXfqitieE1zVtWosiE+F4lkz3FKdsxJevCR0T1uzbEDN5zZIzMSszVg0QYCmnVWBpMmE+Pk0oDW8AE98mOxCvKYVZeGPAjuaO9e3RPnxuVxLl8I9fTWW9FLPcxGcT64BgA6xdfe16wJB9CMsbjJfVTUaiwuR6QjzREVhvsHBfd0SI5lHVzn8Nl+Azq3+grC0VGql/yARRCoizj95OCTHutZ3tUVZX1ze8FmEu1b4Rpa69c9UZXKolvYqHarO6b7AZ5gBFJqwTdBH0so1mVlGTzm7s8C4VSMjb3danf7h+ppQzLGyvchDHKu1al9MQKeexhv4LmWwOYXhkCoIH3Yfmg9is/9L+PafWEDZvu5MAJknDSFUn788s193AGlaae9KcAi5HJBNGwOe5NTq8jzcRx6Vzsx7r9GrG0CJ8LHBY8pNkRo4bDBLD0Nh5gak6USLkjaZvlKZzt0UbfnOE0sltMl+BiGYwqmF14eBEcbRqqTQlWvEOSqhTwpUpf5TW2gJQ6yylsVQhvWb9UZnY60OpHzqIvHD+h6rmkeeM5erM9mOXJFeIXPzOy0NUc+SOPMndQIAGIAu/n2dlyHUn1c4FnajaSUat8bgsyTDMrDwInr3xzASjAcInJQaaTUkt2i7x/XrrrJI/EqwU6a5lbeNUfikJLXZNJVY6pbZigrxOPJvTbontLFblKJ3GUfy4m6G47iQZEzNfvIJB01xH+f8hREA+BphH7pu3xbvY0uRob+pAZoMXtUVknwKZbF6N1aWx0BkOwDfy3WygrSuPH/bcF/KMSHg4RlIg0DEFT5+4viSh6qzt5KoiXvfak42lOGImBtPXj9GwbR6PZiuMaHe6bDxT0Ldozr0iPGfH8zdFqaggu5cq+Bxb9UTKs+8/zB6u09KNdq1/JMj2dHDgXxxvtVP6CkLrjqxfS2rtXOfeATh53LvGRspWIdTwpy4SJ7mmstTklHaIT3g2YDSNPQeerjQPX8SYYuCnkJVNoqfRwbVRbGwBnftIvMtO8M2D5SF8sKNYoUAlXZ+iOq2GsGn7cqPBnriGHLFDftRqCNzNpfJhSc3MOwjcauqhNxzeGaqYsNVtWXh6BEFX+BbSCt6q2UddtpAI2Pn0gVu7YcFuzCGtXcdRldJpXxdtL6NO6vct7qMgJ7uRXqmjNRJOKl6nux7sbnkG9yODANfsL5wEsThPUzE+QvpLr4F3L+dmO83DoQKH6PiwtmTA+nSmDan7QFdpxryDKsDy/oWaS/5KWU6VX9XJa+be0jQypjoSWu1yA3iyHGR5QwXuR+pDFtVw0M735lr90fpjBLNSU2wTzzZxhKx1IQnRvoBL+kvRHWkpDtYtRiubiCXLV39Hb9xGCbnj7dGassDeTBQ+Mg1sEEAAHCZDUlJPC/MSHQYYuTZh4UribIAZNPVGTfNuIczGJRca1IdiXxwd+FqDppT86MkYiziPUNX73euhlqP63ueHNBIRVwdYD32/09pyTK2wQ2Obv78UCIJUrzoG7C4T6e3ihPb1JPSdJE4W0/AhmZ
X-OriginatorOrg: cs.tcd.ie
X-MS-Exchange-CrossTenant-Network-Message-Id: f9b486c6-8fc3-412a-1f6f-08db11097bed
X-MS-Exchange-CrossTenant-AuthSource: DB7PR02MB5113.eurprd02.prod.outlook.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 Feb 2023 17:07:43.7541 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-CrossTenant-Id: d595be8d-b306-45f4-8064-9e5b82fbe52b
X-MS-Exchange-CrossTenant-MailboxType: HOSTED
X-MS-Exchange-CrossTenant-UserPrincipalName: GNrg9nA6H8oelMnZNUbaJ4VERFZUCQU4HJpGvBVJK6XPlsD0mXkXvqSAtMGjt45v
X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS8PR02MB6536
Archived-At: <https://mailarchive.ietf.org/arch/msg/openpgp/2Ijtb6KHTFNKkkjWIapd-sYSdEY>
Subject: Re: [openpgp] Guidance for Designated Expert?
X-BeenThere: openpgp@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Ongoing discussion of OpenPGP issues." <openpgp.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/openpgp>, <mailto:openpgp-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/openpgp/>
List-Post: <mailto:openpgp@ietf.org>
List-Help: <mailto:openpgp-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/openpgp>, <mailto:openpgp-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 17 Feb 2023 17:07:56 -0000
Hiya, dkg and I discussed this in our chairs' call today. We think this is one where it should be fine to allow the editor discretion to make changes as he sees fit. (Partly, that's on the basis that IANA considerations guidance like this is always noodled on during IETF last call and IESG review, so we don't have any real worry that we'll end up with something awful here.) So, Paul, please merge your preferred text based on the MR and your comments below. Cheers, S. On 08/02/2023 02:02, Paul Wouters wrote: > On Tue, 7 Feb 2023, Daniel Kahn Gillmor wrote: > >> I've just knocked together >> https://gitlab.com/openpgp-wg/rfc4880bis/-/merge_requests/232, which >> adds text to the IANA considerations section: >> >> ------------ >> --- a/crypto-refresh.md >> +++ b/crypto-refresh.md >> @@ -3331,6 +3331,31 @@ Because this document obsoletes {{RFC4880}}, >> IANA is requested to update all reg >> OpenPGP is highly parameterized, and consequently there are a number >> of considerations for allocating parameters for extensions. >> This section describes how IANA should look at extensions to the >> protocol as described in this document. >> >> +Most of these registries have been moved the SPECIFICATION REQUIRED >> method. > > Most registries have been updated to use a Specification Required policy. > >> +As indicated in {{RFC8126}}, the designated expert is expected to >> ensure that a clear and detailed specification capable of producing >> interoperable implementations is permanent and readily available. >> +Because interoperability in the store-and-forward domains where >> OpenPGP most often used is made more challenging by combinatorial >> explosions of options, and because many of these registries are >> limited in size, the designated expert is expected to minimize >> codepoint squatting and vanity registrations by taking the following >> steps: >> + >> +- Ensure that the specification is concretely useful. >> + Does a clear use case exist? >> + Is that use case *not* handled by any existing mechanism in OpenPGP? >> + Is the referenced specification fit for purpose for that use case? > > I don't think these are very relevant for specification required. All > that is really needed is that the specification is complete enough for > implementors to be able to implement this. Whether a "use case" is > covered or not is very subjective. > >> +- Ensure that the specification is complete. > > Right. > >> + Does it describe the expected semantics or behavior when the >> proposed codepoint is present? >> + (For example, when adding a new elliptic curve, are all tables >> referencing the curve populated as expected?) > > Makes sense, although it feels like just an example of "specification is > complete" > >> + Do the expected semantics or behavior when the codepoint is *not* >> present conform to existing baseline deployments? >> + Does the specification identify *where* the codepoint is expected >> to be observed? >> + (For example, when designating a new signature subpacket, does the >> specification indicate which types of signature it is to be found in?) >> + Does the specification clearly identify the expected semantics or >> behavior when the code point is observed in unexpected places? > > I am not sure about these. I would probably formulate it more > generically. Eg If the code point is a modular extension that adds a new > feature that is okay. If the code point would modify existing behaviour, > it should probably be IETF stream RFC required. (eg if it Updates: the > core spec by modifying its behaviour) > >> +- Ensure that the specification and its use case is not contradictory >> to existing registered codepoints. > > I don't know what this really means. > >> + Can the the specification or its deployment produce confusion or >> interoperability failures when it is observed in combination with some >> other mechanism in OpenPGP? > > This comes down to the above. If it is a modular extension, a new > feature that is independent of the existing features, or just a new > algorithm or cipher, then it would be fine. This would not require > Update:ing this draft. If it wants to update this draft, it must be > by standards action RFC required. > >> +- Ensure that any registered algorithms meet the security >> requirements of the community and the message structures for which >> they are proposed to be used. >> + When a novel cryptographic approach is considered, is it strong >> enough to be worth deploying? >> + Are there enough diverse expressions of interest to determine a >> sense of the security needs of the community that would adopt the >> feature? >> + Does the proposed algorithm meet those security needs? > > I'm not sure I agree with all of this. For example "requirements of the > community" might be hard for nation state ciphers, where the community > doens't really see a point or cannot prove it means any security > standard. If Wakanda wants its vanity cipher Foo, and we have no idea > about Foo's security properties, we should still let them have the > code point and use it. > > Paul > > _______________________________________________ > openpgp mailing list > openpgp@ietf.org > https://www.ietf.org/mailman/listinfo/openpgp
- [openpgp] Guidance for Designated Expert? Daniel Kahn Gillmor
- Re: [openpgp] Guidance for Designated Expert? Daniel Kahn Gillmor
- Re: [openpgp] Guidance for Designated Expert? Paul Wouters
- Re: [openpgp] Guidance for Designated Expert? Daniel Kahn Gillmor
- Re: [openpgp] Guidance for Designated Expert? Stephen Farrell