Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 (was "Re: AUTH48: RFC-to-be 9381 <draft-irtf-cfrg-vrf-15> for your review")
Christopher Wood <caw@heapingbits.net> Wed, 16 August 2023 21:40 UTC
Return-Path: <caw@heapingbits.net>
X-Original-To: auth48archive@ietfa.amsl.com
Delivered-To: auth48archive@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3215C15198E; Wed, 16 Aug 2023 14:40:02 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.105
X-Spam-Level:
X-Spam-Status: No, score=-7.105 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, 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=heapingbits.net header.b="qKnsbUIc"; dkim=pass (2048-bit key) header.d=messagingengine.com header.b="U8ac0REE"
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 PRgrVtSQiJi2; Wed, 16 Aug 2023 14:39:58 -0700 (PDT)
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0AE0DC14CF1E; Wed, 16 Aug 2023 14:39:57 -0700 (PDT)
Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 1E8A35C0081; Wed, 16 Aug 2023 17:39:57 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Wed, 16 Aug 2023 17:39:57 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=cc:cc:content-transfer-encoding:content-type:content-type :date:date:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to; s=fm1; t=1692221997; x=1692308397; bh=LlbcWYK5RuLfuwn6WXcH1QI2B whMg1TIq64zcgA2jq8=; b=qKnsbUIcDuXkq3aUwd6xQwqPnHDUPFJnc+cmib52J NcEVyHi9X9M07r870qyAKBZu2cctBwRY60HsloZeahxrgPhLIdy2Gs6onjnSDTEJ GmdJ/3sdUhpjXE0iVVMt4V9CKk6LQ3l2c84by1cmhYSR+KC/C2GIcPwmr5xNR30y qavwzTxPAjUlAr6xNJoemhY5nZSCndIXofg5hxeNsSNOyt/kHrg8y5V3uC9ZeMFH vCJ8nmXb1zZWaqm6YjbwvKIAukrxkJLV7A1AhdOG3JqtzLGWpj5parlH9g5ZGJpC ghPVNrzFxDPFR2varclfBuuhYpmwSKRTV8/e8ccOwiAsQ==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1692221997; x=1692308397; bh=LlbcWYK5RuLfuwn6WXcH1QI2BwhMg1TIq64 zcgA2jq8=; b=U8ac0REEQbwdrCLz+j5gq7HsdMjzRZxiUKrMtH8zPghmSzNNmvc SBGdb+xPDR1lNmzw7sWU962FWDbBNmoFSbcwmedvgK0oditisscdOquMRox2uDI/ C835nNXGRMXJHOzDBOrfIZuokn3je5dl60qbaNzNehvJWQJOk/lcHNgmPNcyJRHf wAEhrG65U5QlJHwT9qzRwM7h7Q3o0rhZoS8LDx4HcQbAckt6ogaC2eorZ/tsNEDj hpIDtQ9lc8Zfgii/1Sf+RQr6+IVKdPbEqiqm5AGIeqi7l94N4BC9f9uCKXBRqvcB CLRPdzqmimK7zLczZwT2Zze5MN1WQ1ZovfA==
X-ME-Sender: <xms:LELdZFpjVhMxNCZXkjhYxjx_c3wuWI6VDgnO73AxVFfJet3aBz5QPw> <xme:LELdZHpF-cP3UKqW5vc2gHwWP64DrgyEG-ySxPhzLKeT4HivvAvKfaxO7waxe04nZ Yu3-svZVymDDVKJCWU>
X-ME-Received: <xmr:LELdZCOJZjVTiiYw6Z1_PM3i8g7--Xj5b32GY0OqDIbMoeoFWOfyCKlMR7MDWSRP2XYJlURf4i8KZazAmvljHyY6Zyd3o-4VBLWJ0TSdfkB5Dw6e>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedruddutddgtdduucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurheptgfghfggufffkfhfvegjvffosehtqhhmtdhhtdejnecuhfhrohhmpeevhhhr ihhsthhophhhvghrucghohhougcuoegtrgifsehhvggrphhinhhgsghithhsrdhnvghtqe enucggtffrrghtthgvrhhnpeettdegteefkeegjedttdejffevfeejvdejueehudevveel fedtkeeiudettddugfenucffohhmrghinheprhhftgdqvgguihhtohhrrdhorhhgpdhirg gtrhdrohhrghdphihprdhtohdpihgvthhfrdhorhhgpdgsuhdrvgguuhenucevlhhushht vghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinh hgsghithhsrdhnvght
X-ME-Proxy: <xmx:LELdZA5CBefMvH6kyhuFg1B3aaVJITStzoZiHa7oK-5iyjytBKSaUA> <xmx:LELdZE54wVssfObB40IsAhOhyEuiCIcd9TO5R2_MXcENDbZg97oE2A> <xmx:LELdZIjpRPAqd7R9ZHAV963HzBxX1E3gyo8bFeXCei9BcJpt7Un8Ig> <xmx:LULdZFECR_6N2giPmhNOvQaTlCOIUOX4C6CAj4kqoPj7UhhCTRgavA>
Feedback-ID: i2f494406:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 16 Aug 2023 17:39:55 -0400 (EDT)
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
From: Christopher Wood <caw@heapingbits.net>
Mime-Version: 1.0 (1.0)
Date: Wed, 16 Aug 2023 17:39:44 -0400
Message-Id: <6CAF9BE1-FB5F-4B09-A116-540DD5633F0F@heapingbits.net>
References: <6FCF22F0-FE1F-4255-95EC-8FF099BEBF71@amsl.com>
Cc: "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>, Sharon Goldberg <sharon.goldbe@gmail.com>, Leonid Reyzin <leonid.reyzin@gmail.com>, Tim Taubert <ttaubert@apple.com>, Dimitrios Papadopoulos <dipapado@cse.ust.hk>, IRSG <irsg@irtf.org>, Jan Včelák <jvcelak@ns1.com>, Nick Sullivan <nick@cloudflare.com>, rfc-editor@rfc-editor.org, auth48archive@rfc-editor.org
In-Reply-To: <6FCF22F0-FE1F-4255-95EC-8FF099BEBF71@amsl.com>
To: Lynne Bartholomew <lbartholomew@amsl.com>
X-Mailer: iPhone Mail (20G75)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/ngT6l_oCgFO3S2XXgtBZZPF5CzQ>
Subject: Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 (was "Re: AUTH48: RFC-to-be 9381 <draft-irtf-cfrg-vrf-15> for your review")
X-BeenThere: auth48archive@rfc-editor.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Archiving AUTH48 exchanges between the RFC Production Center, the authors, and other related parties" <auth48archive.rfc-editor.org>
List-Unsubscribe: <https://mailman.rfc-editor.org/mailman/options/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/auth48archive/>
List-Post: <mailto:auth48archive@rfc-editor.org>
List-Help: <mailto:auth48archive-request@rfc-editor.org?subject=help>
List-Subscribe: <https://mailman.rfc-editor.org/mailman/listinfo/auth48archive>, <mailto:auth48archive-request@rfc-editor.org?subject=subscribe>
X-List-Received-Date: Wed, 16 Aug 2023 21:40:02 -0000
Thanks, Lynne. I approve publication of RFC9383. Sent from my iPhone > On Aug 16, 2023, at 5:19 PM, Lynne Bartholomew <lbartholomew@amsl.com> wrote: > > Dear Chris, Eliot, Sharon, Leonid, and Tim, > > Thank you for your replies. We have updated RFCs-to-be 9381 and 9383 to use "Prover" and "Verifier". > > ** RFC-to-be 9381: The latest files are posted here. Please refresh your browser: > > https://www.rfc-editor.org/authors/rfc9381.txt > https://www.rfc-editor.org/authors/rfc9381.pdf > https://www.rfc-editor.org/authors/rfc9381.html > https://www.rfc-editor.org/authors/rfc9381.xml > https://www.rfc-editor.org/authors/rfc9381-diff.html > https://www.rfc-editor.org/authors/rfc9381-rfcdiff.html > https://www.rfc-editor.org/authors/rfc9381-auth48diff.html > https://www.rfc-editor.org/authors/rfc9381-lastdiff.html > https://www.rfc-editor.org/authors/rfc9381-lastrfcdiff.html > > https://www.rfc-editor.org/authors/rfc9381-xmldiff1.html > https://www.rfc-editor.org/authors/rfc9381-xmldiff2.html > https://www.rfc-editor.org/authors/rfc9381-alt-diff.html > > > ** RFC-to-be 9383: The latest files are posted here. Please refresh your browser: > > https://www.rfc-editor.org/authors/rfc9383.txt > https://www.rfc-editor.org/authors/rfc9383.pdf > https://www.rfc-editor.org/authors/rfc9383.html > https://www.rfc-editor.org/authors/rfc9383.xml > https://www.rfc-editor.org/authors/rfc9383-diff.html > https://www.rfc-editor.org/authors/rfc9383-rfcdiff.html > https://www.rfc-editor.org/authors/rfc9383-auth48diff.html > https://www.rfc-editor.org/authors/rfc9383-lastdiff.html > https://www.rfc-editor.org/authors/rfc9383-lastrfcdiff.html > > https://www.rfc-editor.org/authors/rfc9383-xmldiff1.html > https://www.rfc-editor.org/authors/rfc9383-xmldiff2.html > > We will continue the publication process for RFC-to-be 9381. > > RFC-to-be 9383 will be published when RFC-to-be 9382 is published, as noted on <https://www.rfc-editor.org/auth48/rfc9383>. > > Thanks again! > > RFC Editor/lb > > >> On Aug 16, 2023, at 8:06 AM, Tim Taubert <ttaubert@apple.com> wrote: >> >> Capitalized is fine to me as well. Thanks! >> >> — Tim >> >> >>>> On 16. Aug 2023, at 02:48, Leonid Reyzin <leonid.reyzin@gmail.com> wrote: >>> >>> Agreed. Capitalized makes more sense to me, but I don't feel strongly. Thanks for catching! >>> >>> Since my email forwarding seems wonky still, can you contact me at leonid.reyzin@gmail.com instead of @bu? > >> On Aug 15, 2023, at 3:55 PM, Sharon Goldberg <sharon.goldbe@gmail.com> wrote: >> >> I agree with Chris. Go with capitals. >> >> Thanks >> Sharon > >> On Aug 15, 2023, at 1:53 PM, Independent Submissions Editor (Eliot Lear) <rfc-ise@rfc-editor.org> wrote: >> >> I generally prefer lowercase - we're not writing legal contracts here, but the authors can have the final say, so long as they agree. >> >> Eliot >> >>> On 15.08.23 22:42, Lynne Bartholomew wrote: >>> Hi, Chris and *Eliot. >>> >>> Chris, thank you for the quick reply! We'll wait a bit to see if anyone objects; if not, we'll update per your note. >>> >>> *Eliot, as ISE for RFC-to-be 9383, please let us know if you're OK with us updating per Chris's note. >>> >>> Thanks again! >>> >>> RFC Editor/lb > >> >> On Tue, Aug 15, 2023 at 4:34 PM Christopher Wood <caw@heapingbits.net> wrote: >> Hi Lynne, >> >> Specifications I've worked with in the past have capitalized these sorts of terms as proper nouns, but I don't think it really matters much. If we need to choose, and assuming no one else cares strongly, I would go with Prover and Verifier. >> >> Best, >> Chris >> >>> On Tue, Aug 15, 2023, at 3:09 PM, Lynne Bartholomew wrote: >>> Dear authors of RFCs-to-be 9381 (draft-irtf-cfrg-vrf-15) and 9383 >>> (draft-bar-cfrg-spake2plus-08), >>> >>> Apologies, but while preparing RFC-to-be 9381 for publication, we found >>> two items that we had previously flagged internally for these two >>> documents but that were not conveyed to you when these documents were >>> moved to the AUTH48 state last Spring: >>> >>> These documents use both "prover" and "Prover", and both "verifier" and >>> "Verifier" (e.g., "the prover", "the Prover", "the verifier", "the >>> Verifier"). >>> >>> We believe that usage (capitalization or not) for these terms within >>> and between these documents should be consistent. Please let us know >>> which form is preferred for each. >>> >>> Thank you, and again, apologies for not asking about this earlier. >>> >>> RFC Editor/lb >>> >>>> On May 22, 2023, at 10:13 AM, Lynne Bartholomew <lbartholomew@amsl.com> wrote: >>>> >>>> Dear Dimitris, Sharon, and Jan, >>>> >>>> We have noted your approvals on the AUTH48 status page: >>>> >>>> https://www.rfc-editor.org/auth48/rfc9381 >>>> >>>> As this document is part of Cluster C450 (https://www.rfc-editor.org/cluster_info.php?cid=C450) and normatively depends on RFC-to-be 9380 (draft-irtf-cfrg-hash-to-curve), this document will be published when RFC-to-be 9380 is published. You can follow the progress of RFC-to-be 9380 at <https://www.rfc-editor.org/auth48/rfc9380>. >>>> >>>> Thank you! >>>> >>>> RFC Editor/lb >>>> >>>> >>>>> On May 22, 2023, at 1:43 AM, Jan Včelák <jvcelak@ns1.com> wrote: >>>>> >>>>> Thank you for the edits, everyone. The document looks good to me. I >>>>> also approve it for publication. >>>>> >>>>> Jan >>>> >>>>> On May 20, 2023, at 8:50 AM, Sharon Goldberg <sharon.goldbe@gmail.com> wrote: >>>>> >>>>> Thank you, I approve this as well. >>>>> >>>>> On Sat, May 20, 2023 at 4:05 AM Dimitrios Papadopoulos <dipapado@cse.ust.hk> wrote: >>>>> Many thanks for the detailed editing. >>>>> >>>>> I also approve its publication. >>>>> >>>>> Regards, >>>>> -Dimitris >>>>> >>>>>> On 19 May 2023, at 11:52 PM, Leonid Reyzin <reyzin@bu.edu> wrote: >>>>>> >>>>>> Thank you! I now approve it for publication. >>>>>> >>>>>> (NB: Jan, Sharon, Dimitris: you each need to send your approval before it can be published.) >>>>>> >>>>>> On Thu, May 18, 2023 at 6:29 PM Lynne Bartholomew <lbartholomew@amsl.com> wrote: >>>>>> Hi, Leo. No worries! Fixed, and the latest files are posted here. Please refresh your browser: >>>>>> >>>>>> https://www.rfc-editor.org/authors/rfc9381.txt >>>>>> https://www.rfc-editor.org/authors/rfc9381.pdf >>>>>> https://www.rfc-editor.org/authors/rfc9381.html >>>>>> https://www.rfc-editor.org/authors/rfc9381.xml >>>>>> https://www.rfc-editor.org/authors/rfc9381-diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9381-rfcdiff.html >>>>>> https://www.rfc-editor.org/authors/rfc9381-auth48diff.html >>>>>> https://www.rfc-editor.org/authors/rfc9381-lastdiff.html >>>>>> https://www.rfc-editor.org/authors/rfc9381-lastrfcdiff.html >>>>>> >>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff1.html >>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff2.html >>>>>> https://www.rfc-editor.org/authors/rfc9381-alt-diff.html >>>>>> >>>>>> Thank you! >>>>>> >>>>>> RFC Editor/lb >>>>>> >>>>>>> On May 17, 2023, at 3:00 AM, Leonid Reyzin <reyzin@bu.edu> wrote: >>>>>>> >>>>>>> Oh, so sorry for that bug. It should be 3.2.1.3. Could you please fix that? >>>>>>> >>>>>>> On Tue, May 16, 2023 at 4:00 AM Lynne Bartholomew <lbartholomew@amsl.com> wrote: >>>>>>> Dear Leo, >>>>>>> >>>>>>> Thank you for the latest updated XML file as well! >>>>>>> >>>>>>> Thanks also for the working NIST URL. We updated the reference listing accordingly. >>>>>>> >>>>>>> However, please note that the NIST document associated with this URL does not have a Section 3.1.2.3. Which section should be cited in the following sentence (from Section 5.5 of this document)? >>>>>>> >>>>>>> * The EC group G is the NIST P-256 elliptic curve, with the finite >>>>>>> field and curve parameters as specified in Section 3.1.2.3 of >>>>>>> [SP-800-186] and Section 2.6 of [RFC5114]. >>>>>>> >>>>>>> We have posted the latest files here: >>>>>>> >>>>>>> https://www.rfc-editor.org/authors/rfc9381.txt >>>>>>> https://www.rfc-editor.org/authors/rfc9381.pdf >>>>>>> https://www.rfc-editor.org/authors/rfc9381.html >>>>>>> https://www.rfc-editor.org/authors/rfc9381.xml >>>>>>> https://www.rfc-editor.org/authors/rfc9381-diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9381-rfcdiff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9381-auth48diff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9381-lastdiff.html >>>>>>> https://www.rfc-editor.org/authors/rfc9381-lastrfcdiff.html >>>>>>> >>>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff1.html >>>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff2.html >>>>>>> https://www.rfc-editor.org/authors/rfc9381-alt-diff.html >>>>>>> >>>>>>> Thanks again! >>>>>>> >>>>>>> RFC Editor/lb >>>>>>> >>>>>>>> On May 12, 2023, at 7:43 AM, Leonid Reyzin <reyzin@bu.edu> wrote: >>>>>>>> >>>>>>>> Dear Lynne, >>>>>>>> >>>>>>>> Thanks so much for the quick turnaround! I made the change I had failed to make the previous time; fixed another nit for clarity; changed the mailing addresses for two of the authors; and provided an alternative URL for the NIST document. All new changes are annotated with [auth48response] in the attached xml file. >>>>>>>> >>>>>>>> Best, >>>>>>>> >>>>>>>> Leo >>>>>>>> >>>>>>>> On Thu, May 11, 2023 at 8:31 PM Lynne Bartholomew <lbartholomew@amsl.com> wrote: >>>>>>>> Dear Leo, >>>>>>>> >>>>>>>> Thank you very much for the updated XML file! The updates and your notes were most helpful. >>>>>>>> >>>>>>>> Regarding this item: >>>>>>>> >>>>>>>> <!-- [auth48response] Removed "four" becuase it's incorrect. Added "to" before >>>>>>>> "each other". ... >>>>>>>> >>>>>>>> We did not see this update. Should "unlikely to equal each other or to any inputs" be changed to "unlikely to be equal to each other or to any inputs"? >>>>>>>> >>>>>>>> Regarding your note related to the stability of [X25519]: Thank you for the information. We left as is; seventeen years seems a good track record and indicates that it should remain stable. >>>>>>>> >>>>>>>> The latest files are posted here (please refresh your browser): >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9381.txt >>>>>>>> https://www.rfc-editor.org/authors/rfc9381.pdf >>>>>>>> https://www.rfc-editor.org/authors/rfc9381.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9381.xml >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-rfcdiff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-auth48diff.html >>>>>>>> >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-alt-diff.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff1.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff2.html >>>>>>>> https://www.rfc-editor.org/authors/rfc9381-alt-diff.html >>>>>>>> >>>>>>>> Thanks again! >>>>>>>> >>>>>>>> RFC Editor/lb >>>>>>>> >>>>>>>> >>>>>>>>> On May 10, 2023, at 10:58 AM, Leonid Reyzin <reyzin@bu.edu> wrote: >>>>>>>>> >>>>>>>>> Dear Lynne et al., >>>>>>>>> >>>>>>>>> Attaching the updated XML file. Responses to edits / comments, as well as a few new minor edits, are explained in the comments prefixed with [auth48response]. >>>>>>>>> >>>>>>>>> Thank you very much for such a thorough pass through the document and for all the excellent suggestions! >>>>>>>>> >>>>>>>>> Sincerely, >>>>>>>>> >>>>>>>>> Leo >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Thu, Apr 27, 2023 at 5:40 PM Lynne Bartholomew <lbartholomew@amsl.com> wrote: >>>>>>>>> Hi, Jan. Thank you for checking in with us! >>>>>>>>> >>>>>>>>> RFC Editor/lb >>>>>>>>> >>>>>>>>>> On Apr 26, 2023, at 10:19 PM, Jan Včelák <jvcelak@ns1.com> wrote: >>>>>>>>>> >>>>>>>>>> Hello Lynne. >>>>>>>>>> >>>>>>>>>> Thank you. We will look at the questions and get back to you soon. >>>>>>>>>> >>>>>>>>>> Jan >>>>>>>>>> >>>>>>>>>> Dne pá 21. 4. 2023 20:13 uživatel Lynne Bartholomew <lbartholomew@amsl.com> napsal: >>>>>>>>>> Dear authors, >>>>>>>>>> >>>>>>>>>> Checking in with you regarding the status of this document. Please review the questions below, and let us know how this document should be updated. >>>>>>>>>> >>>>>>>>>> The latest files are posted here: >>>>>>>>>> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.xml >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.pdf >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.txt >>>>>>>>>> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-diff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-rfcdiff.html >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-alt-diff.html >>>>>>>>>> >>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff1.html >>>>>>>>>> >>>>>>>>>> The AUTH48 status page is here: >>>>>>>>>> >>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9381 >>>>>>>>>> >>>>>>>>>> Thank you! >>>>>>>>>> >>>>>>>>>> RFC Editor/lb >>>>>>>>>> >>>>>>>>>>> On Apr 17, 2023, at 11:03 PM, rfc-editor@rfc-editor.org wrote: >>>>>>>>>>> >>>>>>>>>>> Authors, >>>>>>>>>>> >>>>>>>>>>> While reviewing this document during AUTH48, please resolve (as necessary) the following questions, which are also in the XML file. >>>>>>>>>>> >>>>>>>>>>> 1) <!-- [rfced] Please ensure that the guidelines listed in >>>>>>>>>>> Section 2.1 of RFC 5743 have been adhered to in this document. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2) <!-- [rfced] Would you like the references to be listed in >>>>>>>>>>> alphanumeric order? --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 3) <!-- [rfced] Jan: We have seen both "Vcelak" and "Včelák" >>>>>>>>>>> in recent RFCs-to-be. Please let us know your preference. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 4) <!-- [rfced] Section 3.5: We could not find anything in Section 3.4 >>>>>>>>>>> that indicates that pseudorandomness cannot hold against malicious >>>>>>>>>>> key generation. Please confirm that this section number is correct and >>>>>>>>>>> will be clear to readers. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> As explained in Section 3.4, pseudorandomness cannot hold against >>>>>>>>>>> malicious key generation. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 5) <!-- [rfced] Sections 4.2 and 5.2: Is pi_string sometimes known to >>>>>>>>>>> have been produced by RSAFDHVRF_prove (in which case "only on a >>>>>>>>>>> pi_string value that is known to have been produced by >>>>>>>>>>> RSAFDHVRF_prove" would be correct), or always (in which case "only on >>>>>>>>>>> pi_string, which is known to have been produced by RSAFDHVRF_prove" >>>>>>>>>>> would be correct)? >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> Important note: >>>>>>>>>>> >>>>>>>>>>> RSAFDHVRF_proof_to_hash should be run only on pi_string that is >>>>>>>>>>> known to have been produced by RSAFDHVRF_prove, or from within >>>>>>>>>>> RSAFDHVRF_verify as specified in Section 4.3. >>>>>>>>>>> ... >>>>>>>>>>> Important note: >>>>>>>>>>> >>>>>>>>>>> ECVRF_proof_to_hash should be run only on pi_string that is known >>>>>>>>>>> to have been produced by ECVRF_prove, or from within ECVRF_verify >>>>>>>>>>> as specified in Section 5.3. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 6) <!-- [rfced] Section 5: We don't see any mention of the field F in >>>>>>>>>>> Section 5.5. Please confirm that this listing will be clear to >>>>>>>>>>> readers. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> Fixed options (specified in Section 5.5): >>>>>>>>>>> >>>>>>>>>>> F - finite field --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 7) <!-- [rfced] Section 5.4.1.1: This sentence does not parse. If the >>>>>>>>>>> suggested text is not correct, please clarify >>>>>>>>>>> "interpret_hash_value_as_a_point functions specified"* and >>>>>>>>>>> "roughly half hash_string values". >>>>>>>>>>> >>>>>>>>>>> * We see "interpret_hash_value_as_a_point - a function that attempts" >>>>>>>>>>> earlier in this section.) >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> Note even though the loop is infinite as written, and >>>>>>>>>>> int_to_string(ctr,1) may fail when ctr reaches 256, >>>>>>>>>>> interpret_hash_value_as_a_point functions specified in Section 5.5 >>>>>>>>>>> will succeed on roughly half hash_string values. >>>>>>>>>>> >>>>>>>>>>> Suggested (we could not find evidence of multiple >>>>>>>>>>> interpret_hash_value_as_a_point functions): >>>>>>>>>>> Note that even though the loop is infinite as written and >>>>>>>>>>> int_to_string(ctr,1) may fail when ctr reaches 256, the >>>>>>>>>>> interpret_hash_value_as_a_point function, as specified in >>>>>>>>>>> Section 5.5, will succeed on roughly half of the hash_string >>>>>>>>>>> values. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 8) <!-- [rfced] Section 5.4.2.1: This sentence is confusing as written, >>>>>>>>>>> because the ECVRF_nonce_generation function is not specified in >>>>>>>>>>> [RFC6979]. If the suggested text is not correct, please clarify the >>>>>>>>>>> meaning. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> The ECVRF_nonce_generation function is as specified in [RFC6979] >>>>>>>>>>> Section 3.2 where >>>>>>>>>>> >>>>>>>>>>> Suggested: >>>>>>>>>>> The ECVRF_nonce_generation function is implemented per the process >>>>>>>>>>> specified in Section 3.2 of [RFC6979], where --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 9) <!-- [rfced] Section 5.4.2.1: >>>>>>>>>>> >>>>>>>>>>> a) Please confirm that "output length hlen" is correct (i.e., should >>>>>>>>>>> not be "output length hLen"). We ask because this is the only >>>>>>>>>>> instance of "hlen" in this document. >>>>>>>>>>> >>>>>>>>>>> Is this something that should be clarified, along the lines of the >>>>>>>>>>> "this qlen is not to be confused with qLen" text a few lines later? >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> The hash function H is Hash and its output length hlen (in bits) >>>>>>>>>>> is set as hLen*8 >>>>>>>>>>> >>>>>>>>>>> Possibly: >>>>>>>>>>> * The hash function H is Hash, and its output length hlen (in bits) >>>>>>>>>>> is set as hLen*8 (this hlen is not to be confused with hLen, >>>>>>>>>>> which is used in this document to represent the length of Hash in >>>>>>>>>>> octets). >>>>>>>>>>> >>>>>>>>>>> b) The last bullet item in this list was the only sentence fragment. >>>>>>>>>>> We added a verb ("are"). If this is incorrect, please let us know >>>>>>>>>>> how we can make this list parallel (i.e., either all sentence >>>>>>>>>>> fragments or all complete sentences). >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> All the other values and primitives as defined in [RFC6979] >>>>>>>>>>> >>>>>>>>>>> Currently: >>>>>>>>>>> * All the other values and primitives are as defined in [RFC6979]. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 10) <!-- [rfced] Section 5.4.5: We changed "given to this procedure" to >>>>>>>>>>> "used in this procedure" here. If this is incorrect, please provide >>>>>>>>>>> clarifying text. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> Important note: the public key Y given to this procedure MUST be a >>>>>>>>>>> valid point on E. >>>>>>>>>>> >>>>>>>>>>> Currently: >>>>>>>>>>> Important note: >>>>>>>>>>> >>>>>>>>>>> The public key Y used in this procedure MUST be a valid point on >>>>>>>>>>> E. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 11) <!-- [rfced] Section 5.4.5: Does "in order to" refer to clearing >>>>>>>>>>> the x-coordinate or something else? If the suggested text is not >>>>>>>>>>> correct, please provide clarifying text. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> Thus, bad_pk[0] (of order 4), >>>>>>>>>>> bad_pk[2] (of order 8), and bad_pk[3] (of order 8) each match two bad >>>>>>>>>>> points, depending on the sign of the x-coordinate, which was cleared >>>>>>>>>>> in step 3, in order to make sure that it does not affect the >>>>>>>>>>> comparison. >>>>>>>>>>> >>>>>>>>>>> Suggested: >>>>>>>>>>> Thus, bad_pk[0] (of order 4), >>>>>>>>>>> bad_pk[2] (of order 8), and bad_pk[3] (of order 8) each match two bad >>>>>>>>>>> points, depending on the sign of the x-coordinate, which was cleared >>>>>>>>>>> in Step 3 in order to make sure that it does not affect the >>>>>>>>>>> comparison. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 12) <!-- [rfced] Section 5.4.5: Please confirm that "their y-coordinate" >>>>>>>>>>> should not be "their y-coordinates" here. We ask because of the >>>>>>>>>>> plural "Their y-coordinates" in the third sentence of this paragraph. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> There is no need to >>>>>>>>>>> shift the other bad_pk values by p (or any bad_pk values by a larger >>>>>>>>>>> multiple of p), because their y coordinate would exceed 2^255; and we >>>>>>>>>>> ensure that y_string corresponds to an integer less than 2^255 in >>>>>>>>>>> step 3.) --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 13) <!-- [rfced] Section 5.5: This sentence is confusing as written, >>>>>>>>>>> because the int_to_string function is not specified in [RFC8032]. >>>>>>>>>>> If the suggested text is not correct, please clarify the meaning. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> * The int_to_string function as specified in the first paragraph of >>>>>>>>>>> Section 5.1.2 of [RFC8032]. >>>>>>>>>>> >>>>>>>>>>> Suggested: >>>>>>>>>>> * The int_to_string function is implemented as specified in the >>>>>>>>>>> first paragraph of Section 5.1.2 of [RFC8032]. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 14) <!-- [rfced] Sections 7.1.1 and 7.1.3: We had trouble following >>>>>>>>>>> this sentence. Does "the modulus n or the exponent e are chosen not >>>>>>>>>>> in compliance with [RFC8017]" mean "the modulus n or the exponent e >>>>>>>>>>> is not chosen, in compliance with [RFC8017]" or >>>>>>>>>>> "the modulus n or the exponent e is chosen without complying >>>>>>>>>>> with [RFC8017]" or otherwise? >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> Thus, for RSA-FDH-VRF, uniqueness and >>>>>>>>>>> collision resistance may not hold if the keys are generated >>>>>>>>>>> adversarially (specifically, if the RSA function specified in the >>>>>>>>>>> public key is not bijective because the modulus n or the exponent e >>>>>>>>>>> are chosen not in compliance with [RFC8017]); thus, RSA-FDH-VRF >>>>>>>>>>> defined in this document does not have "full uniqueness" and "full >>>>>>>>>>> collision resistance". >>>>>>>>>>> ... >>>>>>>>>>> (Specifically, the >>>>>>>>>>> VRF output may be predictable if the RSA function specified in the >>>>>>>>>>> public key is far from bijective because the modulus n or the >>>>>>>>>>> exponent e are chosen not in compliance with [RFC8017].) --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 15) <!-- [rfced] Section 7.2: We found the phrasing in these sentences >>>>>>>>>>> confusing, as the text appears to indicate that the equations in >>>>>>>>>>> question can be found in the cited documents. >>>>>>>>>>> If the suggested updates would preserve your intended meaning, may we >>>>>>>>>>> rephrase? >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> * For trusted collision resistance: approximately 8*min(k/2, hLen/2) >>>>>>>>>>> (as shown in [PWHVNRG17]). >>>>>>>>>>> >>>>>>>>>>> * For selective pseudorandomness: approximately as strong as the >>>>>>>>>>> security, in bits, of the RSA problem for the key (n, e) (as shown >>>>>>>>>>> in [GNPRVZ15]). >>>>>>>>>>> >>>>>>>>>>> As shown in [PWHVNRG17], the security level of the ECVRF, measured in >>>>>>>>>>> bits, is as follows (in the random oracle model for the functions >>>>>>>>>>> Hash and ECVRF_encode_to_curve): >>>>>>>>>>> >>>>>>>>>>> Suggested: >>>>>>>>>>> For trusted collision resistance (as discussed in [PWHVNRG17]): >>>>>>>>>>> approximately 8*min(k/2, hLen/2). >>>>>>>>>>> >>>>>>>>>>> For selective pseudorandomness (as discussed in [GNPRVZ15]: >>>>>>>>>>> approximately as strong as the security, in bits, of the RSA >>>>>>>>>>> problem for the key (n, e). >>>>>>>>>>> >>>>>>>>>>> As discussed in [PWHVNRG17], the security level of the ECVRF, >>>>>>>>>>> measured in bits, would be as follows (in the random oracle model >>>>>>>>>>> for the functions Hash and ECVRF_encode_to_curve): --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 16) <!-- [rfced] Section 7.3: Please confirm that "loose", and not >>>>>>>>>>> "lossy", is correct here. We ask because we see "lossier security >>>>>>>>>>> reduction" in Appendix B of [PWHVNRG17] but do not see any words >>>>>>>>>>> that have "loose" in them in that document. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> * They may increase security parameters to make up for the loose >>>>>>>>>>> security reduction. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 17) <!-- [rfced] Section 7.5: Does "must run in time independent of" >>>>>>>>>>> mean "must run in a time that is independent of", or does >>>>>>>>>>> "independent" refer to "run" (in which case it should be >>>>>>>>>>> "independently")? >>>>>>>>>>> >>>>>>>>>>> (Please note that this question has also been raised for "run in time >>>>>>>>>>> independent of" as also found in companion document >>>>>>>>>>> draft-irtf-cfrg-hash-to-curve.) >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> ECVRF-P256-SHA256-SSWU and ECVRF-EDWARDS25519-SHA512-ELL2 can be made >>>>>>>>>>> to run in time independent of alpha, following recommendations in >>>>>>>>>>> [I-D.irtf-cfrg-hash-to-curve]. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 18) <!-- [rfced] Section 7.8: We had trouble following several sentences >>>>>>>>>>> in this section. Please review the following. If the suggestions >>>>>>>>>>> below are not correct, please clarify the following: >>>>>>>>>>> >>>>>>>>>>> the four inputs (where are these defined?) >>>>>>>>>>> to equal each other or to any inputs (to be equal to?) >>>>>>>>>>> second octets of the input (plural "octets", singular "input") >>>>>>>>>>> second octets of the inputs (plural "octets", plural "inputs") >>>>>>>>>>> last octet of the input (singular "octet", singular "input") >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> This analysis still holds >>>>>>>>>>> even if the same hash function is used, as long as the four inputs >>>>>>>>>>> given to the hash function for a given SK and alpha are >>>>>>>>>>> overwhelmingly unlikely to equal each other or to any inputs given to >>>>>>>>>>> the hash function for the same SK and different alpha. This is >>>>>>>>>>> indeed the case for the RSA-FDH-VRF defined in this document, because >>>>>>>>>>> the second octets of the input to the hash function used in MGF1 and >>>>>>>>>>> in proof_to_hash are different. >>>>>>>>>>> ... >>>>>>>>>>> * the second octets of the inputs to the hash function used in >>>>>>>>>>> proof_to_hash, challenge_generation, and >>>>>>>>>>> encode_to_curve_try_and_increment are all different. >>>>>>>>>>> ... >>>>>>>>>>> * the last octet of the input to the hash function used in >>>>>>>>>>> proof_to_hash, challenge_generation, and >>>>>>>>>>> encode_to_curve_try_and_increment is always zero, and therefore >>>>>>>>>>> different from the last octet of the input to the hash function >>>>>>>>>>> used in ECVRF_encode_to_curve_h2c_suite, which is set equal to the >>>>>>>>>>> nonzero length of the domain separation tag by >>>>>>>>>>> [I-D.irtf-cfrg-hash-to-curve]. >>>>>>>>>>> >>>>>>>>>>> Suggested: >>>>>>>>>>> This analysis still holds >>>>>>>>>>> even if the same hash function is used, as long as the four inputs >>>>>>>>>>> given to the hash function for a given SK and alpha are >>>>>>>>>>> overwhelmingly unlikely to be equal to each other or to any inputs >>>>>>>>>>> given to the hash function for the same SK and different alpha. >>>>>>>>>>> This is indeed the case for the RSA-FDH-VRF defined in this >>>>>>>>>>> document, because the second octet of the inputs to the hash >>>>>>>>>>> function used in MGF1 and in proof_to_hash are different. >>>>>>>>>>> ... >>>>>>>>>>> * The second octet of the inputs to the hash function used in >>>>>>>>>>> proof_to_hash, challenge_generation, and >>>>>>>>>>> encode_to_curve_try_and_increment are all different. >>>>>>>>>>> >>>>>>>>>>> * The last octet of the inputs to the hash function used in >>>>>>>>>>> proof_to_hash, challenge_generation, and >>>>>>>>>>> encode_to_curve_try_and_increment is always zero and is therefore >>>>>>>>>>> different from the last octet of the inputs to the hash function >>>>>>>>>>> used in ECVRF_encode_to_curve_h2c_suite, which is set equal to the >>>>>>>>>>> nonzero length of the domain separation tag per [RFC9380]. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 19) <!-- [rfced] Section 7.9: This sentence does not parse. If the >>>>>>>>>>> suggested text is not correct, please clarify "if a group of public >>>>>>>>>>> keys to share the same salt" and "group of public keys, which may aid >>>>>>>>>>> in some protocol". >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> For example, if a group of public keys to share the >>>>>>>>>>> same salt, then the hash of the VRF input alpha will be the same for >>>>>>>>>>> the entire group of public keys, which may aid in some protocol that >>>>>>>>>>> uses the VRF. >>>>>>>>>>> >>>>>>>>>>> Suggested: >>>>>>>>>>> For example, if a group of public keys shares the >>>>>>>>>>> same salt, then the hash of the VRF input alpha will be the same for >>>>>>>>>>> the entire group of public keys; this can be helpful for any >>>>>>>>>>> protocol that uses the VRF. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 20) <!-- [rfced] Section 7.10: It appears that one or more words were >>>>>>>>>>> missing in this sentence. We added the words "to the" as shown below. >>>>>>>>>>> If this is incorrect, please provide clarifying text. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> For the ECVRF, the inputs ECVRF_encode_to_curve hash >>>>>>>>>>> function used in producing H are then guaranteed to be different from >>>>>>>>>>> other ciphersuites; since all the other hashing done by the prover >>>>>>>>>>> depends on H, inputs to all the hash functions used by the prover >>>>>>>>>>> will also be different from other ciphersuites as long as >>>>>>>>>>> ECVRF_encode_to_curve is collision resistant. >>>>>>>>>>> >>>>>>>>>>> Currently: >>>>>>>>>>> For the ECVRF, the inputs to the ECVRF_encode_to_curve >>>>>>>>>>> hash function used in producing H are then guaranteed to be different >>>>>>>>>>> from other ciphersuites; since all the other hashing done by the >>>>>>>>>>> prover depends on H, inputs to all the hash functions used by the >>>>>>>>>>> prover will also be different from other ciphersuites as long as >>>>>>>>>>> ECVRF_encode_to_curve is collision resistant. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 21) <!-- [rfced] [DGKR18]: We see that <https://eprint.iacr.org/2017/573> >>>>>>>>>>> lists the title of this reference as "Ouroboros Praos: An >>>>>>>>>>> adaptively-secure, semi-synchronous proof-of-stake protocol", but >>>>>>>>>>> when we click the "PDF" box on the page, the title of the PDF version >>>>>>>>>>> of the paper has one word different ("protocol" vs. "blockchain"): >>>>>>>>>>> "Ouroboros Praos: An adaptively-secure, semi-synchronous proof-of-stake >>>>>>>>>>> blockchain". How should the title be updated in this reference? >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> [DGKR18] David, B., Gazi, P., Kiayias, A., and A. Russell, >>>>>>>>>>> "Ouroboros Praos: An adaptively-secure, semi-synchronous >>>>>>>>>>> proof-of-stake protocol", in Advances in Cryptology - >>>>>>>>>>> EUROCRYPT, 2018, <https://eprint.iacr.org/2017/573>. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 22) <!-- [rfced] [GNPRVZ15]: This listing is the only "eprint.iacr.org" >>>>>>>>>>> listing to provide a direct link to the PDF copy. Should all >>>>>>>>>>> "eprint.iacr.org" URLs in this document be updated to point to >>>>>>>>>>> the PDF copy, or should the ".pdf" be removed from this link? >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> [GNPRVZ15] Goldberg, S., Naor, M., Papadopoulos, D., Reyzin, L., >>>>>>>>>>> Vasant, S., and A. Ziv, "NSEC5: Provably Preventing DNSSEC >>>>>>>>>>> Zone Enumeration", in NDSS, 2015, >>>>>>>>>>> <https://eprint.iacr.org/2014/582.pdf>. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 23) <!-- [rfced] [X25519]: We see that the provided URL resolves to what >>>>>>>>>>> appears to be a personal website. Please confirm that this page is >>>>>>>>>>> stable and will continue to be available to readers. >>>>>>>>>>> >>>>>>>>>>> Original: >>>>>>>>>>> [X25519] Bernstein, D.J., "How do I validate Curve25519 public >>>>>>>>>>> keys?", 2006, <https://cr.yp.to/ecdh.html#validate>. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 24) <!-- [rfced] Please review the "Inclusive Language" portion of the >>>>>>>>>>> online Style Guide at >>>>>>>>>>> <https://www.rfc-editor.org/styleguide/part2/#inclusive_language>, >>>>>>>>>>> and let us know if any changes are needed. >>>>>>>>>>> >>>>>>>>>>> Note that our script did not flag any words in particular, but this >>>>>>>>>>> should still be reviewed as a best practice. --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 25) <!-- [rfced] Please let us know if any changes are needed for the >>>>>>>>>>> following: >>>>>>>>>>> >>>>>>>>>>> a) The following terms appear to be used inconsistently in this >>>>>>>>>>> document. Please let us know which form is preferred. >>>>>>>>>>> >>>>>>>>>>> INVALID / "INVALID" >>>>>>>>>>> (e.g., 'may output INVALID', 'output "INVALID" and stop') >>>>>>>>>>> >>>>>>>>>>> VALID / "VALID" >>>>>>>>>>> (e.g., '(VALID, beta1)', '("VALID", beta_string)') >>>>>>>>>>> >>>>>>>>>>> b) As ptLen is defined as "length, in octets, of a point on E", it >>>>>>>>>>> appears that ptLen would be pronounced as either "pee-tee-len" or >>>>>>>>>>> "point-len". We changed the two instances of "an ptLen" to "a ptLen" >>>>>>>>>>> accordingly. Please let us know any concerns. >>>>>>>>>>> >>>>>>>>>>> c) Should spacing be made consistent for the following? >>>>>>>>>>> >>>>>>>>>>> ctr = 1 >>>>>>>>>>> ctr=1 >>>>>>>>>>> (ctr, 1) >>>>>>>>>>> (ctr,1) >>>>>>>>>>> >>>>>>>>>>> Please note that in the context of "ctr" the use of spaces between >>>>>>>>>>> entries appears to be more common; we suggest adding spaces >>>>>>>>>>> for these items (e.g., ctr = 1, (ctr, 1)). >>>>>>>>>>> >>>>>>>>>>> 2^(8qLen)>q >>>>>>>>>>> 2^qlen > q >>>>>>>>>>> >>>>>>>>>>> d) Last paragraph of Section 5.4.5: For consistency, should numerals >>>>>>>>>>> or spelled-out numbers be used for the following? >>>>>>>>>>> >>>>>>>>>>> 8 bad points >>>>>>>>>>> two bad points >>>>>>>>>>> >>>>>>>>>>> (If the spelled-out "eight" is preferred, we will also change >>>>>>>>>>> "5 list elements" to "five list elements".) --> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thank you. >>>>>>>>>>> >>>>>>>>>>> RFC Editor/lb/ar >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Apr 17, 2023, rfc-editor@rfc-editor.org wrote: >>>>>>>>>>> >>>>>>>>>>>> *****IMPORTANT***** >>>>>>>>>>>> >>>>>>>>>>>> Updated 2023/04/17 >>>>>>>>>>>> >>>>>>>>>>>> RFC Author(s): >>>>>>>>>>>> -------------- >>>>>>>>>>>> >>>>>>>>>>>> Instructions for Completing AUTH48 >>>>>>>>>>>> >>>>>>>>>>>> Your document has now entered AUTH48. Once it has been reviewed and >>>>>>>>>>>> approved by you and all coauthors, it will be published as an RFC. >>>>>>>>>>>> If an author is no longer available, there are several remedies >>>>>>>>>>>> available as listed in the FAQ (https://www.rfc-editor.org/faq/). >>>>>>>>>>>> >>>>>>>>>>>> You and you coauthors are responsible for engaging other parties >>>>>>>>>>>> (e.g., Contributors or Working Group) as necessary before providing >>>>>>>>>>>> your approval. >>>>>>>>>>>> >>>>>>>>>>>> Planning your review >>>>>>>>>>>> --------------------- >>>>>>>>>>>> >>>>>>>>>>>> Please review the following aspects of your document: >>>>>>>>>>>> >>>>>>>>>>>> * RFC Editor questions >>>>>>>>>>>> >>>>>>>>>>>> Please review and resolve any questions raised by the RFC Editor >>>>>>>>>>>> that have been included in the XML file as comments marked as >>>>>>>>>>>> follows: >>>>>>>>>>>> >>>>>>>>>>>> <!-- [rfced] ... --> >>>>>>>>>>>> >>>>>>>>>>>> These questions will also be sent in a subsequent email. >>>>>>>>>>>> >>>>>>>>>>>> * Changes submitted by coauthors >>>>>>>>>>>> >>>>>>>>>>>> Please ensure that you review any changes submitted by your >>>>>>>>>>>> coauthors. We assume that if you do not speak up that you >>>>>>>>>>>> agree to changes submitted by your coauthors. >>>>>>>>>>>> >>>>>>>>>>>> * Content >>>>>>>>>>>> >>>>>>>>>>>> Please review the full content of the document, as this cannot >>>>>>>>>>>> change once the RFC is published. Please pay particular attention to: >>>>>>>>>>>> - IANA considerations updates (if applicable) >>>>>>>>>>>> - contact information >>>>>>>>>>>> - references >>>>>>>>>>>> >>>>>>>>>>>> * Copyright notices and legends >>>>>>>>>>>> >>>>>>>>>>>> Please review the copyright notice and legends as defined in >>>>>>>>>>>> RFC 5378 and the Trust Legal Provisions >>>>>>>>>>>> (TLP – https://trustee.ietf.org/license-info/). >>>>>>>>>>>> >>>>>>>>>>>> * Semantic markup >>>>>>>>>>>> >>>>>>>>>>>> Please review the markup in the XML file to ensure that elements of >>>>>>>>>>>> content are correctly tagged. For example, ensure that <sourcecode> >>>>>>>>>>>> and <artwork> are set correctly. See details at >>>>>>>>>>>> <https://authors.ietf.org/rfcxml-vocabulary>. >>>>>>>>>>>> >>>>>>>>>>>> * Formatted output >>>>>>>>>>>> >>>>>>>>>>>> Please review the PDF, HTML, and TXT files to ensure that the >>>>>>>>>>>> formatted output, as generated from the markup in the XML file, is >>>>>>>>>>>> reasonable. Please note that the TXT will have formatting >>>>>>>>>>>> limitations compared to the PDF and HTML. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Submitting changes >>>>>>>>>>>> ------------------ >>>>>>>>>>>> >>>>>>>>>>>> To submit changes, please reply to this email using ‘REPLY ALL’ as all >>>>>>>>>>>> the parties CCed on this message need to see your changes. The parties >>>>>>>>>>>> include: >>>>>>>>>>>> >>>>>>>>>>>> * your coauthors >>>>>>>>>>>> >>>>>>>>>>>> * rfc-editor@rfc-editor.org (the RPC team) >>>>>>>>>>>> >>>>>>>>>>>> * other document participants, depending on the stream (e.g., >>>>>>>>>>>> IETF Stream participants are your working group chairs, the >>>>>>>>>>>> responsible ADs, and the document shepherd). >>>>>>>>>>>> >>>>>>>>>>>> * auth48archive@rfc-editor.org, which is a new archival mailing list >>>>>>>>>>>> to preserve AUTH48 conversations; it is not an active discussion >>>>>>>>>>>> list: >>>>>>>>>>>> >>>>>>>>>>>> * More info: >>>>>>>>>>>> https://mailarchive.ietf.org/arch/msg/ietf-announce/yb6lpIGh-4Q9l2USxIAe6P8O4Zc >>>>>>>>>>>> >>>>>>>>>>>> * The archive itself: >>>>>>>>>>>> https://mailarchive.ietf.org/arch/browse/auth48archive/ >>>>>>>>>>>> >>>>>>>>>>>> * Note: If only absolutely necessary, you may temporarily opt out >>>>>>>>>>>> of the archiving of messages (e.g., to discuss a sensitive matter). >>>>>>>>>>>> If needed, please add a note at the top of the message that you >>>>>>>>>>>> have dropped the address. When the discussion is concluded, >>>>>>>>>>>> auth48archive@rfc-editor.org will be re-added to the CC list and >>>>>>>>>>>> its addition will be noted at the top of the message. >>>>>>>>>>>> >>>>>>>>>>>> You may submit your changes in one of two ways: >>>>>>>>>>>> >>>>>>>>>>>> An update to the provided XML file >>>>>>>>>>>> — OR — >>>>>>>>>>>> An explicit list of changes in this format >>>>>>>>>>>> >>>>>>>>>>>> Section # (or indicate Global) >>>>>>>>>>>> >>>>>>>>>>>> OLD: >>>>>>>>>>>> old text >>>>>>>>>>>> >>>>>>>>>>>> NEW: >>>>>>>>>>>> new text >>>>>>>>>>>> >>>>>>>>>>>> You do not need to reply with both an updated XML file and an explicit >>>>>>>>>>>> list of changes, as either form is sufficient. >>>>>>>>>>>> >>>>>>>>>>>> We will ask a stream manager to review and approve any changes that seem >>>>>>>>>>>> beyond editorial in nature, e.g., addition of new text, deletion of text, >>>>>>>>>>>> and technical changes. Information about stream managers can be found in >>>>>>>>>>>> the FAQ. Editorial changes do not require approval from a stream manager. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Approving for publication >>>>>>>>>>>> -------------------------- >>>>>>>>>>>> >>>>>>>>>>>> To approve your RFC for publication, please reply to this email stating >>>>>>>>>>>> that you approve this RFC for publication. Please use ‘REPLY ALL’, >>>>>>>>>>>> as all the parties CCed on this message need to see your approval. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Files >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> The files are available here: >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.xml >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.html >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.pdf >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381.txt >>>>>>>>>>>> >>>>>>>>>>>> Diff file of the text: >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-diff.html >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-rfcdiff.html (side by side) >>>>>>>>>>>> >>>>>>>>>>>> This diff file compares an altered original and the RFC (in order >>>>>>>>>>>> to make the changes in the moved "Contributors" viewable): >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-alt-diff.html >>>>>>>>>>>> >>>>>>>>>>>> Diff of the XML: >>>>>>>>>>>> https://www.rfc-editor.org/authors/rfc9381-xmldiff1.html >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Tracking progress >>>>>>>>>>>> ----------------- >>>>>>>>>>>> >>>>>>>>>>>> The details of the AUTH48 status of your document are here: >>>>>>>>>>>> https://www.rfc-editor.org/auth48/rfc9381 >>>>>>>>>>>> >>>>>>>>>>>> Please let us know if you have any questions. >>>>>>>>>>>> >>>>>>>>>>>> Thank you for your cooperation, >>>>>>>>>>>> >>>>>>>>>>>> RFC Editor/lb/ar >>>>>>>>>>>> >>>>>>>>>>>> -------------------------------------- >>>>>>>>>>>> RFC9381 (draft-irtf-cfrg-vrf-15) >>>>>>>>>>>> >>>>>>>>>>>> Title : Verifiable Random Functions (VRFs) >>>>>>>>>>>> Author(s) : S. Goldberg, L. Reyzin, D. Papadopoulos, J. Včelák >>>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> <rfc9381.xml> >>>>>>>> >>>>>>>> <rfc9381.xml> >>>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> --- >>>>> Sharon Goldberg >>>>> Computer Science, Boston University >>>>> http://www.cs.bu.edu/~goldbe >>>> >>>> >>>> >>>> >> -- >> --- >> Sharon Goldberg >> Computer Science, Boston University >> http://www.cs.bu.edu/~goldbe > >
- [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-cfrg-… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… rfc-editor
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Jan Včelák
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Leonid Reyzin
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Leonid Reyzin
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Leonid Reyzin
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Leonid Reyzin
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Sharon Goldberg
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Jan Včelák
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Christopher Wood
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Lynne Bartholomew
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Sharon Goldberg
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Leonid Reyzin
- Re: [auth48] AUTH48: RFC-to-be 9381 <draft-irtf-c… Tim Taubert
- [auth48] AUTH48 for RFCs-to-be 9381 and 9383 (was… Lynne Bartholomew
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Christopher Wood
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Lynne Bartholomew
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Tim Taubert
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Lynne Bartholomew
- [auth48] [ISE] Re: AUTH48 for RFCs-to-be 9381 and… Lynne Bartholomew
- Re: [auth48] [ISE] Re: AUTH48 for RFCs-to-be 9381… Independent Submissions Editor (Eliot Lear)
- Re: [auth48] [ISE] AUTH48 for RFCs-to-be 9381 and… Lynne Bartholomew
- Re: [auth48] [ISE] AUTH48 for RFCs-to-be 9381 and… Sharon Goldberg
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Lynne Bartholomew
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Jan Včelák
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Lynne Bartholomew
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Leonid Reyzin
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Lynne Bartholomew
- Re: [auth48] AUTH48 for RFCs-to-be 9381 and 9383 … Sandy Ginoza