Re: [auth48] [ISE] AUTH48 for RFCs-to-be 9381 and 9383 (was "Re: AUTH48: RFC-to-be 9381 <draft-irtf-cfrg-vrf-15> for your review")
Lynne Bartholomew <lbartholomew@amsl.com> Fri, 18 August 2023 21:12 UTC
Return-Path: <lbartholomew@amsl.com>
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 C7B73C1516F3; Fri, 18 Aug 2023 14:12:46 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.907
X-Spam-Level:
X-Spam-Status: No, score=-6.907 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable autolearn_force=no
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 MPkeynmeIowP; Fri, 18 Aug 2023 14:12:40 -0700 (PDT)
Received: from c8a.amsl.com (c8a.amsl.com [4.31.198.40]) (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 96FBFC15106D; Fri, 18 Aug 2023 14:12:40 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by c8a.amsl.com (Postfix) with ESMTP id 62B84424FFE7; Fri, 18 Aug 2023 14:12:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
Received: from c8a.amsl.com ([127.0.0.1]) by localhost (c8a.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6ZwX3dKvMMCn; Fri, 18 Aug 2023 14:12:40 -0700 (PDT)
Received: from smtpclient.apple (unknown [IPv6:2601:646:9881:f500:88:9cc0:e246:5bd]) by c8a.amsl.com (Postfix) with ESMTPSA id 13003424CD3F; Fri, 18 Aug 2023 14:12:40 -0700 (PDT)
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.200.110.1.12\))
From: Lynne Bartholomew <lbartholomew@amsl.com>
In-Reply-To: <0afcef46-aeb7-5ee6-5032-03bdf01407bc@rfc-editor.org>
Date: Fri, 18 Aug 2023 14:12:29 -0700
Cc: Tim Taubert <ttaubert@apple.com>, Christopher Wood <caw@heapingbits.net>, Sharon Goldberg <sharon.goldbe@gmail.com>, Leonid Reyzin <leonid.reyzin@gmail.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" <rfc-editor@rfc-editor.org>, auth48archive@rfc-editor.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <6083E41E-C358-40E2-81C8-2B8F9C67F568@amsl.com>
References: <17CC3C9F-2D26-49D1-8193-2FDA990D80DA@amsl.com> <89243B0E-1EAB-4F9F-92A8-51D343DA6D1E@apple.com> <61F74407-2147-490F-83B9-8B5B0C446325@amsl.com> <2195AACE-9DF7-41C7-B06B-8194E21324CA@amsl.com> <0afcef46-aeb7-5ee6-5032-03bdf01407bc@rfc-editor.org>
To: "Independent Submissions Editor (Eliot Lear)" <rfc-ise@rfc-editor.org>
X-Mailer: Apple Mail (2.3731.200.110.1.12)
Archived-At: <https://mailarchive.ietf.org/arch/msg/auth48archive/SwaBD0ELEMCAc-fSaDVp8Bayhh0>
Subject: Re: [auth48] [ISE] 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: Fri, 18 Aug 2023 21:12:46 -0000
Hi, Eliot. So noted: https://www.rfc-editor.org/auth48/rfc9383 Thank you! RFC Editor/lb > On Aug 18, 2023, at 2:00 PM, Independent Submissions Editor (Eliot Lear) <rfc-ise@rfc-editor.org> wrote: > > Approved. > > On 18.08.23 22:49, Lynne Bartholomew wrote: >> Hi, Eliot. >> >> A quick check-in with you. Do you have any further comments, or would you like to confirm your approval of RFC-to-be 9383? >> >> Thank you! >> >> RFC Editor/lb >> >>> On Aug 18, 2023, at 1:45 PM, Lynne Bartholomew <lbartholomew@amsl.com> wrote: >>> >>> Hi, Tim. We have noted your approval: >>> >>> https://www.rfc-editor.org/auth48/rfc9383 >>> >>> Thank you! >>> >>> RFC Editor/lb >>> >>>> On Aug 17, 2023, at 5:44 PM, Tim Taubert <ttaubert@apple.com> wrote: >>>> >>>> Thank you Lynne! I also approve publication of RFC 9383. >>>> >>>> — Tim >>>> >>>> >>>>> On Aug 17, 2023, at 00:04, Lynne Bartholomew <lbartholomew@amsl.com> wrote: >>>>> >>>>> Hi, Chris. So noted: >>>>> >>>>> https://www.rfc-editor.org/auth48/rfc9383 >>>>> >>>>> Thank you! >>>>> >>>>> RFC Editor/lb >>>>> >>>>>> On Aug 16, 2023, at 2:39 PM, Christopher Wood <caw@heapingbits.net> wrote: >>>>>> >>>>>> 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