From nobody Mon Jun 1 02:53:48 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 983A73A0ECC for ; Mon, 1 Jun 2020 02:53:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 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, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q9u82z18vzqc for ; Mon, 1 Jun 2020 02:53:44 -0700 (PDT) Received: from mail-ot1-x329.google.com (mail-ot1-x329.google.com [IPv6:2607:f8b0:4864:20::329]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1032B3A0EC9 for ; Mon, 1 Jun 2020 02:53:44 -0700 (PDT) Received: by mail-ot1-x329.google.com with SMTP id o13so7497118otl.5 for ; Mon, 01 Jun 2020 02:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=e6pmjzbb7I3i8c3PE5ZakJYTs6P6FBDaw5kJq3+7KhE=; b=Y/ZuSNw9yZDnOg1nED6VQS6W0bqF0JBoW9plEXYFi/ixmO7jmFeKTDDjEzfO9/sKky MpXny2ziCjj8p8asKdEYhR1E/Yrao4Yh37jaRnzumsw66KkqdQ4j7+J8h+WnVfNm0ZNV u8+zAJcVP+8ibUvu0/S4Xz+ZddJFFP1giKEAJxUs9fFK3g9PRgn1U96bVgzTV16LgmGZ +Fzp50QAZcBTV2GTyW5GDb4msPnIgJK44A/MgJoGSEymNAAn5DZ0tpl88LxBs3t1OfKO T0ld4YzXuKvp04tJoM6gC24jEQQPWa22aHHGw7w0KchhcwEA1ZsMMN2Qs5uM0k2QYXAk tzOA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=e6pmjzbb7I3i8c3PE5ZakJYTs6P6FBDaw5kJq3+7KhE=; b=FoAxy1pQhU1efTprCT0/GboGtblh/NzmSx5ON5NbZu/1UFLWqBl+N8Ov1hDa4SpyNC hqGnDh/J1bitJQGHkqiVbd606zdVae/cZcTFV5HXU00ZNcEawyD5PMUWPh0L1ZnG58cG XhUIZeEGz2XmrIWlKIUPABLAV4kAeWixjuge9FN6gA/xENnOnbMb5bkYr9tZN3S76fbd HGMEPq9veAjYXX1nVCbbz/k+KGP3QR2jj3FXuQgwNG0E9pa7tdyw2Ftdr35T1IZ9uVNY WfvR95B/aKANefb37o4VOLY9nvGhT4Y/Oqi9CKlWMN7PjlLJ1yGLvVc4XRWDkuyiHauM xFjA== X-Gm-Message-State: AOAM531xLz7SxW0PV521A2rcMbvSHiiSf2JUpLphC3/58gBEyoUHQfsz /5SV/F0bPbDRSjmYE30qTiQ3QIJ51t9yXPOVO6E= X-Google-Smtp-Source: ABdhPJwRSlDFsXp/OLQABG386N2d2oDmsN4lwRH/8zMfztDsFQBqMevMvAXH/E8N6aySUVLKtzmJk/UAA0NHvPP9jWI= X-Received: by 2002:a9d:6d0f:: with SMTP id o15mr15542304otp.200.1591005223122; Mon, 01 Jun 2020 02:53:43 -0700 (PDT) MIME-Version: 1.0 References: <002201d61c30$4f561da0$ee0258e0$@hco.ntt.co.jp_1> In-Reply-To: From: Chloe Martindale Date: Mon, 1 Jun 2020 10:53:31 +0100 Message-ID: To: Yumi Sakemi Cc: crypto-panel@irtf.org, "Stanislav V. Smyshlyaev" , cfrg-chairs@ietf.org, Tetsutaro Kobayashi , SAITO Tsunekazu Content-Type: multipart/alternative; boundary="00000000000028fcb005a702c5e7" Archived-At: Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-pairing-friendly-curves-03 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Jun 2020 09:53:47 -0000 --00000000000028fcb005a702c5e7 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Yumi, dear all, thank you for the update and for involving me in your thought process regarding the curve choices. I understand and agree with your reasoning (and approach) regarding including both BLS12-381 and BN462, however I think I would make a different 'safer choice'. My reason is this: if the attack is improved further (which you are completely right, it may), it is very likely to have a bigger impact on curves constructed via polynomial methods with embedding degree 8 (such as BN462) than on any other curves for this security level, so it's not unlikely that the security of BN462 would be pushed below 128 bits. A safer choice in my view would be to take the Cocks-Pinch curve (not constructed using polynomial methods) defined using a 544-bit prime implemented in RELIC, from [GMT19]*. The TNFS attacks cannot be applied to Cocks-Pinch curves (at least not without a fundamental new attack idea, since they rely on the polynomial construction), so small improvements will not decrease the security level at all, and this curve is actually still more efficient than BN462 so there's nothing to lose there. I appreciate that such a choice would mean also including some background on Cocks-Pinch and a reference/short explanation of the fact that TNFS attacks don't apply to these, which would be a major change to the original document, so I appreciate it if you'd rather not do this, but just thought I'd suggest it as I think it would increase the lifetime of your document. *In your draft this is [GME19], but it should be [GMT19], and can now be updated to the peer-reviewed version of course (this is the paper I pointed out in my review). All the best, Chloe On Fri, 29 May 2020 at 16:21, Yumi Sakemi wrote= : > Dear Chloe > > We appreciate a lot of constructive comments received at Expert Review. > > We are currently working on updating our draft. > Last week, Nick created a repository for pairing-friendly curves on > CFRG's official GitHub, so we plan to update our draft using the issue > tracker. > The updating for your comments will be made available to you on the > following issue page. > > https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/issues > > We will contact you again when all the comments have been updated. > In that case, we would be glad if you could check them. > > In addition, before updating, there is a comment that we would like to > inform you about the policy of update. > The comment is about the recommended curve for 128-bit security level. > > First of all, thank you for teaching us a peer-reviewed paper for > BLS12-381. > The comment is about the recommended curve for 128-bit security level. > Due to our lack of investigation, we made the wrong decision that > BLS12-381 was not matched in our selection policy. > > Your comment pointed out that BLS12-381 is moved to the recommended > curve and BN462 is moved to the Appendix. > We understood the disadvantages of BN462 that you were concerned > about, but we would like to recommend both BLS12-381 and BN462. > The reason is as follows. > > CFRG aims to standardize cryptographic technology for future Internet use= . > We agree that BLS12-381 with a 126-bit security level is the best > match as a curve of 128-bit security level "at this time" from the > viewpoint of security and efficiency. > On the other hand, the security of BLS12-381 is already less than > 128bit, so from the viewpoint of future use, if the attack is improved > even a little, it will not be suitable for a curve of 128-bit security > level. > Considering that the curve of 128-bit security level is often used at > current. > So, we would like to recommend both BLS12-381 and BN462 considering > the future use and the safety side. > > However, as you pointed out, BN462 has the disadvantage of being too > slow compared to BLS12-381. > Then, the reader will be confused if there are two parameters of > 128-bit security level, so we will add the basis for selection by > adding the explanation of merits and demerits for each parameter. > And, we will also add a description about the disadvantages of BN462 > regarding efficiency. > > If you have any problems with the updating policy, we would like you to > comment. > > Best regards, > Yumi > > > > > > > 2020=E5=B9=B44=E6=9C=8827=E6=97=A5(=E6=9C=88) 21:58 Yumi Sakemi : > > > > Dear Chloe > > > > I appreciate your review. > > I'm very glad to receive many constructive comments! > > I will discuss about your comments with co-authors and revise our > > draft to reflect your comments in our draft. > > I think it will be a better draft by reflecting your comments. > > > > As co-author Tsunekazu e-mailed, we're planning to submit version 04, > > because we were independently working on updating of abstract, > > introduction (sec. 1.3) and proofreading of English in parallel with > > the expert review. > > (Version 04 will not be reflected your comments.) > > > > Comments from Chloe will be reflected in the version 05. > > We will submit version 05 in mid-May and we will report you when we > > submit version 05. > > > > Dear Stanislav > > > > Thank you very much for proceeding to the Expert review. > > We received a lot of constructive comments from Chloe, so I think it > > is difficult to manage comments by email. > > (Because there are over 100 comments from Chloe.) > > > > Therefore, I would like to use the issue management function of GitHub > > so that it is easy to check the reflecting status of Chloe's comments. > > So, I'd like to use the repository of pairing-friendly curves draft on > > CFRG's GitHub > > because BLS signature which is similar in terms of IRTF stream is also > > registered on the GitHub. > > Could you register the repository for the draft of pairing-friendly > > curves on the following CFRG's GitHub? > > > > https://github.com/cfrg > > > > Best regards, > > Yumi > > > > 2020=E5=B9=B44=E6=9C=8827=E6=97=A5(=E6=9C=88) 10:09 SAITO Tsunekazu : > > > > > > Dear Chloe, Stanislav, > > > > > > > > > > > > This is Tsunekazu. > > > > > > > > > > > > We plan to update the draft to version 04 soon. > > > > > > As the contents of the update, we changed the wording of Section 1.3 > and security consideration. > > > > > > Yumi will submit the 4th edition, so please wait a moment. > > > > > > > > > > > > Best regards, > > > > > > Tsunekazu > > > > > > > > > > > > From: Stanislav V. Smyshlyaev > > > Sent: Sunday, April 26, 2020 2:30 PM > > > To: Chloe Martindale ; SAITO Tsunekazu < > tsunekazu.saito.hg@hco.ntt.co.jp>; Tetsutaro Kobayashi < > tetsutaro.kobayashi.dr@hco.ntt.co.jp>; Yumi Sakemi < > yumi.sakemi@lepidum.co.jp> > > > Cc: cfrg-chairs@ietf.org; crypto-panel@irtf.org > > > Subject: Re: [Crypto-panel] Request for review: > draft-irtf-cfrg-pairing-friendly-curves-03 > > > > > > > > > > > > Dear Chloe, > > > > > > Many thanks for your review (such a great and a prompt one!). > > > > > > > > > > > > Dear Yumi, Saito, Tetsutaro, do you plan to update your draft taking > into account Chloe=E2=80=99s review? > > > > > > > > > > > > Best regards, > > > > > > Stanislav > > > > > > > > > > > > =D0=BF=D1=82, 24 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 19:49, Chloe= Martindale < > chloemartindale@gmail.com>: > > > > > > Hi all, > > > > > > > > > > > > review is attached. > > > > > > > > > > > > All the best, > > > > > > Chloe > > > > > > > > > > > > On Tue, 21 Apr 2020 at 18:05, Stanislav V. Smyshlyaev < > smyshsv@gmail.com> wrote: > > > > > > Sure - it is > > > > > > https://tools.ietf.org/html/draft-irtf-cfrg-pairing-friendly-curves-0= 3 > > > > > > > > > > > > Thank you again! > > > > > > > > > > > > Regards, > > > > > > Stanislav > > > > > > > > > > > > =D0=B2=D1=82, 21 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 19:10, Chloe= Martindale < > chloemartindale@gmail.com>: > > > > > > Just to be sure, can you point me towards the most recent version of > the draft please? > > > > > > > > > > > > Thanks, > > > > > > Chloe > > > > > > > > > > > > On Tue, 21 Apr 2020 at 13:17, Stanislav V. Smyshlyaev < > smyshsv@gmail.com> wrote: > > > > > > Great, many thanks, Chloe! > > > > > > > > > > > > Kind regards, > > > > > > Nick, Alexey, Stanislav > > > > > > > > > > > > On Tue, 21 Apr 2020 at 15:16, Chloe Martindale < > chloemartindale@gmail.com> wrote: > > > > > > I'll take a look this week. > > > > > > > > > > > > All the best, > > > > > > Chloe > > > > > > > > > > > > On Tue, 21 Apr 2020, 13:10 Stanislav V. Smyshlyaev, > wrote: > > > > > > Dear Crypto Panel members, > > > > > > > > > > > > The authors of the Pairing-Friendly Curves draft have addressed the > concerns raised during the discussion and are ready to move to the next > stage with the draft. > > > > > > > > > > > > Alexey, Nick and I would like to ask Crypto Review Panel members abou= t > the review(s) of draft-irtf-cfrg-pairing-friendly-curves-03. > > > > > > > > > > > > This memo introduces pairing-friendly curves used for constructing > pairing-based cryptography. It describes recommended parameters for each > security level and recent implementations of pairing-friendly curves. > > > > > > > > > > > > > > > > > > Can we have any volunteers, please?.. > > > > > > > > > > > > > > > > > > Best regards, > > > > > > Stanislav (on behalf of chairs) > > > > > > _______________________________________________ > > > Crypto-panel mailing list > > > Crypto-panel@irtf.org > > > https://www.irtf.org/mailman/listinfo/crypto-panel > > > > > > > > -- > > Yumi Sakemi, Ph. D. > > Lepidum Co. Ltd. > > E-Mail: yumi.sakemi@lepidum.co.jp > > > > -- > Yumi Sakemi, Ph. D. > Lepidum Co. Ltd. > > Tel: +81-3 6276 5103 > E-Mail: yumi.sakemi@lepidum.co.jp > --00000000000028fcb005a702c5e7 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Yumi, dear all,

thank y= ou for the update and for involving me in your thought process regarding th= e curve choices. I understand and agree with your reasoning (and approach) = regarding including both BLS12-381 and BN462, however I think I would make = a different 'safer choice'.

My reason= is this: if the attack is improved further (which you are completely right= , it may), it is very likely to have a bigger impact on curves constructed = via polynomial methods with embedding degree 8 (such as BN462) than on any = other curves for this security level, so it's not unlikely that the sec= urity of BN462 would be pushed below 128 bits. A safer choice in my view wo= uld be to take the Cocks-Pinch curve (not constructed using polynomial meth= ods) defined using a 544-bit prime implemented in RELIC, from [GMT19]*. The= TNFS attacks cannot be applied to Cocks-Pinch curves (at least not without= a fundamental new attack idea, since they rely on the polynomial construct= ion), so small improvements will not decrease the security level at all, an= d this curve is actually still more efficient than BN462 so there's not= hing to lose there. I appreciate that such a choice would mean also includi= ng some background on Cocks-Pinch and a reference/short explanation of the = fact that TNFS attacks don't apply to these, which would be a major cha= nge to the original document, so I appreciate it if you'd rather not do= this, but just thought I'd suggest it as I think it would increase the= lifetime of your document.

*In your draft this is= [GME19], but it should be [GMT19], and can now be updated to the peer-revi= ewed version of course (this is the paper I pointed out in my review).

All the best,
Chloe

On Fri, 29 May = 2020 at 16:21, Yumi Sakemi <yumi.sakemi@lepidum.co.jp> wrote:
Dear Chloe

We appreciate a lot of constructive comments received at Expert Review.

We are currently working on updating our draft.
Last week, Nick created a repository for pairing-friendly curves on
CFRG's official GitHub, so we plan to update our draft using the issue<= br> tracker.
The updating for your comments will be made available to you on the
following issue page.

https://github.com/cfrg/draft-= irtf-cfrg-pairing-friendly-curves/issues

We will contact you again when all the comments have been updated.
In that case, we would be glad if you could check them.

In addition, before updating, there is a comment that we would like to
inform you about the policy of update.
The comment is about the recommended curve for 128-bit security level.

First of all, thank you for teaching us a peer-reviewed paper for BLS12-381= .
The comment is about the recommended curve for 128-bit security level.
Due to our lack of investigation, we made the wrong decision that
BLS12-381 was not matched in our selection policy.

Your comment pointed out that BLS12-381 is moved to the recommended
curve and BN462 is moved to the Appendix.
We understood the disadvantages of BN462 that you were concerned
about, but we would like to recommend both BLS12-381 and BN462.
The reason is as follows.

CFRG aims to standardize cryptographic technology for future Internet use.<= br> We agree that BLS12-381 with a 126-bit security level is the best
match as a curve of 128-bit security level "at this time" from th= e
viewpoint of security and efficiency.
On the other hand, the security of BLS12-381 is already less than
128bit, so from the viewpoint of future use, if the attack is improved
even a little, it will not be suitable for a curve of 128-bit security
level.
Considering that the curve of 128-bit security level is often used at curre= nt.
So, we would like to recommend both BLS12-381 and BN462 considering
the future use and the safety side.

However, as you pointed out, BN462 has the disadvantage of being too
slow compared to BLS12-381.
Then, the reader will be confused if there are two parameters of
128-bit security level, so we will add the basis for selection by
adding the explanation of merits and demerits for each parameter.
And, we will also add a description about the disadvantages of BN462
regarding efficiency.

If you have any problems with the updating policy, we would like you to com= ment.

Best regards,
Yumi






2020=E5=B9=B44=E6=9C=8827=E6=97=A5(=E6=9C=88) 21:58 Yumi Sakemi <yumi.sakemi@lepidum= .co.jp>:
>
> Dear Chloe
>
> I appreciate your review.
> I'm very glad to receive many constructive comments!
> I will discuss about your comments with co-authors and revise our
> draft to reflect your comments in our draft.
> I think it will be a better draft by reflecting your comments.
>
> As co-author Tsunekazu e-mailed, we're=C2=A0 planning to submit ve= rsion 04,
> because we were independently working on updating of abstract,
> introduction (sec. 1.3) and proofreading of English in parallel with > the expert review.
> (Version 04 will not be reflected your comments.)
>
> Comments from Chloe will be reflected in the version 05.
> We will submit version 05 in mid-May and we will report you when we > submit version 05.
>
> Dear Stanislav
>
> Thank you very much for proceeding to the Expert review.
> We received a lot of constructive comments from Chloe, so I think it > is difficult to manage comments by email.
> (Because there are over 100 comments from Chloe.)
>
> Therefore, I would like to use the issue management function of GitHub=
> so that it is easy to check the reflecting status of Chloe's comme= nts.
> So, I'd like to use the repository of pairing-friendly curves draf= t on
> CFRG's GitHub
> because BLS signature which is similar in terms of IRTF stream is also=
> registered on the GitHub.
> Could you register the repository for the draft of pairing-friendly > curves on the following CFRG's GitHub?
>
> https://github.com/cfrg
>
> Best regards,
> Yumi
>
> 2020=E5=B9=B44=E6=9C=8827=E6=97=A5(=E6=9C=88) 10:09 SAITO Tsunekazu &l= t;tsu= nekazu.saito.hg@hco.ntt.co.jp>:
> >
> > Dear Chloe, Stanislav,
> >
> >
> >
> > This is Tsunekazu.
> >
> >
> >
> > We plan to update the draft to version 04 soon.
> >
> > As the contents of the update, we changed the wording of Section = 1.3 and security consideration.
> >
> > Yumi will submit the 4th edition, so please wait a moment.
> >
> >
> >
> > Best regards,
> >
> > Tsunekazu
> >
> >
> >
> > From: Stanislav V. Smyshlyaev <smyshsv@gmail.com>
> > Sent: Sunday, April 26, 2020 2:30 PM
> > To: Chloe Martindale <chloemartindale@gmail.com>; SAITO Tsunekazu &= lt;ts= unekazu.saito.hg@hco.ntt.co.jp>; Tetsutaro Kobayashi <tetsutaro.ko= bayashi.dr@hco.ntt.co.jp>; Yumi Sakemi <yumi.sakemi@lepidum.co.jp>
> > Cc: cfr= g-chairs@ietf.org; crypto-panel@irtf.org
> > Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-p= airing-friendly-curves-03
> >
> >
> >
> > Dear Chloe,
> >
> > Many thanks for your review (such a great and a prompt one!).
> >
> >
> >
> > Dear Yumi, Saito, Tetsutaro, do you plan to update your draft tak= ing into account Chloe=E2=80=99s review?
> >
> >
> >
> > Best regards,
> >
> > Stanislav
> >
> >
> >
> > =D0=BF=D1=82, 24 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 19:49, C= hloe Martindale <chloemartindale@gmail.com>:
> >
> > Hi all,
> >
> >
> >
> > review is attached.
> >
> >
> >
> > All the best,
> >
> > Chloe
> >
> >
> >
> > On Tue, 21 Apr 2020 at 18:05, Stanislav V. Smyshlyaev <smyshsv@gmail.com> w= rote:
> >
> > Sure - it is
> >
> > https://tools.ietf.o= rg/html/draft-irtf-cfrg-pairing-friendly-curves-03
> >
> >
> >
> > Thank you again!
> >
> >
> >
> > Regards,
> >
> > Stanislav
> >
> >
> >
> > =D0=B2=D1=82, 21 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 19:10, C= hloe Martindale <chloemartindale@gmail.com>:
> >
> > Just to be sure, can you point me towards the most recent version= of the draft please?
> >
> >
> >
> > Thanks,
> >
> > Chloe
> >
> >
> >
> > On Tue, 21 Apr 2020 at 13:17, Stanislav V. Smyshlyaev <smyshsv@gmail.com> w= rote:
> >
> > Great, many thanks, Chloe!
> >
> >
> >
> > Kind regards,
> >
> > Nick, Alexey, Stanislav
> >
> >
> >
> > On Tue, 21 Apr 2020 at 15:16, Chloe Martindale <chloemartindale@gmail.com<= /a>> wrote:
> >
> > I'll take a look this week.
> >
> >
> >
> > All the best,
> >
> > Chloe
> >
> >
> >
> > On Tue, 21 Apr 2020, 13:10 Stanislav V. Smyshlyaev, <smyshsv@gmail.com> w= rote:
> >
> > Dear Crypto Panel members,
> >
> >
> >
> > The authors of the Pairing-Friendly Curves draft have addressed t= he concerns raised during the discussion and are ready to move to the next = stage with the draft.
> >
> >
> >
> > Alexey, Nick and I would like to ask Crypto Review Panel members = about the review(s) of draft-irtf-cfrg-pairing-friendly-curves-03.
> >
> >
> >
> > This memo introduces pairing-friendly curves used for constructin= g pairing-based cryptography. It describes recommended parameters for each = security level and recent implementations of pairing-friendly curves.
> >
> >
> >
> >
> >
> > Can we have any volunteers, please?..
> >
> >
> >
> >
> >
> > Best regards,
> >
> > Stanislav (on behalf of chairs)
> >
> > _______________________________________________
> > Crypto-panel mailing list
> > Crypto= -panel@irtf.org
> > https://www.irtf.org/mailman/listinfo/cr= ypto-panel
>
>
>
> --
> Yumi Sakemi, Ph. D.
> Lepidum Co. Ltd.
> E-Mail: yumi.sakemi@lepidum.co.jp



--
Yumi Sakemi, Ph. D.
Lepidum Co. Ltd.

Tel: +81-3 6276 5103
E-Mail: yumi= .sakemi@lepidum.co.jp
--00000000000028fcb005a702c5e7-- From nobody Thu Jun 4 21:17:25 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AECD53A1214 for ; Thu, 4 Jun 2020 21:17:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Nntq-vKYzgtZ for ; Thu, 4 Jun 2020 21:17:22 -0700 (PDT) Received: from mail-lf1-x130.google.com (mail-lf1-x130.google.com [IPv6:2a00:1450:4864:20::130]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 694123A1216 for ; Thu, 4 Jun 2020 21:17:22 -0700 (PDT) Received: by mail-lf1-x130.google.com with SMTP id c12so4946459lfc.10 for ; Thu, 04 Jun 2020 21:17:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to:cc; bh=LqWg5h5+8BnqLPiAfeW2Oi3Lr71m4LIeqLzMCSex5W0=; b=Vvq8QUf24w3S6LW1wLNT0dw7tw4ZVLD8FO0K/PJuXsyHnwnwzmJxeDyTWUVAKjGeFf 1VXAlzMe3LZop5lERWTL2UyMesarhz7ALkDY4x8+hbQvTQKHR6jbtxuUZgbpjAT/lMhK K1Z40u7MXC3dtYDjmI96rFsasDI42rtpdzjSiGiV94ZRan+sXuS7ZEsWXzNbMoKi38EE iRVPu4OEA9Ey1+F3VndA4G9z6q4iUXYNEUKjjO3qGjuYLzI3IxeZ0sojCcRsrmYx0x7n 9zAsiVExqHNINumh8swYFzWFtN7nungNhkgc9kDjt/enOCMWOSIO/k330vryxwBxe5MZ aTqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=LqWg5h5+8BnqLPiAfeW2Oi3Lr71m4LIeqLzMCSex5W0=; b=JLlsuT3yrLCKCSvjV005fILmzmVJ35Bv58mXengV3oY24FsCjfRDDskz2/XQQUzS1N uWteLgGXj8ICzbJZQzelIJ3Dc2loh/lOue7mombkqEbthBrnSlXHkLNNRSgXWI3No5rP 6Lf5xERR8hC93jD3mfdCHW7DhDn1tXw7VTe2TBDXiwzE7rFe3sKip3DWADyU3b1hBGun TB1BB9qZHI7IndNWs2GnvPF0aHP2mWGyBP3PW/UikwSLexoLx8MeVP6sp46+lfS20pme +Pg3CpsRmhj7gz9v8DDnlOI5S1Uw9vrf2kpBzmgbtwxFfgNBE7w8SHtCAfcPwJPiCCT4 IAHQ== X-Gm-Message-State: AOAM530HDzlsFk3kA/Jy6sEKC2RATMWpq8CLdvXkKI617Bx3SbEPdOl7 4uqod4J224dIeElMFYXStwFrXZwf8Q6Jml4GmrOrIOlx5QE= X-Google-Smtp-Source: ABdhPJz+vydRL23/QA9xCnL+x8GDtOivydWJaACWEJ5uTwZwJA4W0fOZ5iOYNCM9dIagrKs0zdEvW4YUxDL5bqxFgxA= X-Received: by 2002:ac2:4562:: with SMTP id k2mr4257994lfm.5.1591330639074; Thu, 04 Jun 2020 21:17:19 -0700 (PDT) MIME-Version: 1.0 From: "Stanislav V. Smyshlyaev" Date: Fri, 5 Jun 2020 07:17:53 +0300 Message-ID: To: crypto-panel@irtf.org Cc: cfrg-chairs@ietf.org, draft-irtf-cfrg-hash-to-curve.authors@ietf.org Content-Type: multipart/alternative; boundary="00000000000076596c05a74e8972" Archived-At: Subject: [Crypto-panel] Request for review: draft-irtf-cfrg-hash-to-curve-08 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 04:17:24 -0000 --00000000000076596c05a74e8972 Content-Type: text/plain; charset="UTF-8" Dear Crypto Panel members, Alexey, Nick and I would like to ask Crypto Review Panel members about the review(s) of draft-irtf-cfrg-hash-to-curve-08. The document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. Can we have any volunteers, please? Best regards, Stanislav (on behalf of chairs) --00000000000076596c05a74e8972 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Crypto Panel members,=C2=A0

Alexey= , Nick and I would like to ask Crypto Review Panel members about the review= (s) of draft-irtf-cfrg-hash-to-curve-08.

The docum= ent specifies a number of algorithms for encoding or hashing an arbitrary s= tring to a point on an elliptic curve.=C2=A0

<= br>
Can we have any volunteers, please?

=
Best regards,
Stanislav (on behalf of chairs)
--00000000000076596c05a74e8972-- From nobody Fri Jun 5 04:53:46 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 85BC13A149E for ; Fri, 5 Jun 2020 04:53:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.096 X-Spam-Level: X-Spam-Status: No, score=-2.096 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nccgroup.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HsBjFDcf4i9i for ; Fri, 5 Jun 2020 04:53:43 -0700 (PDT) Received: from eu-smtp-delivery-170.mimecast.com (eu-smtp-delivery-170.mimecast.com [207.82.80.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7B00D3A14E0 for ; Fri, 5 Jun 2020 04:53:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nccgroup.com; s=mimecastnccgroupcom; t=1591358019; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=0kwwdjxhJ1I1nwB4MNY5lA+J8kNbL3UpBFqXFOZnSDA=; b=hFk677ysrxyDU4vssF5fyP8h2aeV9KgoP+oFW6UkiqlR15rKigPiY2dT5+hpwHtis3V1tg Tmh9YavhX+I3XK3tVjj438EXDR5t7d/fQ5m496AzwMA7crxMa4a5nmltGFkUx9OhkNLsv+ fjEg0JMaPJtwBYk1EkROTTqrGLkxL95YVtQpv85BaQGY+9LJM7vJJxAT+jMkLJivW8C/Xi aQYemkBesQiidfKQxLFUMBOCKb0uEXi5rJjmkytqCfxyoOchdRaXTg7tsw9u0m1l+C/yK3 30kTTxrpUgTCy3FicdD8udiTEfgNA5V5Sx/U9pfQ/HRdxcgmWf+ZPC8uZ5f+qA== Received: from GBR01-CWL-obe.outbound.protection.outlook.com (mail-cwlgbr01lp2058.outbound.protection.outlook.com [104.47.20.58]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mtapsc-8-q6z_Yr2YPRqdX-UAl3HMNw-1; Fri, 05 Jun 2020 12:53:35 +0100 X-MC-Unique: q6z_Yr2YPRqdX-UAl3HMNw-1 Received: from CWXP265MB0983.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:47::19) by CWXP265MB1080.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:3e::17) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Fri, 5 Jun 2020 11:53:33 +0000 Received: from CWXP265MB0983.GBRP265.PROD.OUTLOOK.COM ([fe80::78ba:f951:c830:9141]) by CWXP265MB0983.GBRP265.PROD.OUTLOOK.COM ([fe80::78ba:f951:c830:9141%3]) with mapi id 15.20.3066.019; Fri, 5 Jun 2020 11:53:33 +0000 From: Thomas Pornin To: "Stanislav V. Smyshlyaev" , "crypto-panel@irtf.org" CC: "draft-irtf-cfrg-hash-to-curve.authors@ietf.org" , "cfrg-chairs@ietf.org" Thread-Topic: EXTERNAL: [Crypto-panel] Request for review: draft-irtf-cfrg-hash-to-curve-08 Thread-Index: AQHWOvBDNW+ePftesUesp0rSDCJKy6jJpvAA Date: Fri, 5 Jun 2020 11:53:33 +0000 Message-ID: <27FC2D65-658D-4E21-8484-E95927CCA1BF@nccgroup.com> References: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.200.215.113] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: df191c13-ca64-44c3-49b5-08d8094712a3 x-ms-traffictypediagnostic: CWXP265MB1080: x-microsoft-antispam-prvs: route: R_Mimecast campaign: C_Default signature: S_NoSignature disclaimer: D_NoDisclaimer x-ms-oob-tlc-oobclassifiers: OLM:8273; x-forefront-prvs: 0425A67DEF x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DQ6XjKLgjwVJbbEf/zG42oPyEMm7VuFWWuDDpHclVIPYTL6wPjMKQZ+fpSV503TM7rYG2WYmnb9ya7aIy5DiPIX1GYaSuk01x99F7wEioChwmMatRJSYEWi0DUA4/6bv20F4DK7DAveUZSaGpTo5Z2lYPHeT1xM/j7B5iRqamHctdLDv2or4xtWo82rZsdSw0sIYzVbdLMEjQeSHb/+VzS+NJs/z2I956aBQ35PNg3tcQQBxm6RyZYvHioRwTsPfyZN0Vdocj7SQNbdseC3RkQ1/jjowufdaDKANn4lk3PY+HbUeH0cGxi/OvA8j7eVE x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CWXP265MB0983.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39850400004)(346002)(366004)(376002)(316002)(53546011)(110136005)(71200400001)(2616005)(186003)(83380400001)(6512007)(44832011)(54906003)(6506007)(26005)(2906002)(4744005)(66946007)(76116006)(8936002)(66476007)(36756003)(33656002)(91956017)(478600001)(6486002)(86362001)(66556008)(5660300002)(66446008)(64756008)(8676002)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: /pcsuXbOkr/SV56rzZCUv6ePnnv3ky9Sj1+29UE+p9ftm4+LXzjvFNmLVjLYkYXzPgPM9FYn0WJulFe3/npt8gCbXd0cDgr7LNpRvueUE6ShLgpAt17/LCbwwHW4fjYvv+SpXrFVAeAqPnFCbK4QMZzyAqY/zYCAEe1SAHr46tQKV791Vp82cJGTczk3IY6d0Jj0RZ9f4MzM2CVHbIw40HaP0uF25bDOcHPOroeI7MxgHUSXM+wlzCTnaHnAhRAee0P2hcMtG/njm5v59p6kUstWe1+dg/WF0BI5MQp+GpmQ1H/uTnjXxhru0c7EDx9cR9lnGG2BdCHT6XOQ8E+3JJTNFS8Pm1AOP3hAP9q1+gNFn6mnuPn1O7Pfha2JDWj5iRYeFItIn+Ju6LGjY+Vm20hZcK9dE1MpDoJcG8d1VOCQqrbTxf2/MLdfNtrlmEz7Fp9UGrJElFk4dLbM7oR5/+lW46FLjORagPMevxrqbYRXkAcZP063XAyQzSUSlQ0O x-ms-exchange-transport-forked: True MIME-Version: 1.0 X-OriginatorOrg: nccgroup.com X-MS-Exchange-CrossTenant-Network-Message-Id: df191c13-ca64-44c3-49b5-08d8094712a3 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 Jun 2020 11:53:33.1005 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a41111be-486b-45f6-8bd0-ee01a62f368e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: U0No8FWiWil1fZG1lrL+t9S2NosNN0POdp7o2u3bD7O5GQeKbkUN846U8ONXBxA39f8YdeC6P6x/rZkWVYydwm6lwuDpKqMNXBh76/yonMw= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWXP265MB1080 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: nccgroup.com Content-Type: multipart/alternative; boundary="_000_27FC2D65658D4E218484E95927CCA1BFnccgroupcom_" Archived-At: Subject: Re: [Crypto-panel] EXTERNAL: Request for review: draft-irtf-cfrg-hash-to-curve-08 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 11:53:45 -0000 --_000_27FC2D65658D4E218484E95927CCA1BFnccgroupcom_ Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 SSBjYW4gZG8gdGhhdC4NCg0KVGhvbWFzDQoNCkZyb206IENyeXB0by1wYW5lbCA8Y3J5cHRvLXBh bmVsLWJvdW5jZXNAaXJ0Zi5vcmc+IG9uIGJlaGFsZiBvZiAiU3RhbmlzbGF2IFYuIFNteXNobHlh ZXYiIDxzbXlzaHN2QGdtYWlsLmNvbT4NCkRhdGU6IEZyaWRheSwgSnVuZSA1LCAyMDIwIGF0IDAw OjE3DQpUbzogImNyeXB0by1wYW5lbEBpcnRmLm9yZyIgPGNyeXB0by1wYW5lbEBpcnRmLm9yZz4N CkNjOiAiZHJhZnQtaXJ0Zi1jZnJnLWhhc2gtdG8tY3VydmUuYXV0aG9yc0BpZXRmLm9yZyIgPGRy YWZ0LWlydGYtY2ZyZy1oYXNoLXRvLWN1cnZlLmF1dGhvcnNAaWV0Zi5vcmc+LCAiY2ZyZy1jaGFp cnNAaWV0Zi5vcmciIDxjZnJnLWNoYWlyc0BpZXRmLm9yZz4NClN1YmplY3Q6IEVYVEVSTkFMOiBb Q3J5cHRvLXBhbmVsXSBSZXF1ZXN0IGZvciByZXZpZXc6IGRyYWZ0LWlydGYtY2ZyZy1oYXNoLXRv LWN1cnZlLTA4DQoNCkRlYXIgQ3J5cHRvIFBhbmVsIG1lbWJlcnMsDQoNCkFsZXhleSwgTmljayBh bmQgSSB3b3VsZCBsaWtlIHRvIGFzayBDcnlwdG8gUmV2aWV3IFBhbmVsIG1lbWJlcnMgYWJvdXQg dGhlIHJldmlldyhzKSBvZiBkcmFmdC1pcnRmLWNmcmctaGFzaC10by1jdXJ2ZS0wOC4NCg0KVGhl IGRvY3VtZW50IHNwZWNpZmllcyBhIG51bWJlciBvZiBhbGdvcml0aG1zIGZvciBlbmNvZGluZyBv ciBoYXNoaW5nIGFuIGFyYml0cmFyeSBzdHJpbmcgdG8gYSBwb2ludCBvbiBhbiBlbGxpcHRpYyBj dXJ2ZS4NCg0KDQpDYW4gd2UgaGF2ZSBhbnkgdm9sdW50ZWVycywgcGxlYXNlPw0KDQoNCkJlc3Qg cmVnYXJkcywNClN0YW5pc2xhdiAob24gYmVoYWxmIG9mIGNoYWlycykNCg== --_000_27FC2D65658D4E218484E95927CCA1BFnccgroupcom_ Content-Type: text/html; charset=UTF-8 Content-ID: Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6bz0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6b2ZmaWNlIiB4 bWxuczp3PSJ1cm46c2NoZW1hcy1taWNyb3NvZnQtY29tOm9mZmljZTp3b3JkIiB4bWxuczptPSJo dHRwOi8vc2NoZW1hcy5taWNyb3NvZnQuY29tL29mZmljZS8yMDA0LzEyL29tbWwiIHhtbG5zPSJo dHRwOi8vd3d3LnczLm9yZy9UUi9SRUMtaHRtbDQwIj4NCjxoZWFkPg0KPG1ldGEgaHR0cC1lcXVp dj0iQ29udGVudC1UeXBlIiBjb250ZW50PSJ0ZXh0L2h0bWw7IGNoYXJzZXQ9dXRmLTgiPg0KPG1l dGEgbmFtZT0iR2VuZXJhdG9yIiBjb250ZW50PSJNaWNyb3NvZnQgV29yZCAxNSAoZmlsdGVyZWQg bWVkaXVtKSI+DQo8c3R5bGU+PCEtLQ0KLyogRm9udCBEZWZpbml0aW9ucyAqLw0KQGZvbnQtZmFj ZQ0KCXtmb250LWZhbWlseToiQ2FtYnJpYSBNYXRoIjsNCglwYW5vc2UtMToyIDQgNSAzIDUgNCA2 IDMgMiA0O30NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6Q2FsaWJyaTsNCglwYW5vc2UtMToy IDE1IDUgMiAyIDIgNCAzIDIgNDt9DQovKiBTdHlsZSBEZWZpbml0aW9ucyAqLw0KcC5Nc29Ob3Jt YWwsIGxpLk1zb05vcm1hbCwgZGl2Lk1zb05vcm1hbA0KCXttYXJnaW46MGNtOw0KCW1hcmdpbi1i b3R0b206LjAwMDFwdDsNCglmb250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJp IixzYW5zLXNlcmlmO30NCmE6bGluaywgc3Bhbi5Nc29IeXBlcmxpbmsNCgl7bXNvLXN0eWxlLXBy aW9yaXR5Ojk5Ow0KCWNvbG9yOiMwNTYzQzE7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9 DQphOnZpc2l0ZWQsIHNwYW4uTXNvSHlwZXJsaW5rRm9sbG93ZWQNCgl7bXNvLXN0eWxlLXByaW9y aXR5Ojk5Ow0KCWNvbG9yOiM5NTRGNzI7DQoJdGV4dC1kZWNvcmF0aW9uOnVuZGVybGluZTt9DQpw Lm1zb25vcm1hbDAsIGxpLm1zb25vcm1hbDAsIGRpdi5tc29ub3JtYWwwDQoJe21zby1zdHlsZS1u YW1lOm1zb25vcm1hbDsNCgltc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzsNCgltYXJnaW4tcmlnaHQ6 MGNtOw0KCW1zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvOw0KCW1hcmdpbi1sZWZ0OjBjbTsNCglm b250LXNpemU6MTEuMHB0Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCnNw YW4uRW1haWxTdHlsZTE4DQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLXJlcGx5Ow0KCWZvbnQt ZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmOw0KCWNvbG9yOndpbmRvd3RleHQ7fQ0KLk1zb0No cERlZmF1bHQNCgl7bXNvLXN0eWxlLXR5cGU6ZXhwb3J0LW9ubHk7DQoJZm9udC1zaXplOjEwLjBw dDt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2lu OjcyLjBwdCA3Mi4wcHQgNzIuMHB0IDcyLjBwdDt9DQpkaXYuV29yZFNlY3Rpb24xDQoJe3BhZ2U6 V29yZFNlY3Rpb24xO30NCi0tPjwvc3R5bGU+DQo8L2hlYWQ+DQo8Ym9keSBsYW5nPSJFTi1DQSIg bGluaz0iIzA1NjNDMSIgdmxpbms9IiM5NTRGNzIiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24x Ij4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIj5JIGNhbiBkbyB0aGF0 LjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9 IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48c3BhbiBsYW5nPSJFTi1VUyI+VGhvbWFzPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0I1QzRERiAx LjBwdDtwYWRkaW5nOjMuMHB0IDBjbSAwY20gMGNtIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxi PjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5Gcm9tOiA8L3NwYW4+ PC9iPjxzcGFuIHN0eWxlPSJmb250LXNpemU6MTIuMHB0O2NvbG9yOmJsYWNrIj5DcnlwdG8tcGFu ZWwgJmx0O2NyeXB0by1wYW5lbC1ib3VuY2VzQGlydGYub3JnJmd0OyBvbiBiZWhhbGYgb2YgJnF1 b3Q7U3RhbmlzbGF2IFYuIFNteXNobHlhZXYmcXVvdDsgJmx0O3NteXNoc3ZAZ21haWwuY29tJmd0 Ozxicj4NCjxiPkRhdGU6IDwvYj5GcmlkYXksIEp1bmUgNSwgMjAyMCBhdCAwMDoxNzxicj4NCjxi PlRvOiA8L2I+JnF1b3Q7Y3J5cHRvLXBhbmVsQGlydGYub3JnJnF1b3Q7ICZsdDtjcnlwdG8tcGFu ZWxAaXJ0Zi5vcmcmZ3Q7PGJyPg0KPGI+Q2M6IDwvYj4mcXVvdDtkcmFmdC1pcnRmLWNmcmctaGFz aC10by1jdXJ2ZS5hdXRob3JzQGlldGYub3JnJnF1b3Q7ICZsdDtkcmFmdC1pcnRmLWNmcmctaGFz aC10by1jdXJ2ZS5hdXRob3JzQGlldGYub3JnJmd0OywgJnF1b3Q7Y2ZyZy1jaGFpcnNAaWV0Zi5v cmcmcXVvdDsgJmx0O2NmcmctY2hhaXJzQGlldGYub3JnJmd0Ozxicj4NCjxiPlN1YmplY3Q6IDwv Yj5FWFRFUk5BTDogW0NyeXB0by1wYW5lbF0gUmVxdWVzdCBmb3IgcmV2aWV3OiBkcmFmdC1pcnRm LWNmcmctaGFzaC10by1jdXJ2ZS0wODxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+RGVhciBDcnlwdG8gUGFuZWwgbWVtYmVycywmbmJz cDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFsZXhleSwg TmljayBhbmQgSSB3b3VsZCBsaWtlIHRvIGFzayBDcnlwdG8gUmV2aWV3IFBhbmVsIG1lbWJlcnMg YWJvdXQgdGhlIHJldmlldyhzKSBvZiBkcmFmdC1pcnRmLWNmcmctaGFzaC10by1jdXJ2ZS0wOC48 bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+ Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+VGhl IGRvY3VtZW50IHNwZWNpZmllcyBhIG51bWJlciBvZiBhbGdvcml0aG1zIGZvciBlbmNvZGluZyBv ciBoYXNoaW5nIGFuIGFyYml0cmFyeSBzdHJpbmcgdG8gYSBwb2ludCBvbiBhbiBlbGxpcHRpYyBj dXJ2ZS4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5DYW4gd2UgaGF2ZSBhbnkgdm9sdW50ZWVycywgcGxlYXNlPzxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlc3QgcmVnYXJk cyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0 YW5pc2xhdiAob24gYmVoYWxmIG9mIGNoYWlycyk8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_27FC2D65658D4E218484E95927CCA1BFnccgroupcom_-- From nobody Fri Jun 5 05:11:00 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B43533A1497 for ; Fri, 5 Jun 2020 05:10:58 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XpV0vptv4DAw for ; Fri, 5 Jun 2020 05:10:57 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2FC673A1494 for ; Fri, 5 Jun 2020 05:10:57 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id c17so11394126lji.11 for ; Fri, 05 Jun 2020 05:10:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=93DEOpbVfx+ziRnidyd1Ds6jzrow5VFfrbWSC8GiSaw=; b=hw1GEmz3dw7SQBB9qPYX6mebenQbxQ5MgQjmRI3KC8AcoP/Kc7tPwa0Ujy7BHkRElc gZ9zqvR6DRvW+kG3WSDCfSs5LpHuTN9Oyu/2+7H+/ecup+4A92WuGRAgk8XcHXytlJWA 1s2SlwRU9UG/qGEbkkGKTvf4pSIvLQ45TF5Tn+2gCinUJQLOYv30xFN3NvHT0WAgJlqm yn0mrFrlxp4JfgPA5sJPfGhI1yoe6gG4dm8bLj8ddyDKCES7yQMU909czYSjc3TVtZv8 DVeeRAUka/BlQA1Cy2EsJk/1du4u8nSYEQDl+a/PXmlsbyrCSgSF/FIy9vREMVd6mFoC qDKQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=93DEOpbVfx+ziRnidyd1Ds6jzrow5VFfrbWSC8GiSaw=; b=NxZIqkd/gUvjCfSvsS7YvPMENbyHjkvvzJ+G/ggIWqIwHDRuiSgRogoBoiZPsSZ5s/ 4HoXo5uwlaQHIZAM6c0S5iRO1E0vY69Ty4R2hLmWzAngLADo1C5kEqFPam+YvQhT2M52 jQmJPEPC62+Y6cgA1Gze7qmvU+6yPjQHUbikR6ptKoQkyZIQCTKxTzT4P4V6fDDpafkf qVaAzbShmD7z7XJ6RiR0dOUDdT459VGpsw0tcj4y26jTG7jD1/Vc9cjV7UHJN4LS2ilu eyeB/7YegwVP3vmTmnnad+OnZPJ3O5h3cI0QEBHmAXBCZbarl74ipvnJlfH/X8YTzqv/ Ixig== X-Gm-Message-State: AOAM531qV/ChhXVd+xoi3gqIuhM1k2f0rYnFlwW5jzARuRayCJEEsnqV kVPCEVKtv8ric5aXmJJfkXn+PHQuPBAPS958TN0= X-Google-Smtp-Source: ABdhPJwvSccDQmo6mEniRU+WfYXbyT7uttX8C0y2xhre9qElbuZfeBwFbuosthiq6U+546cbkffl119O6/na2PeB3sE= X-Received: by 2002:a2e:918e:: with SMTP id f14mr3557005ljg.229.1591359051936; Fri, 05 Jun 2020 05:10:51 -0700 (PDT) MIME-Version: 1.0 References: <27FC2D65-658D-4E21-8484-E95927CCA1BF@nccgroup.com> In-Reply-To: <27FC2D65-658D-4E21-8484-E95927CCA1BF@nccgroup.com> From: "Stanislav V. Smyshlyaev" Date: Fri, 5 Jun 2020 15:10:41 +0300 Message-ID: To: Thomas Pornin Cc: "crypto-panel@irtf.org" , "draft-irtf-cfrg-hash-to-curve.authors@ietf.org" , "cfrg-chairs@ietf.org" Content-Type: multipart/alternative; boundary="0000000000000036ec05a7552747" Archived-At: Subject: Re: [Crypto-panel] EXTERNAL: Request for review: draft-irtf-cfrg-hash-to-curve-08 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 12:10:59 -0000 --0000000000000036ec05a7552747 Content-Type: text/plain; charset="UTF-8" Great, many thanks, Thomas! Stanislav (for Chairs) On Fri, 5 Jun 2020 at 14:53, Thomas Pornin wrote: > I can do that. > > > > Thomas > > > > *From: *Crypto-panel on behalf of > "Stanislav V. Smyshlyaev" > *Date: *Friday, June 5, 2020 at 00:17 > *To: *"crypto-panel@irtf.org" > *Cc: *"draft-irtf-cfrg-hash-to-curve.authors@ietf.org" < > draft-irtf-cfrg-hash-to-curve.authors@ietf.org>, "cfrg-chairs@ietf.org" < > cfrg-chairs@ietf.org> > *Subject: *EXTERNAL: [Crypto-panel] Request for review: > draft-irtf-cfrg-hash-to-curve-08 > > > > Dear Crypto Panel members, > > > > Alexey, Nick and I would like to ask Crypto Review Panel members about the > review(s) of draft-irtf-cfrg-hash-to-curve-08. > > > > The document specifies a number of algorithms for encoding or hashing an > arbitrary string to a point on an elliptic curve. > > > > > > Can we have any volunteers, please? > > > > > > Best regards, > > Stanislav (on behalf of chairs) > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > --0000000000000036ec05a7552747 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Great, many thanks, Thomas!

Stanislav (= for Chairs)

On Fri, 5 Jun 2020 at 14:53, Thomas Pornin <thomas.porn= in=3D40nccgroup.com@dmarc.= ietf.org> wrote:

I can do that.

=C2=A0

Thomas

=C2=A0

From: = Crypto-panel <crypto-panel= -bounces@irtf.org> on behalf of "Stanislav V. Smyshlyaev" = <smyshsv@gmail.co= m>
Date: Friday, June 5, 2020 at 00:17
To: "crypto-panel@irtf.org" <crypto-panel@irtf.org>
Cc: "draft-irtf-cfrg-hash-to-curve.authors@ietf.org" <draft-irtf-cfrg-hash-to-curve.authors@ietf.org>= , "cfrg-chai= rs@ietf.org" <cfrg-chairs@ietf.org>
Subject: EXTERNAL: [Crypto-panel] Request for review: draft-irtf-cfr= g-hash-to-curve-08

=C2=A0

Dear Crypto Panel members,=C2=A0

=C2=A0

Alexey, Nick and I would like to ask Crypto Review P= anel members about the review(s) of draft-irtf-cfrg-hash-to-curve-08.

=C2=A0

The document specifies a number of algorithms for en= coding or hashing an arbitrary string to a point on an elliptic curve.=C2= =A0

=C2=A0

=C2=A0

Can we have any volunteers, please?

=C2=A0

=C2=A0

Best regards,

Stanislav (on behalf of chairs)

_______________________________________________
Crypto-panel mailing list
Crypto-panel@irt= f.org
https://www.irtf.org/mailman/listinfo/crypto-panel=
--0000000000000036ec05a7552747-- From nobody Fri Jun 5 07:48:14 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ED363A0798 for ; Fri, 5 Jun 2020 07:48:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.098 X-Spam-Level: X-Spam-Status: No, score=-2.098 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, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=heapingbits.net header.b=EDC3KC9g; dkim=pass (2048-bit key) header.d=messagingengine.com header.b=rQRuiECF Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YSgdc5r3N3mK for ; Fri, 5 Jun 2020 07:48:11 -0700 (PDT) Received: from out4-smtp.messagingengine.com (out4-smtp.messagingengine.com [66.111.4.28]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CA9853A0793 for ; Fri, 5 Jun 2020 07:48:10 -0700 (PDT) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 1E6375C014E; Fri, 5 Jun 2020 10:48:10 -0400 (EDT) Received: from imap4 ([10.202.2.54]) by compute1.internal (MEProxy); Fri, 05 Jun 2020 10:48:10 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=heapingbits.net; h=mime-version:message-id:in-reply-to:references:date:from:to :cc:subject:content-type; s=fm1; bh=JxrsZmKj90VaBgF4JKqhi9sseMRX F7psQ384MyC7SJM=; b=EDC3KC9gwzv7l+3eFuXUUoVtPeeZpffHXJh3X6/bZr1g x/o8mhnNaN++rVpePUcnxdYA9LsjKg5B3P5wLWFzO1Xn0RWYgJUt5fg0LviasP0l j0358lmHETDYuawXxyCBXd0Fr43QlCIiYJf/hD4jRqzmpkSI2fZFbhXsuChdHaZr V5lO4+bTawKW8lNr6r0NHR5olb6Zzl0KNbc52fuzs5lCl8STeOAx4wMf0yHYR6im 4o09Ti3PyNV6yC7bW9DqICXKjFW01rC7eoG3vjWv5PFYsas9sMnhLSbds0MZtlDs /3iVHhyj2BDjayBFHnXZNtusNRKa8ReIq00dOQejCg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=JxrsZm Kj90VaBgF4JKqhi9sseMRXF7psQ384MyC7SJM=; b=rQRuiECFAQ/9KScUTapBS2 QM9m/JR5UJ2nn84K2XCKA0gm1XAFrFi9QExr768DVjN8tlBd+M0Jv5M24e0D3A3V FZC9DRvcJ9g8OuNBpzBG09aWivVnouDC9PGXhVnnefgakZtnyg9by/xtBrOB++vP /hvPVxEl41XU5QIYjkr0bOlbTThPAFIMRkI+yp0w/CDtZLb0SRSOXcuNUAkg/PSI yiw9mK7e0VhOSkD0yORpvI60SyZ/Jlt0GydVe+WP3Swn/9+AptCH6n9Afjjzs5Zt cuWERsUdypU5r9GAL4CTrJHVv4Dsxh8riCMd6DEzsZrOrSGGA4EzGqzv+P2WhGOA == X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeduhedrudegfedgjedtucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepofgfggfkjghffffhvffutgesthdtredtreerjeenucfhrhhomhepfdevhhhr ihhsthhophhhvghrucghohhougdfuceotggrfieshhgvrghpihhnghgsihhtshdrnhgvth eqnecuggftrfgrthhtvghrnhepfeevhedtueehtdfghfdtvdduhfettdelkeffgeeuueev ueegteegueekteevieefnecuffhomhgrihhnpehirhhtfhdrohhrghenucevlhhushhtvg hrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegtrgifsehhvggrphhinhhg sghithhsrdhnvght X-ME-Proxy: Received: by mailuser.nyi.internal (Postfix, from userid 501) id 1BE793C00A1; Fri, 5 Jun 2020 10:48:09 -0400 (EDT) X-Mailer: MessagingEngine.com Webmail Interface User-Agent: Cyrus-JMAP/3.3.0-dev0-519-g0f677ba-fm-20200601.001-g0f677ba6 Mime-Version: 1.0 Message-Id: <022045fd-02b2-4958-9749-dbeb45470c56@www.fastmail.com> In-Reply-To: References: <27FC2D65-658D-4E21-8484-E95927CCA1BF@nccgroup.com> Date: Fri, 05 Jun 2020 07:47:48 -0700 From: "Christopher Wood" To: "Stanislav V. Smyshlyaev" , "Thomas Pornin" Cc: "crypto-panel@irtf.org" , "draft-irtf-cfrg-hash-to-curve.authors@ietf.org" , "cfrg-chairs@ietf.org" Content-Type: text/plain Archived-At: Subject: Re: [Crypto-panel] =?utf-8?q?EXTERNAL=3A_Request_for_review=3A_draft?= =?utf-8?q?-irtf-cfrg-hash-to-curve-08?= X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 05 Jun 2020 14:48:12 -0000 On Fri, Jun 5, 2020, at 5:10 AM, Stanislav V. Smyshlyaev wrote: > Great, many thanks, Thomas! +1 :-) Best, Chris > Stanislav (for Chairs) > > On Fri, 5 Jun 2020 at 14:53, Thomas Pornin > wrote: > > I can do that.____ > > > __ __ > > > Thomas____ > > > __ __ > > > *From: *Crypto-panel on behalf of "Stanislav V. Smyshlyaev" > > *Date: *Friday, June 5, 2020 at 00:17 > > *To: *"crypto-panel@irtf.org" > > *Cc: *"draft-irtf-cfrg-hash-to-curve.authors@ietf.org" , "cfrg-chairs@ietf.org" > > *Subject: *EXTERNAL: [Crypto-panel] Request for review: draft-irtf-cfrg-hash-to-curve-08____ > > > __ __ > > > Dear Crypto Panel members, ____ > > > __ __ > > > Alexey, Nick and I would like to ask Crypto Review Panel members about the review(s) of draft-irtf-cfrg-hash-to-curve-08.____ > > > __ __ > > > The document specifies a number of algorithms for encoding or hashing an arbitrary string to a point on an elliptic curve. ____ > > > __ __ > > > __ __ > > > Can we have any volunteers, please?____ > > > __ __ > > > __ __ > > > Best regards,____ > > > Stanislav (on behalf of chairs)____ > > > _______________________________________________ > > Crypto-panel mailing list > > Crypto-panel@irtf.org > > https://www.irtf.org/mailman/listinfo/crypto-panel From nobody Mon Jun 8 14:54:08 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 49F173A0807 for ; Mon, 8 Jun 2020 14:54:07 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtUsGxkEb0Gr for ; Mon, 8 Jun 2020 14:54:04 -0700 (PDT) Received: from mail-vk1-xa36.google.com (mail-vk1-xa36.google.com [IPv6:2607:f8b0:4864:20::a36]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3BD493A0802 for ; Mon, 8 Jun 2020 14:54:04 -0700 (PDT) Received: by mail-vk1-xa36.google.com with SMTP id i1so4375905vkp.8 for ; Mon, 08 Jun 2020 14:54:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=sfuvvISqrLBPgjT0MvTwQnrbrySrjyr9zLR+dZgx6Lo=; b=sNJNlLoONvT1GCKCAgkugtXEx16jczs2+z6fUU/23aU4fIHFs3yPZxRHPC7G5zbxvb GtT8AB8bqNRgYx7jk40IlSPY2u87ufWqMOXbsRTIDHxCx8Z4a8rnuxKx/RiNTDYayzSg J7Umk0KdwIgmEr7azJivAmBWbKl1I/Bi+sS64= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=sfuvvISqrLBPgjT0MvTwQnrbrySrjyr9zLR+dZgx6Lo=; b=foErLeFB4bEYIRPvHx61e9Y+9kNv0ULqCO5mrDbIbaQ0f3VI3TwcyBEpvV819HBOP5 txABB3fXGMH0BqtubqBscZR8aiizI2G5Znvcjafp7J83W+y4MvG4Nd+25S3M2CiJZlGY 67bn8u6dPTx53Pv4DeuhjovzpJy0usMB2tl4zVrQaslpLgHL+8vuxp6UYhbJKAINhBKR P01LxhESVQso2L4ihBnatY3I5sU74G/XffMQO+ncmIw9zr/ezsFgMS/JVhcZFYft1XWM Sk3kMdvc9lEtIErum2ger4YNEDSmb5B8YiP86L6pQ1G3BrdmI6GDZ8cB7Psm/8Ksst81 nL8A== X-Gm-Message-State: AOAM533ACLYg3/SczFhsS2JqcIFVOnR4muwM15HBUtJR6DnEP5qpgkLB rcPC228lWYFaaPvWnJYz7OMa3Q7xw6xpdksKMVr7WYjDiYHImw== X-Google-Smtp-Source: ABdhPJw6uZrQJqhyDNL3HpNqPr4ckJVvcPkjqeOlSkoKeSs0BYP2XXfk63RV2bds/XYv56AcXjtr3jBg6SR6PAPQVbo= X-Received: by 2002:a1f:48c4:: with SMTP id v187mr523865vka.23.1591653242825; Mon, 08 Jun 2020 14:54:02 -0700 (PDT) MIME-Version: 1.0 From: Nick Sullivan Date: Mon, 8 Jun 2020 14:53:45 -0700 Message-ID: To: crypto-panel@irtf.org Cc: cfrg-chairs@ietf.org, draft-irtf-cfrg-hpke@ietf.org Content-Type: multipart/alternative; boundary="0000000000002525b605a799a6ae" Archived-At: Subject: [Crypto-panel] Request for review: draft-irtf-cfrg-hpke-04 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 21:54:07 -0000 --0000000000002525b605a799a6ae Content-Type: text/plain; charset="UTF-8" Dear Crypto Panel members, Alexey, Stanislav and I would like to ask Crypto Review Panel members for a review of https://www.ietf.org/id/draft-irtf-cfrg-hpke-04.html. The document specifies a set of mechanisms to do hybrid public key encryption. It can be thought of as a generalization of ECIES for any KEM. This document went through last call and didn't receive many comments, so a thorough review from a crypto panel member would be helpful to move this document forward. Who would like to volunteer? Best regards, Nick (on behalf of chairs) --0000000000002525b605a799a6ae Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Crypto Panel members,

Alexey, Stanislav and I= would like to ask Crypto Review Panel members for a review of=C2=A0https://www.ietf.= org/id/draft-irtf-cfrg-hpke-04.html. The document specifies a set of me= chanisms to do hybrid public key encryption. It can be thought of as a gene= ralization of ECIES for any KEM.

This document went thro= ugh last call and didn't receive=C2=A0many comments, so a thorough revi= ew from a crypto panel member would be=C2=A0helpful to move this document f= orward.

Who would like to=C2=A0volunteer?

Best regards,
Nick (on behalf of chairs)
--0000000000002525b605a799a6ae-- From nobody Mon Jun 8 14:57:04 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD12C3A0807 for ; Mon, 8 Jun 2020 14:57:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.999 X-Spam-Level: X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cs.tcd.ie Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M0eTqF3b2EvI for ; Mon, 8 Jun 2020 14:57:01 -0700 (PDT) Received: from mercury.scss.tcd.ie (mercury.scss.tcd.ie [134.226.56.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E457E3A080B for ; Mon, 8 Jun 2020 14:57:00 -0700 (PDT) Received: from localhost (localhost [127.0.0.1]) by mercury.scss.tcd.ie (Postfix) with ESMTP id A8BC1BE4C; Mon, 8 Jun 2020 22:56:57 +0100 (IST) X-Virus-Scanned: Debian amavisd-new at scss.tcd.ie Received: from mercury.scss.tcd.ie ([127.0.0.1]) by localhost (mercury.scss.tcd.ie [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id D2btPqZfJFYm; Mon, 8 Jun 2020 22:56:55 +0100 (IST) Received: from [10.244.2.119] (95-45-153-252-dynamic.agg2.phb.bdt-fng.eircom.net [95.45.153.252]) by mercury.scss.tcd.ie (Postfix) with ESMTPSA id 59454BE47; Mon, 8 Jun 2020 22:56:55 +0100 (IST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cs.tcd.ie; s=mail; t=1591653415; bh=xQ2RmVx92Wq5PmjyPTPOvUzX5zm+7PcgFOBSCQfCxYw=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=h1ZVobaMrss4MNIiHud3uUeJSIR2riTmey4Q9QhZHuFMz0AVoEEpi70NssADqkJ5h bKJZT6TCtl+ZUnEPv2mZhxcUYL1cpQyOzfvEQ/vpfZMeHx/uPlAiEbdHX31rc638D7 0XQ3WLnrK5G0O3m3FGkkw6Jt/cV5VzlamxrLKZBY= To: Nick Sullivan , crypto-panel@irtf.org Cc: draft-irtf-cfrg-hpke@ietf.org, cfrg-chairs@ietf.org References: From: Stephen Farrell Autocrypt: addr=stephen.farrell@cs.tcd.ie; prefer-encrypt=mutual; keydata= mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nemCP5PMvmh 5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kTq0IqYzsEv5HI58S+ QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtEgvw4fVhVWJuyy3w//0F2tzKr EMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy+pAh4EKzS1FE7BOZp9daMu9MUQmDqtZU bUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqO Vz+7L+WiVfxLbeVqBwV+4uL9to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJg b097ZaNyuY1ETghVB5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k 4LyM2lp5FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9tlyWxn5Xi HzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQABtDJTdGVwaGVuIEZh cnJlbGwgKDIwMTcpIDxzdGVwaGVuLmZhcnJlbGxAY3MudGNkLmllPokCQAQTAQgAKgIbAwUJ CZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAUCWj6jdwIZAQAKCRBasvrxexcr6o7QD/9m x9DPJetmW794RXmNTrbTJ44zc/tJbcLdRBh0KBn9OW/EaAqjDmgNJeCMyJTKr1ywaps8HGUN hLEVkc14NUpgi4/Zkrbi3DmTp25OHj6wXBS5qVMyVynTMEIjOfeFFyxG+48od+Xn7qg6LT7G rHeNf+z/r0v9+8eZ1Ip63kshQDGhhpmRMKu4Ws9ZvTW2ACXkkTFaSGYJj3yIP4R6IgwBYGMz DXFX6nS4LA1s3pcPNxOgrvCyb60AiJZTLcOk/rRrpZtXB1XQc23ZZmrlTkl2HaThL6w3YKdi Ti1NbuMeOxZqtXcUshII45sANm4HuWNTiRh93Bn5bN6ddjgsaXEZBKUBuUaPBl7gQiQJcAlS 3MmGgVS4ZoX8+VaPGpXdQVFyBMRFlOKOC5XJESt7wY0RE2C8PFm+5eywSO/P1fkl9whkMgml 3OEuIQiP2ehRt/HVLMHkoM9CPQ7t6UwdrXrvX+vBZykav8x9U9M6KTgfsXytxUl6Vx5lPMLi 2/Jrsz6Mzh/IVZa3xjhq1OLFSI/tT2ji4FkJDQbO+yYUDhcuqfakDmtWLMxecZsY6O58A/95 8Qni6Xeq+Nh7zJ7wNcQOMoDGj+24di2TX1cKLzdDMWFaWzlNP5dB5VMwS9Wqj1Z6TzKjGjru q8soqohwb2CK9B3wzFg0Bs1iBI+2RuFnxLkCDQRaPVAyARAA+g3R0HzGr/Dl34Y07XqGqzq5 SU0nXIu9u8Ynsxj7gR5qb3HgUWYEWrHW2jHOByXnvkffucf5yzwrsvw8Q8iI8CFHiTYHPpey 4yPVn6R0w/FOMcY70eTIu/k6EEFDlDbs09DtKcrsT9bmN0XoRxITlXwWTufYqUnmS+YkAuk+ TLCtUin7OdaS2uU6Ata3PLQSeM2ZsUQMmYmHPwB9rmf+q2I005AJ9Q1SPQ2KNg/8xOGxo13S VuaSqYRQdpV93RuCOzg4vuXtR+gP0KQrus/P2ZCEPvU9cXF/2MIhXgOz207lv3iE2zGyNXld /n8spvWk+0bH5Zqd9Wcba/rGcBhmX9NKKDARZqjkv/zVEP1X97w1HsNYeUFNcg2lk9zQKb4v l1jx/Uz8ukzH2QNhU4R39dbF/4AwWuSVkGW6bTxHJqGs6YimbfdQqxTzmqFwz3JP0OtXX5q/ 6D4pHwcmJwEiDNzsBLl6skPSQ0Xyq3pua/qAP8MVm+YxCxJQITqZ8qjDLzoe7s9X6FLLC/DA L9kxl5saVSfDbuI3usH/emdtn0NA9/M7nfgih92zD92sl1yQXHT6BDa8xW1j+RU4P+E0wyd7 zgB2UeYgrp2IIcfG+xX2uFG5MJQ/nYfBoiALb0+dQHNHDtFnNGY3Oe8z1M9c5aDG3/s29QbJ +w7hEKKo9YMAEQEAAYkCJQQYAQgADwUCWj1QMgIbDAUJCZQmAAAKCRBasvrxexcr6qwvD/9b Rek3kfN8Q+jGrKl8qwY8HC5s4mhdDJZI/JP2FImf5J2+d5/e8UJ4fcsT79E0/FqX3Z9wZr6h sofPqLh1/YzDsYkZDHTYSGrlWGP/I5kXwUmFnBZHzM3WGrL3S7ZmCYMdudhykxXXjq7M6Do1 oxM8JofrXGtwBTLv5wfvvygJouVCVe87Ge7mCeY5vey1eUi4zSSF1zPpR6gg64w2g4TXM5qt SwkZVOv1g475LsGlYWRuJV8TA67yp1zJI7HkNqCo8KyHX0DPOh9c+Sd9ZX4aqKfqH9HIpnCL AYEgj7vofeix7gM3kQQmwynqq32bQGQBrKJEYp2vfeO30VsVx4dzuuiC5lyjUccVmw5D72J0 FlGrfEm0kw6D1qwyBg0SAMqamKN6XDdjhNAtXIaoA2UMZK/vZGGUKbqTgDdk0fnzOyb2zvXK CiPFKqIPAqKaDHg0JHdGI3KpQdRNLLzgx083EqEc6IAwWA6jSz+6lZDV6XDgF0lYqAYIkg3+ 6OUXUv6plMlwSHquiOc/MQXHfgUP5//Ra5JuiuyCj954FD+MBKIj8eWROfnzyEnBplVHGSDI ZLzL3pvV14dcsoajdeIH45i8DxnVm64BvEFHtLNlnliMrLOrk4shfmWyUqNlzilXN2BTFVFH 4MrnagFdcFnWYp1JPh96ZKjiqBwMv/H0kw== Message-ID: Date: Mon, 8 Jun 2020 22:56:54 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fK3fMVcTsN0Wo5DC8KyyfL2IbqEOuj7Ch" Archived-At: Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-hpke-04 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Jun 2020 21:57:04 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --fK3fMVcTsN0Wo5DC8KyyfL2IbqEOuj7Ch Content-Type: multipart/mixed; boundary="7vMLCMq3Du1c7trv13oeiwmsXQvJdd8Re"; protected-headers="v1" From: Stephen Farrell To: Nick Sullivan , crypto-panel@irtf.org Cc: draft-irtf-cfrg-hpke@ietf.org, cfrg-chairs@ietf.org Message-ID: Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-hpke-04 References: In-Reply-To: --7vMLCMq3Du1c7trv13oeiwmsXQvJdd8Re Content-Type: multipart/mixed; boundary="------------FB49F5CDC80E63959B2389BC" Content-Language: en-US This is a multi-part message in MIME format. --------------FB49F5CDC80E63959B2389BC Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable I've implemented an earlier version [1] and will be coding up the final one. Happy to do it, or for that to be considered disqualifying:-) Cheers, S. [1] https://github.com/sftcd/happykey On 08/06/2020 22:53, Nick Sullivan wrote: > Dear Crypto Panel members, >=20 > Alexey, Stanislav and I would like to ask Crypto Review Panel members f= or a > review of https://www.ietf.org/id/draft-irtf-cfrg-hpke-04.html. The > document specifies a set of mechanisms to do hybrid public key encrypti= on. > It can be thought of as a generalization of ECIES for any KEM. >=20 > This document went through last call and didn't receive many comments, = so a > thorough review from a crypto panel member would be helpful to move thi= s > document forward. >=20 > Who would like to volunteer? >=20 > Best regards, > Nick (on behalf of chairs) >=20 >=20 > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel >=20 --------------FB49F5CDC80E63959B2389BC Content-Type: application/pgp-keys; name="0x5AB2FAF17B172BEA.asc" Content-Transfer-Encoding: quoted-printable Content-Disposition: attachment; filename="0x5AB2FAF17B172BEA.asc" -----BEGIN PGP PUBLIC KEY BLOCK----- mQINBFo9UDIBEADUH4ZPcUnX5WWRWO4kEkHea5Y5eEvZjSwe/YA+G0nrTuOU9nem CP5PMvmh5Cg8gBTyWyN4Z2+O25p9Tja5zUb+vPMWYvOtokRrp46yhFZOmiS5b6kT q0IqYzsEv5HI58S+QtaFq978CRa4xH9Gi9u4yzUmT03QNIGDXE37honcAM4MOEtE gvw4fVhVWJuyy3w//0F2tzKrEMjmL5VGuD/Q9+G/7abuXiYNNd9ZFjv4625AUWwy +pAh4EKzS1FE7BOZp9daMu9MUQmDqtZUbUv0Q+DnQAB/4tNncejJPz0p2z3MWCp5 iSwHiQvytYgatMp34a50l6CWqa13n6vY8VcPlIqOVz+7L+WiVfxLbeVqBwV+4uL9 to9zLF9IyUvl94lCxpscR2kgRgpM6A5LylRDkR6E0oudFnJgb097ZaNyuY1ETghV B5Uir1GCYChs8NUNumTHXiOkuzk+Gs4DAHx/a78YxBolKHi+esLH8r2k4LyM2lp5 FmBKjG7cGcpBGmWavACYEa7rwAadg4uBx9SHMV5i33vDXQUZcmW0vslQ2Is02NMK 7uB7E7HlVE1IM1zNkVTYYGkKreU8DVQu8qNOtPVE/CdaCJ/pbXoYeHz2B1Nvbl9t lyWxn5XiHzFPJleXc0ksb9SkJokAfwTSZzTxeQPER8la5lsEEPbU/cDTcwARAQAB tCFTdGVwaGVuIEZhcnJlbGwgPHN0ZXBoZW5AamVsbC5pZT6JAj0EEwEIACcFAlo9 UYwCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwECHgECF4AACgkQWrL68XsXK+qG CxAApYHWYgGOIL3G6/OpkejdAkQoCVQAK8LJUSf6vzwost4iVfxIKcKW/3RqKNKk rRl8beJ7j1CWXAz9+VXAOsE9+zNxXIDgGA7HlvJnhffl+qwibVgiHgUcJFhCSbBr sjC+1uULaTU8zYEyET//GOGPLF+X+degkE/sesh4zcEAjF7fGPnlncdCCH3tvPZZ sdTcjwOCRVonKsDgQzBTCMz/RPBfEFX44HZx4g1UQAcCA4xlucY8QkJEyCrSNGpG nvGK8DcGSmnstl1/a9fnlhpdFxieX3oY2phJ1WKkYTn6Advrek3UP71CKxpgtPmk d3iUUz/VZa0Cv6YxQXskspRDVEvdCMYSQBtJPQ4y2+5UxVR9GIQXenwYp9AP2niv Voh+ITsDWWeWnnvYMq07rSDjq0nGdj41MJkNX+Yb2PXVyXItcj5ybE3T2+y3pSBG FEZYJGuaL4NwtBJFMOdOtBmUOPbetS2971EL3Izxb7ibOZWDwexv+8R6SWYfP1wV N3p46RyBQuXqJV8ccE11m6vtZTGSYgnLUUFZMRQYH+0hwuYe0T3AA18xDdSYsa8v ovCCd3l5S4UNzIM2PMChqGrEzKapUpZg7+8ACcxRU3b9Ihd7WYjJ+pQPCoWYKozv tEvenbNpE/govO/ED3B14e+R2yevRPjRrsN7PJzSf15fQLuJARwEEAEIAAYFAlo9 UqAACgkQLzyHNoBfjaLrSwf+MIHbFRQ4O5cmLYR5sIByWelN3SuRN/gW8rpKo9Ok Cz6An8uV/iCXy5tNMLzzi0BFl8f22DwBcC5qy9qnlIAdogWam1qWoTAoAD8veEqm uKhYrqJsCcAyNrKYmK0hP3rpHxx1LySDmKYXmw/8qtBXKHTouMm+5tSsznhykRMT AAr2p7PSaHgo+hIVaW/rKSspHjDhhZS+G9mtOZad1IH29M6G1Q1NCO0Ywe8krKLQ IAQlFxtgvOqpPOZNzeKBa/+KbE8TGgMWrkOhC8OeEM5PVzdDhlhD9kPzB/pCKDF5 DofJ/ZRqnDpbKPQ0bsW38AOig3kOc0A27awiBEw3urqR1YkCMwQQAQgAHRYhBH4X CgRchM9GDit5oBDvedn9g1MSBQJbtyScAAoJEBDvedn9g1MSI/oP/0A9J9nrnBMq Zpm857lfYWw+rshLK+tyeP4OQeOqnDFvs9jePpcyJLG3DF2r6VbVKPQq+AE6Uf5h cJBDEN6BjEhRPSbLcqG3A1cz/nNwm8rPmNp+oKhmaBBQGxwciMLmzgynsDydnjPp MyEs04zvsbsl4vrp2095o105l8KcrrxQrioFjbwveGwHQK9bxJKhx9D+gIk+MouB ur45UDKTZkMZrr9FGrtkyXCGAxvKdcNC5Oa8z9sj1rcUJfG/OpVAMWhArdlZbFUQ yoX6pU2Zb1CR2qpWAVerGSfBhmfCyStjARqaKxlftjO+Bj3Jj73Cr5eqej3qB5+V 4BCsPjr4RLvVbYUCPsRdxWc+nBLlfVYkRURu21g1hFm5KFPjgUkyo1s4vjUOY8Dy I+xLGF7f/IhUBG6l+Vswhpwu7ydalZkeFiPx5xna5NfbEYxvsIf71DvipGvIOaHv X4egWoFgm8n/9c3rcMxJtpwHPSsUt5dgLsyu6VE0IbvOAc3dN7CWJ355DVFJq9Zg 2YVf0izSpyyzJeGsgkfjW6xpmdvZxuT2UcN4BTcm6vYqueASGrb3lfhzC5gpeVsc /MoSjTS65vNWbpzONZWMZuLEFraxWJzC0JrDK3NCd0VN3kstqGkVbUIiYOnUm8Vu 4zoVMLlGWzHLIGoPRG2nRezn1YyNfyb5iQGcBBABCgAGBQJbxcflAAoJEGo7ETk8 pK1gE7QL/ApC5P68W5DrI1787WJVZv1u4t/g39vTr7Xer3UMTVQg10vpa7pmqOGh jIDzDMg3Pe3K3M7fVzfAlUA1qw6ne4RCueVoRKpubeF4AlYbMr0K6hNCPjt5uAxm bBVuejKTc6pru5rv5gKL0nDbr+Snft5xt7juBLSSimw0/41sZnkjCxo9rF/RA/v6 +uWyK171RKmsEYu8fFtw1eqUNt/Xj792TUixE3pxXheNtQtZGk/9P3W83ChhG4Fh 5EQsn0pIh9wZIAbMRLpgRKyW87fWHZC8/YH8h7afarvn9Thl5pFUldCe22mNJj6K LChn2aEHQd+PdY1GBpZEcmNEUPuovwzatM0h64hCzTm41eDqRfihZVBT7TbfXQnv 8rywa42Mk756RGzzEZcQEhwQXZcMQUfxIQQ2VyJo0zG36VdZTQF7TF/4Lz7/3cJ5 6jOIm+dwPXtu+C2wAQuD4USOLt4JWPYpqzDfHYJIND/497P9Z9SuQeahr2ez3DRB g3qsHEjBV7QyU3RlcGhlbiBGYXJyZWxsICgyMDE3KSA8c3RlcGhlbi5mYXJyZWxs QGNzLnRjZC5pZT6JAkAEEwEIACoCGwMFCQmUJgAFCwkIBwIGFQgJCgsCBBYCAwEC HgECF4AFAlo+o3cCGQEACgkQWrL68XsXK+qO0A//ZsfQzyXrZlu/eEV5jU620yeO M3P7SW3C3UQYdCgZ/TlvxGgKow5oDSXgjMiUyq9csGqbPBxlDYSxFZHNeDVKYIuP 2ZK24tw5k6duTh4+sFwUualTMlcp0zBCIzn3hRcsRvuPKHfl5+6oOi0+xqx3jX/s /69L/fvHmdSKet5LIUAxoYaZkTCruFrPWb01tgAl5JExWkhmCY98iD+EeiIMAWBj Mw1xV+p0uCwNbN6XDzcToK7wsm+tAIiWUy3DpP60a6WbVwdV0HNt2WZq5U5Jdh2k 4S+sN2CnYk4tTW7jHjsWarV3FLISCOObADZuB7ljU4kYfdwZ+WzenXY4LGlxGQSl AblGjwZe4EIkCXAJUtzJhoFUuGaF/PlWjxqV3UFRcgTERZTijguVyREre8GNERNg vDxZvuXssEjvz9X5JfcIZDIJpdzhLiEIj9noUbfx1SzB5KDPQj0O7elMHa1671/r wWcpGr/MfVPTOik4H7F8rcVJelceZTzC4tvya7M+jM4fyFWWt8Y4atTixUiP7U9o 4uBZCQ0GzvsmFA4XLqn2pA5rVizMXnGbGOjufAP/efEJ4ul3qvjYe8ye8DXEDjKA xo/tuHYtk19XCi83QzFhWls5TT+XQeVTMEvVqo9Wek8yoxo67qvLKKqIcG9givQd 8MxYNAbNYgSPtkbhZ8SJARwEEAEIAAYFAlo9UqAACgkQLzyHNoBfjaLzHAgAlWT6 NXEGtw/r1miKNGcopzvzILQ9oB8rKI9U9EL6tOf/y2V5oYee/GyQDb3ZdoPxxYYc Jf+RyiH1nMoqUIZiZJaf3bJXinDZ5+AdfE++UR2NBvqaNyC6u3r24jo1B/sagKbY tWgsYtRqHLD4IWi37MZrVyjBuF7u14Q07+uhjq6mX2O/tHpCYw/Q82tbeTRPyUf1 WQOAfD1kfBpW9PvAva5Iw9FWeXpCXRzwxnCZhYfGfqtuSw6CPBYLdbikqML6FZ7E DuTBb/8um1wK7Y9bgeIQC+CYjhYB5RXa1tDJRab2Js4luCvSR0w/CgHw26293tlv e2Q6UTrmHxP5U22DlokCPQQTAQgAJwUCWj1QMgIbAwUJCZQmAAULCQgHAgYVCAkK CwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6tJpD/4rrILH+meP07vrx8wW5eYuqCiP GYnh/CXxIF8eLrfbe5d4QRgtq+w6UeQPMyzKRIRiCoBXB2oJLBZHyxBPxZlg33dT MrEGn8QWKx2iNuz9rZMXyOSWFetuO01d/aUPd5BnbLbIyK5of8xCQlXM6KH8bc+9 gQ7edR9mfLTdvBf2FR522hg8BRBM1imKc3vO8v39+qIHHRjuiwxBBCAOhHtHRsZX ripS0uFA07dM46Oi/E8osjx6fQt/lH5z/PN+2adxYSrLSAXfr1oD3RxYNhuWgyGF L64/VCQb1YGjf0Z5MBPnWm9jgUoOY5K9eNSS0L83WeJjlF5+Q/WOgB+rb49Prm2D Feo9+S9f2V53Llz1WIspXJg6f+n9lmHE94MfQj1GAHCzI0FeL19lvM+LhD8jJSCb hrC3+yobyy/AUOs5Z3E+njjX1FF/VCVAs6iOa6i+XG+Y1hh3ir2y1kckJ5auT10M SU8GEZu9ayU4M3o3N9yxOjaoP0NuQ4MMLL/n/u4u94AeZaHPNBXn/hVfVRRmpRXt GKvJtFAEppGEYezB+bLKIm6XlpPkhnwYzleLZ7AMEco2C6QM8QPB3g3JpS3sqRhA 5rEP4lL16BmijmF+CHoPE/zwgKZbKpyVDqvIW5IDgvfIC2X4pbZDRvGIUKaGSB4+ ksZgUUnNyvfQr2p7jokCMwQQAQgAHRYhBH4XCgRchM9GDit5oBDvedn9g1MSBQJb tySbAAoJEBDvedn9g1MSeKkQAJm44jt1kwHgQgeDBKdjdvl0AjE0xVEQxriZ6lP/ l//34YT0auFfzsYIrChSpQXAEtobBAr4Ohw1Us+BZe+H5P8vm6LRuPwozC3SjwfX 4Iec8+9ot6tIVg4sbedDSgb/CCFVjsmIGcQ1P73JLJTBJ6mxYCV/gn3QC6bwDOFo 7kD9FDHCjRN8XfhHQ4Q9cYyt06uF31qG/aumgWYC9geCGgAwiHgwxNYb9GoJ0iZj CROwbYvLTcQgsVUW2bTmsVR13UVKDsdl02sRV7qcVYW6R0a3Ra8KudX+nt25H5DR Gd382KZ5W8pydsy/viTvD9z6v0ulChBYxAedIvGIClrhbxlLEPmIg4ImVOLGqsUg Vm32J95WOjEkk4PEZ12xSDBtwhSJqmJNboWlfmw43KdIbY8zNhffIO3N6O7FsdGx mqyHeLoTpqY+ySVUPpbuyW8ujnI/J//+6hdTZ9dQsEJQlWngKuWOQ5ma58MPSN88 zllsqhZAFQjNxqnkSzL6ZQ+v/jvuRRe16B80AeO55DsmbWsMv/YLLD1mSi7+Khy2 EtMBhgojWwrGMvdLN6X3mnzNJEscYyLxM9tSk+iySP2sLthK0BVgpAzBSdaf/ezI z60P+neHDzteNFf8Mn7lmgYk1amvZoJ29s5+n2HwxyRL5dVMyMdyQmntubbctfqr Z0tIiQGcBBABCgAGBQJbxcflAAoJEGo7ETk8pK1gnCYMAJY4FeIYjlIXGghFWzsB 4fYwK1+iaFpU3fSto5qcrqVtVPjXpwqczqBWeXGyQxiB0kan4OVAXydIeaP8EAuF CA7paP3s9STLJBO3KurkwyRkPW5zo0X7xVqaVToRsX2Ul98KVJoHYQD1KdezEtwl vpNwiiBr42AYR751Vm6JBVAbQXuFpB3c8bUV0OkkRxNFtL8/2PieHar58n5dntGk bPlPkztahsFqktgacIgXHX5vaT+7YeeZ1DWLOYjGO0wNhkOSeroCmxwJUikU7joB p823L7r5KfpqWTPpSCzVstQKZUGmmoE1qCswY/Ud5wvp9SccpIILkRXj0rZRtfnE 5MpL3hjmtNzfDd9qIsJtBJlSB2hZwAsVm1l+EWN9hG3tqyA43niUMy2n6q690of3 berSiQ+kvY/aC9Hx8I+bKzOV9/J2VUTqfaPZa4Uy2rVX5Q2p69n/PMj7mEer0rCL 3j9V16J9c+s0BSkXoKdtYdB0TWVhBgUybd9qtYcwHWvhP7QuU3RlcGhlbiBGYXJy ZWxsIDxzdGVwaGVuQHRvbGVyYW50bmV0d29ya3MuY29tPokCPQQTAQgAJwUCWj1R WgIbAwUJCZQmAAULCQgHAgYVCAkKCwIEFgIDAQIeAQIXgAAKCRBasvrxexcr6jsc EADEcB0WQEZn2AkrzDs1RhL0Lp6cZi0BigofkbcGfdhJyMSs19C0dhvncrAFClVI 6/Udw3yFtDyYtOCf2W3M3A1K6/RfEizCLzTsdFIhni9gOJLlUpXViQtgrlstjk7h qVV3Ooz4BlCqS4cG7rfqf4LQQPpTAuFUEV9I28FBUB2irqC+v4gTysIgpMw0bA1y BU9sX5jE/tRkzqnuzZrkwiobDtRFJ9qp+7O2JtcY4EsVtLAsaodJKc5cF8R4OvB1 n66vxxcgg9Eh4JNWZ47xsaCmAGo1Bcb2jIY35OtgAL7gCGLRSMKTtAaPy1/fEgIq hCljJ9x40Fkn/3r2BX21WC9HFSPFTBz2RluLRzxdgxOrkYK8EiHUPoE5b1AEzZKw 2AbeXfr57f5zYsN3IqfbQLUjMYtUN1wK3Pjb+idD972wyXMWt8uOzlI7b9Ocu+nY m2whBfJv9Pmp3QYTmPz+LB9lH65VNVUSxSXVr5iWXO3qx1HtEiGEqkporMQCTh3T 5Ud3PvMSRBFFKNs9WhJ/Lxz+SV30WLwG6dr5mQqlzAhb4Phc/zekZyXRdS/oDKrB LUucS36O//49JeyRi1QvOfxnfmIqRIAf/k3PoYJmTo5E82//r5Qj3YGlRu78ba0H Arxs+ACD6AnEHHcbswpbtVEKYzlSu0Ar0Dc7vRWM/IyQdIkBHAQQAQgABgUCWj1S oAAKCRAvPIc2gF+NosIsB/9f/29FNla3BJfGIEIDnhrqGD0i9bSa89SqBd++uG06 TQgW5wsqtNcrwn81yZTq6XE6i9VtD4GKfqC0d4KZJr9bnbeD81cI64VOdL8zJWJs 0vj5EIXCobKyX74Kb4uePUyZqwT2Q74I116u/HwA9/FXsPo5isbh4ZqD4t0VHpWk mfq1FPT9a/JPyX46qKqB2Fce/7Qy+SQP1NfkuUlbhUH/JG9aSSYvk3lznNiH41x9 M+FDlL106itXOubrl3oi2fT3fsSedq7uzt+IV0DQEeNaoQAUuwEhdB8IWOMqN2wo DjGVKJftfsSWY9ilZrnDBNDrp0vRqcx33LUMkIw4d7iBiQIzBBABCAAdFiEEfhcK BFyEz0YOK3mgEO952f2DUxIFAlu3JJwACgkQEO952f2DUxJjuw/6ApHSsVTWD4a0 H6FJ23A9Ftpy+aXZ4vYlzkSrfsn2ECrEfK3lXQh/uzwjJUDYZeB1/BQsFZtcYNQO JSSHbQ49BFRLwb1J/wBZG4bbmrkLxnNbKDKQvzxEpclkMW0Dj0J6o7kGrmzIGGrh B+JJN99AcineHRug8ZSFIERRCmigxdhAKU0BFD7P+5HNHltSL3DF1c2fFOf2JrgB KVoE+9RhMZjWNbYetFFLCkjXb5Rpay9zeMm1DxfSTGAnuOwUXW6qq4hnl5+VC/48 ceDZElLLfu7RQUZv44pkSTOWZs+iQoJiHMFHk9wPqyB2Vok1yJ2a2j27WhXrJlPw nZbgJO5RyWDG3p/eVmpl5Uuc2dsfIpR17KnAuWpghK6V+cyFncDoGCl/YG2Mvool sW08FiZh3Ej4dnJjj25TZkeFG74JJDXLvMYpJfSBGnmETv4Dhcm2xPqVMuFuL1qJ lMbVLrMo2GXeo03OzNyvbs+u8WLIaGm5hC7N1CXY8wZs4jo6OJ/expvnc07dEuws 4zT3AiWv3nIouWReRStZy9QkavDocqbyPmilcdPCYk4BsOlzpwwO74hNG7iyl0Kd AlwTxGQ7y0rJou6HYa1TmRhIEr3vKvlW+JfUUrqtjXgsuacTXo4+Ira2JUErL2cY zQMq1j4r1ZyhFnuz93s7Rsx/Nw0+0YuJAZwEEAEKAAYFAlvFx+UACgkQajsROTyk rWCJqwv+NLVPE4sD4sDA2/6Ek7UsRIUkg+S39fhqWsLc4rtw/mDunv8Un61I3K04 fZ2Ry4nF9hZM0a710UvXFbStvrzRJO3EAAcdJR9LTCd19e8UeruQbIee3YT91U4N kC9JMpecfq62/teOAU2e5P3fWYaLs5ZX7zCLwWuBcW2l3SyoljQczM85HhJ3XHm+ FnwQ6D9xRle+lvWTcuC9d1yAyUb8IOospcL2lJTmy8e3r79R24hPlSB4LDe0wEN8 AXbagrcAQZjwyaHyWxjJbTwZ0b43WGdfIqZ1ElOeoffbketPGRmWvx5xUvb2ALFB BdETzV270gs5XDJgJ1SIIKOyDADxwvroTe2jD8C/841eEql5QSow3s/U3zRqk3mt tto8Qw/DN71aeh6dmYSsvd2UjsHw/vofOPRBGxZLEkKTEvMnhmMW9hiKPkPia+Qg evYE020qpKSxLEdWA8nprHwxmGiDNesCfXSC6vm1qfyj5g8HzxSckq9ZaMhKMCo7 vxflUEDuuQINBFo9UDIBEAD6DdHQfMav8OXfhjTteoarOrlJTSdci727xiezGPuB HmpvceBRZgRasdbaMc4HJee+R9+5x/nLPCuy/DxDyIjwIUeJNgc+l7LjI9WfpHTD 8U4xxjvR5Mi7+ToQQUOUNuzT0O0pyuxP1uY3RehHEhOVfBZO59ipSeZL5iQC6T5M sK1SKfs51pLa5ToC1rc8tBJ4zZmxRAyZiYc/AH2uZ/6rYjTTkAn1DVI9DYo2D/zE 4bGjXdJW5pKphFB2lX3dG4I7ODi+5e1H6A/QpCu6z8/ZkIQ+9T1xcX/YwiFeA7Pb TuW/eITbMbI1eV3+fyym9aT7Rsflmp31Zxtr+sZwGGZf00ooMBFmqOS//NUQ/Vf3 vDUew1h5QU1yDaWT3NApvi+XWPH9TPy6TMfZA2FThHf11sX/gDBa5JWQZbptPEcm oazpiKZt91CrFPOaoXDPck/Q61dfmr/oPikfByYnASIM3OwEuXqyQ9JDRfKrem5r +oA/wxWb5jELElAhOpnyqMMvOh7uz1foUssL8MAv2TGXmxpVJ8Nu4je6wf96Z22f Q0D38zud+CKH3bMP3ayXXJBcdPoENrzFbWP5FTg/4TTDJ3vOAHZR5iCunYghx8b7 Ffa4UbkwlD+dh8GiIAtvT51Ac0cO0Wc0Zjc57zPUz1zloMbf+zb1Bsn7DuEQoqj1 gwARAQABiQIlBBgBCAAPBQJaPVAyAhsMBQkJlCYAAAoJEFqy+vF7FyvqrC8P/1tF 6TeR83xD6MasqXyrBjwcLmziaF0Mlkj8k/YUiZ/knb53n97xQnh9yxPv0TT8Wpfd n3BmvqGyh8+ouHX9jMOxiRkMdNhIauVYY/8jmRfBSYWcFkfMzdYasvdLtmYJgx25 2HKTFdeOrszoOjWjEzwmh+tca3AFMu/nB++/KAmi5UJV7zsZ7uYJ5jm97LV5SLjN JIXXM+lHqCDrjDaDhNczmq1LCRlU6/WDjvkuwaVhZG4lXxMDrvKnXMkjseQ2oKjw rIdfQM86H1z5J31lfhqop+of0cimcIsBgSCPu+h96LHuAzeRBCbDKeqrfZtAZAGs okRina9947fRWxXHh3O66ILmXKNRxxWbDkPvYnQWUat8SbSTDoPWrDIGDRIAypqY o3pcN2OE0C1chqgDZQxkr+9kYZQpupOAN2TR+fM7JvbO9coKI8Uqog8CopoMeDQk d0YjcqlB1E0svODHTzcSoRzogDBYDqNLP7qVkNXpcOAXSVioBgiSDf7o5RdS/qmU yXBIeq6I5z8xBcd+BQ/n/9Frkm6K7IKP3ngUP4wEoiPx5ZE5+fPIScGmVUcZIMhk vMvem9XXh1yyhqN14gfjmLwPGdWbrgG8QUe0s2WeWIyss6uTiyF+ZbJSo2XOKVc3 YFMVUUfgyudqAV1wWdZinUk+H3pkqOKoHAy/8fST =3DYzQY -----END PGP PUBLIC KEY BLOCK----- --------------FB49F5CDC80E63959B2389BC-- --7vMLCMq3Du1c7trv13oeiwmsXQvJdd8Re-- --fK3fMVcTsN0Wo5DC8KyyfL2IbqEOuj7Ch Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEW7Wm6ldl0sWGPK4nWrL68XsXK+oFAl7etCYACgkQWrL68XsX K+pEQA//eWPlUkJ5hzyoFvX8kkG8WuP+ZGcI1EOJm5aI5bbrfyxJNcJyqijJhJ5r hC0dYEKDgCgVZZjIZdqM2HSbIkT16idmRsR5Isv1mrgXYSPG5FlbTpx15d28x2wX MKCxTWCe1VHmLcFw57aQf1mOpzRdehQlNprlEaxOY+vD8Z71F+kyTilaL7+6YiPn pvBYGBWk8iRqfAK2Qi5bUCIE+a/eDngoJXp6VwTn939r9iHIDCsaALacTYBff5ys /Yh5gIzH59MEBcrZ7TULCgOGmxq8Gs5zM7iIdmeExAb8HUCy7LF3xpOeC5JwunAc skEKOlHoEzPWxVqSqazFBjJJJWZQyAof8kO7NqD1RGE6AzlxWhw3W8JiS5tpp96T Ss0MJr8PIBKO2huRvwPJxsf59DQU9tKN+Xjoz++rXBVhO8CvjnnF1pPrghZ9o2nB dn+ETPl8JWHEcFF128YdoGwpwhFD2Ed/8SRceZL8XrqMuJNEVj3EeLpudoiOre63 UBKHArkvG/eRCCbJ3U4sn8rXoiohDEN3vqVoN3N5vGc+iTSdxQ9dt7FqnAs32niq i2bjyGEjinfLDjqgerZ5Kda4hMlE/Xi9sXzkGMBANGoSxmtTL/R2nkN4OxQ1/p8p bAuA79JdBXMOCjXFebGDrbuvJVVHrzKRNP+5q29WGA4xJRyjCBo= =GkrN -----END PGP SIGNATURE----- --fK3fMVcTsN0Wo5DC8KyyfL2IbqEOuj7Ch-- From nobody Tue Jun 9 04:02:49 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C56AD3A03F2 for ; Tue, 9 Jun 2020 04:02:47 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lepidum-co-jp.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RcliOTfzZfr9 for ; Tue, 9 Jun 2020 04:02:45 -0700 (PDT) Received: from mail-lf1-x135.google.com (mail-lf1-x135.google.com [IPv6:2a00:1450:4864:20::135]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 408A43A02BE for ; Tue, 9 Jun 2020 04:02:45 -0700 (PDT) Received: by mail-lf1-x135.google.com with SMTP id x27so12178156lfg.9 for ; Tue, 09 Jun 2020 04:02:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lepidum-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=io+Ki0ospLQ72Iwo+8BrD5MSfoLaiRla3a+b6hJEN7w=; b=fH1inPWvMYlf+zQfPtpfD2gpu61n2rphIU+hTvzP60DZ9zaR/L81/fV1SM8SI+fXcU nIFbhoY5gWUSBhUxBckRuiUswilLtgGKzczt1/Vv2o9eMAmQEXCLZPDmh5Nxg7pAl64i S6Yvo4t2O167BLlwkGsxp3ewsxO36fbsdZv9Seuea9kwMcgQZjyba29z8rTQRWNcaAo+ vliQlEc6JI4TRpUpE5DCAJWe5YrpOuRZdZt8vzMkxFDWUHOR3kx3KBMV4FWxFM87et9y pfnMeaoCNnjF9O2YcB6evVdUKG2ln/gn3iTUOTi/ymKy6kN5x6UL1KUjvHP4VCMOQ7wy nrAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=io+Ki0ospLQ72Iwo+8BrD5MSfoLaiRla3a+b6hJEN7w=; b=tI6T4iyZJB//Ms9rMli5FT9DVxvtVqXU8uhRIzZl6oHu6GIZX13c3lFCUV4kVTcM31 gp4nOxt9vRgn35AKecs9/4SjlXNaHK/tSN3snQwlKQvyf+nk++OKoaUPSyNLWaDlfaSL 91JVay/+T4SeckIMFS0YUM3sjCPDLjFsXRc1R1817zfjKNq0/glvhB3NFWVAKx27CCfm T3s+YwghuaynFviw2atYbsWMEN1jC5+Wk3IVrGU2qqeCYLgU0mmMojykI/mMyNktxouk rJ88DLn6wiBeb6bPdSYTbek0kpYKeOIrWI51FYM1qYYVUS5b+3ihPU0x1B6bgPUbYQn9 0msA== X-Gm-Message-State: AOAM531HEMiZXyLFKdZtr+ee61G0wE2pHArPPzJjQEdGpA1Vb9t8WVdd OL42OgOxVEZJaLolsRbbhVq+tO+qqSPjXeEM6Xg4Ag== X-Google-Smtp-Source: ABdhPJydvzmHoeKEnPH6dVk6zKOPwke1GcoZ42ovIK7xys3bDu1FFg/P3r4JkKzSGke5s2dQ65I8FFtS4OFcwOa3qhA= X-Received: by 2002:ac2:44c1:: with SMTP id d1mr15152261lfm.37.1591700561642; Tue, 09 Jun 2020 04:02:41 -0700 (PDT) MIME-Version: 1.0 References: <002201d61c30$4f561da0$ee0258e0$@hco.ntt.co.jp_1> In-Reply-To: From: Yumi Sakemi Date: Tue, 9 Jun 2020 20:02:30 +0900 Message-ID: To: Chloe Martindale Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org, Tetsutaro Kobayashi , SAITO Tsunekazu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-pairing-friendly-curves-03 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 11:02:48 -0000 Dear Chloe Thank you for your e-mail. We are very glad to reach a rough consensus with you. We believe that our draft became very readable and higher quality by reflecting your comments. We appreciate your valuable and constructive comments. We'd like to express our gratitude and include your name in Acknowledgement= . The version 05 that is reflected your comments will be submitted today or tomorrow, then we will contact you again. Best regards, Yumi 2020=E5=B9=B46=E6=9C=881=E6=97=A5(=E6=9C=88) 18:53 Chloe Martindale : > > Dear Yumi, dear all, > > thank you for the update and for involving me in your thought process reg= arding the curve choices. I understand and agree with your reasoning (and a= pproach) regarding including both BLS12-381 and BN462, however I think I wo= uld make a different 'safer choice'. > > My reason is this: if the attack is improved further (which you are compl= etely right, it may), it is very likely to have a bigger impact on curves c= onstructed via polynomial methods with embedding degree 8 (such as BN462) t= han on any other curves for this security level, so it's not unlikely that = the security of BN462 would be pushed below 128 bits. A safer choice in my = view would be to take the Cocks-Pinch curve (not constructed using polynomi= al methods) defined using a 544-bit prime implemented in RELIC, from [GMT19= ]*. The TNFS attacks cannot be applied to Cocks-Pinch curves (at least not = without a fundamental new attack idea, since they rely on the polynomial co= nstruction), so small improvements will not decrease the security level at = all, and this curve is actually still more efficient than BN462 so there's = nothing to lose there. I appreciate that such a choice would mean also incl= uding some background on Cocks-Pinch and a reference/short explanation of t= he fact that TNFS attacks don't apply to these, which would be a major chan= ge to the original document, so I appreciate it if you'd rather not do this= , but just thought I'd suggest it as I think it would increase the lifetime= of your document. > > *In your draft this is [GME19], but it should be [GMT19], and can now be = updated to the peer-reviewed version of course (this is the paper I pointed= out in my review). > > All the best, > Chloe > > On Fri, 29 May 2020 at 16:21, Yumi Sakemi wro= te: >> >> Dear Chloe >> >> We appreciate a lot of constructive comments received at Expert Review. >> >> We are currently working on updating our draft. >> Last week, Nick created a repository for pairing-friendly curves on >> CFRG's official GitHub, so we plan to update our draft using the issue >> tracker. >> The updating for your comments will be made available to you on the >> following issue page. >> >> https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/issues >> >> We will contact you again when all the comments have been updated. >> In that case, we would be glad if you could check them. >> >> In addition, before updating, there is a comment that we would like to >> inform you about the policy of update. >> The comment is about the recommended curve for 128-bit security level. >> >> First of all, thank you for teaching us a peer-reviewed paper for BLS12-= 381. >> The comment is about the recommended curve for 128-bit security level. >> Due to our lack of investigation, we made the wrong decision that >> BLS12-381 was not matched in our selection policy. >> >> Your comment pointed out that BLS12-381 is moved to the recommended >> curve and BN462 is moved to the Appendix. >> We understood the disadvantages of BN462 that you were concerned >> about, but we would like to recommend both BLS12-381 and BN462. >> The reason is as follows. >> >> CFRG aims to standardize cryptographic technology for future Internet us= e. >> We agree that BLS12-381 with a 126-bit security level is the best >> match as a curve of 128-bit security level "at this time" from the >> viewpoint of security and efficiency. >> On the other hand, the security of BLS12-381 is already less than >> 128bit, so from the viewpoint of future use, if the attack is improved >> even a little, it will not be suitable for a curve of 128-bit security >> level. >> Considering that the curve of 128-bit security level is often used at cu= rrent. >> So, we would like to recommend both BLS12-381 and BN462 considering >> the future use and the safety side. >> >> However, as you pointed out, BN462 has the disadvantage of being too >> slow compared to BLS12-381. >> Then, the reader will be confused if there are two parameters of >> 128-bit security level, so we will add the basis for selection by >> adding the explanation of merits and demerits for each parameter. >> And, we will also add a description about the disadvantages of BN462 >> regarding efficiency. >> >> If you have any problems with the updating policy, we would like you to = comment. >> >> Best regards, >> Yumi >> >> >> >> >> >> >> 2020=E5=B9=B44=E6=9C=8827=E6=97=A5(=E6=9C=88) 21:58 Yumi Sakemi : >> > >> > Dear Chloe >> > >> > I appreciate your review. >> > I'm very glad to receive many constructive comments! >> > I will discuss about your comments with co-authors and revise our >> > draft to reflect your comments in our draft. >> > I think it will be a better draft by reflecting your comments. >> > >> > As co-author Tsunekazu e-mailed, we're planning to submit version 04, >> > because we were independently working on updating of abstract, >> > introduction (sec. 1.3) and proofreading of English in parallel with >> > the expert review. >> > (Version 04 will not be reflected your comments.) >> > >> > Comments from Chloe will be reflected in the version 05. >> > We will submit version 05 in mid-May and we will report you when we >> > submit version 05. >> > >> > Dear Stanislav >> > >> > Thank you very much for proceeding to the Expert review. >> > We received a lot of constructive comments from Chloe, so I think it >> > is difficult to manage comments by email. >> > (Because there are over 100 comments from Chloe.) >> > >> > Therefore, I would like to use the issue management function of GitHub >> > so that it is easy to check the reflecting status of Chloe's comments. >> > So, I'd like to use the repository of pairing-friendly curves draft on >> > CFRG's GitHub >> > because BLS signature which is similar in terms of IRTF stream is also >> > registered on the GitHub. >> > Could you register the repository for the draft of pairing-friendly >> > curves on the following CFRG's GitHub? >> > >> > https://github.com/cfrg >> > >> > Best regards, >> > Yumi >> > >> > 2020=E5=B9=B44=E6=9C=8827=E6=97=A5(=E6=9C=88) 10:09 SAITO Tsunekazu : >> > > >> > > Dear Chloe, Stanislav, >> > > >> > > >> > > >> > > This is Tsunekazu. >> > > >> > > >> > > >> > > We plan to update the draft to version 04 soon. >> > > >> > > As the contents of the update, we changed the wording of Section 1.3= and security consideration. >> > > >> > > Yumi will submit the 4th edition, so please wait a moment. >> > > >> > > >> > > >> > > Best regards, >> > > >> > > Tsunekazu >> > > >> > > >> > > >> > > From: Stanislav V. Smyshlyaev >> > > Sent: Sunday, April 26, 2020 2:30 PM >> > > To: Chloe Martindale ; SAITO Tsunekazu ; Tetsutaro Kobayashi ; Yumi Sakemi >> > > Cc: cfrg-chairs@ietf.org; crypto-panel@irtf.org >> > > Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-pair= ing-friendly-curves-03 >> > > >> > > >> > > >> > > Dear Chloe, >> > > >> > > Many thanks for your review (such a great and a prompt one!). >> > > >> > > >> > > >> > > Dear Yumi, Saito, Tetsutaro, do you plan to update your draft taking= into account Chloe=E2=80=99s review? >> > > >> > > >> > > >> > > Best regards, >> > > >> > > Stanislav >> > > >> > > >> > > >> > > =D0=BF=D1=82, 24 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 19:49, Chlo= e Martindale : >> > > >> > > Hi all, >> > > >> > > >> > > >> > > review is attached. >> > > >> > > >> > > >> > > All the best, >> > > >> > > Chloe >> > > >> > > >> > > >> > > On Tue, 21 Apr 2020 at 18:05, Stanislav V. Smyshlyaev wrote: >> > > >> > > Sure - it is >> > > >> > > https://tools.ietf.org/html/draft-irtf-cfrg-pairing-friendly-curves-= 03 >> > > >> > > >> > > >> > > Thank you again! >> > > >> > > >> > > >> > > Regards, >> > > >> > > Stanislav >> > > >> > > >> > > >> > > =D0=B2=D1=82, 21 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 19:10, Chlo= e Martindale : >> > > >> > > Just to be sure, can you point me towards the most recent version of= the draft please? >> > > >> > > >> > > >> > > Thanks, >> > > >> > > Chloe >> > > >> > > >> > > >> > > On Tue, 21 Apr 2020 at 13:17, Stanislav V. Smyshlyaev wrote: >> > > >> > > Great, many thanks, Chloe! >> > > >> > > >> > > >> > > Kind regards, >> > > >> > > Nick, Alexey, Stanislav >> > > >> > > >> > > >> > > On Tue, 21 Apr 2020 at 15:16, Chloe Martindale wrote: >> > > >> > > I'll take a look this week. >> > > >> > > >> > > >> > > All the best, >> > > >> > > Chloe >> > > >> > > >> > > >> > > On Tue, 21 Apr 2020, 13:10 Stanislav V. Smyshlyaev, wrote: >> > > >> > > Dear Crypto Panel members, >> > > >> > > >> > > >> > > The authors of the Pairing-Friendly Curves draft have addressed the = concerns raised during the discussion and are ready to move to the next sta= ge with the draft. >> > > >> > > >> > > >> > > Alexey, Nick and I would like to ask Crypto Review Panel members abo= ut the review(s) of draft-irtf-cfrg-pairing-friendly-curves-03. >> > > >> > > >> > > >> > > This memo introduces pairing-friendly curves used for constructing p= airing-based cryptography. It describes recommended parameters for each sec= urity level and recent implementations of pairing-friendly curves. >> > > >> > > >> > > >> > > >> > > >> > > Can we have any volunteers, please?.. >> > > >> > > >> > > >> > > >> > > >> > > Best regards, >> > > >> > > Stanislav (on behalf of chairs) >> > > >> > > _______________________________________________ >> > > Crypto-panel mailing list >> > > Crypto-panel@irtf.org >> > > https://www.irtf.org/mailman/listinfo/crypto-panel >> > >> > >> > >> > -- >> > Yumi Sakemi, Ph. D. >> > Lepidum Co. Ltd. >> > E-Mail: yumi.sakemi@lepidum.co.jp >> >> >> >> -- >> Yumi Sakemi, Ph. D. >> Lepidum Co. Ltd. >> >> E-Mail: yumi.sakemi@lepidum.co.jp --=20 Yumi Sakemi Lepidum Co. Ltd. E-Mail: yumi.sakemi@lepidum.co.jp From nobody Tue Jun 9 15:44:06 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 653023A09AF for ; Tue, 9 Jun 2020 15:44:05 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=nccgroup.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wYd3XOXRYAV1 for ; Tue, 9 Jun 2020 15:44:03 -0700 (PDT) Received: from eu-smtp-delivery-170.mimecast.com (eu-smtp-delivery-170.mimecast.com [207.82.80.170]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C9E963A08CA for ; Tue, 9 Jun 2020 15:44:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nccgroup.com; s=mimecastnccgroupcom; t=1591742641; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=DURNoOONM8hrLazTQVsYsfuzridobIAuyRs7008tFU0=; b=StrH3ktqCkj3PkY0a3hD49YZTNryzt+UlOQbJBk+Hc6XP3LfQI2YjlpbzrEdcuy8qilrG7 3yMYXK7e0vOCYTFvvBmTPYh2BN16k8TtdY6NU7o0dk3/TwOhFyrF696uhA9D9VTgorYxaT 19cc0Fk4cSxNYJOKuJnAYxtpK9fuWckRoh8VQA8mYUxzEwvYpVhVDkVucmE1d5cqlo+MTQ MFmD7Cx18+Jrmwaldt+VThW/UYbRgxltsJDfSsnwupoCgPkZOmOZR+YcCKpPwS0/zWyTc8 k5kmumfseL0RHH5paJvflI4HvC9MldIvwdyjvwDZWrVvlgpvoeZiaTWcuvj4oQ== Received: from GBR01-LO2-obe.outbound.protection.outlook.com (mail-lo2gbr01lp2051.outbound.protection.outlook.com [104.47.21.51]) (Using TLS) by relay.mimecast.com with ESMTP id uk-mta-49-j8u9dQnnPAqHOjsHj3LKEg-1; Tue, 09 Jun 2020 23:42:38 +0100 X-MC-Unique: j8u9dQnnPAqHOjsHj3LKEg-1 Received: from CWXP265MB0694.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:2::19) by CWXP265MB0981.GBRP265.PROD.OUTLOOK.COM (2603:10a6:401:3a::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3066.18; Tue, 9 Jun 2020 22:42:37 +0000 Received: from CWXP265MB0694.GBRP265.PROD.OUTLOOK.COM ([fe80::b478:5f5f:3792:e39a]) by CWXP265MB0694.GBRP265.PROD.OUTLOOK.COM ([fe80::b478:5f5f:3792:e39a%4]) with mapi id 15.20.3088.018; Tue, 9 Jun 2020 22:42:37 +0000 From: Thomas Pornin To: "Stanislav V. Smyshlyaev" CC: "crypto-panel@irtf.org" , "draft-irtf-cfrg-hash-to-curve.authors@ietf.org" , "cfrg-chairs@ietf.org" Thread-Topic: [Crypto-panel] EXTERNAL: Request for review: draft-irtf-cfrg-hash-to-curve-08 Thread-Index: AQHWOzJqrZvbjO6e90y88t8BB23yvqjQpRaA Date: Tue, 9 Jun 2020 22:42:36 +0000 Message-ID: References: <27FC2D65-658D-4E21-8484-E95927CCA1BF@nccgroup.com> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [24.200.215.113] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 81c39620-a320-49d6-afd5-08d80cc6688e x-ms-traffictypediagnostic: CWXP265MB0981: x-microsoft-antispam-prvs: route: R_Mimecast campaign: C_Default signature: S_NoSignature disclaimer: D_NoDisclaimer x-ms-oob-tlc-oobclassifiers: OLM:6790; x-forefront-prvs: 042957ACD7 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: /VU8GvzNsHM/0WjiMNCZky16VDfq2V4o8HgCnwACsfKqosaqFb1X/m3vhm2FC/U8Q/2yNCmI5KIZwkl+9RRJ608hUnuDBVZrerLHmrS9oB3rxTMxEybMOLRbkMMSnrj+BBNUlvVlkQ+7Lpv7m90NhOsxQ1zdb04tCiLwElO3yeMV2XJ0MdKAeMyzCacH2YE39HKA9nMrpps+TthyBEuWZ6cJ5bZhPoFfA5ooFi5G1jKc9qIAnHKv2q/WIQnkCuNbliF4G43VJCQetbGD4KTMaggq3quo23MG28FYVskzofW/cZ7pRi+6R6J5aXYKR2BqZEKvKju81Y9ui8APIdoT47egKn/0LDQFHYjZ/M4ESHweZudVj11QgGiI/Kil/U6MuhjniQOzmx8oybnsTWQ3Qg== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CWXP265MB0694.GBRP265.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(376002)(346002)(39840400004)(396003)(136003)(366004)(8936002)(2616005)(91956017)(33656002)(66556008)(76116006)(2906002)(6512007)(64756008)(36756003)(66446008)(53546011)(44832011)(316002)(66476007)(66574014)(54906003)(6486002)(8676002)(6506007)(4326008)(30864003)(966005)(66946007)(6916009)(83380400001)(26005)(71200400001)(45080400002)(186003)(86362001)(5660300002)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: u0KHChYm8hE2l7nYAWjnqQDRpvQD+dkq8DSVkCARuvFIhi9a42WbAGHK+UU/jhQU6X7G7aV+aZHMj2EEQtmFZhm9ysjsYtMrtuSyRU/HjOtxWJ8U3z6cZzp5Oj4JGLZeQe4TrPlL2NA0s2cxrNaRI50GzBuaiBu5KHjg23AsPCmog7N5yEtKxRZPUfMGf+AvGE+Snx6ij8QJGztPG28ycvubAhFCQJ1jk82NzhFmWIIA4LPr8VOHzMBqAA8mPwyCvKGMdUVm3pQ5nXp2eUq6gQEyNbPmvDScYbLuc4vQ9WzAZkuFEhFHVXqtLic+u4l7755H9n0ykuJQkDDhBmp2cyMDEmDdPD6nblayRHtpfwhYXynxlLkcTsV77J50DGDxw+H/N/3Km+op9LJxu7ygiztbpbEUrhceCCoLtLRcuF81W/Vq0CC/elOZ6pxTgH9BEbcKAuzqXtkW2VYSLxSP09a67eYD6T6/zxYTkGuKyNKaE5CGLvyoNuhPtrBsJXtH x-ms-exchange-transport-forked: True Content-ID: <0F5180B6CB80F345A66E9DFE229A88C7@GBRP265.PROD.OUTLOOK.COM> MIME-Version: 1.0 X-OriginatorOrg: nccgroup.com X-MS-Exchange-CrossTenant-Network-Message-Id: 81c39620-a320-49d6-afd5-08d80cc6688e X-MS-Exchange-CrossTenant-originalarrivaltime: 09 Jun 2020 22:42:36.7985 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: a41111be-486b-45f6-8bd0-ee01a62f368e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: +WdjDDAtaNJ6qW3WmMI0RH0c9AvlglYQ77CdOYVLgRFAw6CtEuAglSlejF5+JYLVbDtaf6q4hnwrLfxuNKOZ1CtzfGhgDeeLHQrvaLLrYOA= X-MS-Exchange-Transport-CrossTenantHeadersStamped: CWXP265MB0981 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: nccgroup.com Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: base64 Archived-At: Subject: Re: [Crypto-panel] EXTERNAL: Request for review: draft-irtf-cfrg-hash-to-curve-08 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Jun 2020 22:44:05 -0000 SGVyZSBpcyBteSByZXZpZXcuDQoNCkhhc2hpbmcgdG8gRWxsaXB0aWMgQ3VydmVzDQpkcmFmdC1p cnRmLWNmcmctaGFzaC10by1jdXJ2ZS0wOA0KDQpUaGlzIGRyYWZ0IGlzIHdlbGwtd3JpdHRlbi4g SSBoYXZlIG5vdCB2ZXJpZmllZCB0aGF0IGFsbCBwc2V1ZG9jb2RlDQphbmQgYWxsIHRlc3QgdmVj dG9ycyBhcmUgY29ycmVjdCwgYnV0IEkgZGlkIG5vdCBzZWUgYW55dGhpbmcgb2J2aW91c2x5DQp3 cm9uZy4gQWxsIHByb3Bvc2VkIGNvbnN0cnVjdGlvbnMgbWFrZSBzZW5zZSB0byBtZSwgZnJvbSBh IGNyeXB0b2dyYXBoaWMNCnBvaW50IG9mIHZpZXcuDQooSSBjYW4gcmVpbXBsZW1lbnQgc3R1ZmYg aW4gU2FnZSBhbmQgY2hlY2sgdGhlIHJlc3VsdHMsIGJ1dCBpdCB3aWxsIHRha2UNCm1lIG1vcmUg dGltZSwgYW5kIEkgZG9uJ3QgaGF2ZSBhIGxvdCBvZiBpdCBhdCB0aGUgbW9tZW50LikNCg0KQSBn ZW5lcmljIHJlbWFyazogdGhlcmUgaXMgbm90IGEgd29yZCBhYm91dCBpbnRlbGxlY3R1YWwgcHJv cGVydHkNCmlzc3Vlcy4gSSB1bmRlcnN0YW5kIHRoYXQgdGhpcyBpcyBhIGNvbnRlbnRpb3VzIGlz c3VlLCBhbmQgdGhhdCBub2JvZHkNCndhbnRzIHRvIGFzc2VydCB0aGF0IGFueSBzcGVjaWZpYyBt ZXRob2QgaXMgcGF0ZW50LWZyZWUuIEJ1dCBJIHdvdWxkDQpoYXZlIGV4cGVjdGVkIGEgZGlzY2xh aW1lciBzb21ld2hlcmUuIE90aGVyd2lzZSwgaXQgZmVlbHMgd2VpcmQgdGhhdA0KSWNhcnQncyBt YXAgaXMgbm90IHVzZWQgYXMgYSBwb3NzaWJsZSBtZXRob2QsIHNpbmNlLCB3aGVuIHBebSA9IDIg bW9kIDMsDQppdCBzaG91bGQgYmUgZmFzdGVyIHRoYW4gdGhlIHNpbXBsaWZpZWQgU1dVIChpdCB1 c2VzIG9uZSBpbnZlcnNpb24NCmFuZCBvbmUgY3ViZSByb290LCBubyBleHRyYSBpc19zcXVhcmUo KSBvciBzaW1pbGFyKS4NCihBbHNvLCBJIGhlYXJkIHNvbWUgcnVtb3VycyB0aGF0IHNpbXBsaWZp ZWQgU1dVIGlzIGFsc28gcGF0ZW50ZWQsDQphbGJlaXQgd2l0aCBhIGxlc3MgcHJvYWN0aXZlbHkg ZW5mb3JjZWQgcGF0ZW50LiBUaGUgc2FtZSBydW1vdXJzIHNheQ0KdGhhdCB0aGUgb3JpZ2luYWwg U2hhbGx1ZS12YW4gZGUgV29lc3Rpam5lIG1ldGhvZCBpcyBwYXRlbnQtZnJlZS4gVGhlc2UNCmFy ZSBvbmx5IHJ1bW91cnMuKQ0KDQpTb21lIG90aGVyIHJlbWFya3MsIGluIGFwcGVhcmFuY2Ugb3Jk ZXI6DQoNCjIuMSAocGFnZSA2KTogTWF5YmUgbm90ZSB0aGF0IHRoZXJlIGFyZSBtdWx0aXBsZSBj aG9pY2VzIGZvciB0aGUNCnJlcHJlc2VudGF0aW9uIG9mIEdGKHBebSkgYXMgcG9seW5vbWlhbHM6 IGFueSBpcnJlZHVjaWJsZSBtb2R1bHVzIE0gKG9mDQpkZWdyZWUgbSkgaXMgZmluZSAoYWxsIGZp bml0ZSBmaWVsZHMgd2l0aCB0aGUgc2FtZSBjYXJkaW5hbCBhcmUNCmlzb21vcnBoaWMgdG8gZWFj aCBvdGhlciksIGJ1dCBubyBNIGlzIG1vcmUgY2Fub25pY2FsIHRoYW4gYW55IG90aGVyLg0KQ2hv aWNlIG9mIE0gaXMgb2Z0ZW4gZHJpdmVuIGJ5IGltcGxlbWVudGF0aW9uIHBlcmZvcm1hbmNlIChz b21lIE0gbGVhZA0KdG8gZmFzdGVyIGNvZGUpLg0KDQoyLjEgKHBhZ2UgNik6ICJlbGVtZW50cyBh cmUgdGhvc2UgcG9pbnRzIHdpdGggY29vcmRpbmF0ZXMgKHgsIHkpDQpzYXRpc2Z5aW5nIHRoZSBj dXJ2ZSBlcXVhdGlvbiI6IHNvbWUgY3VydmVzIChpbiBwYXJ0aWN1bGFyIFdlaWVyc3RyYcOfDQph bmQgTW9udGdvbWVyeSBjdXJ2ZXMpIGFsc28gaW5jbHVkZSBhIHNwZWNpYWwgcG9pbnQtYXQtaW5m aW5pdHkgd2hpY2gNCmRvZXMgbm90IGhhdmUgY29vcmRpbmF0ZXMgKHgsIHkpLg0KDQoyLjIuMiAo cGFnZSA4KTogIlNlY3Rpb24gMTAgZGlzY3Vzc2VzIGZ1cnRoZXIuIiAtPiBUaGlzIGxhY2tzIGEN CmNvbXBsZW1lbnQuIE1heWJlOiAiU2VlIHNlY3Rpb24gMTAgZm9yIGZ1cnRoZXIgZGlzY3Vzc2lv bi4iPw0KDQoyLjIuNSAocGFnZSA5KTogQ29uY2F0ZW5hdGlvbiBjYW4gYmUgYW1iaWd1b3VzLCBp LmUuDQogICAiUk8xMCIgfHwgeCA9PSAiUk8xIiB8fCAoIjAiIHx8IHgpDQpUaGUgYWN0dWFsIHVz YWdlIChpbiBzZWN0aW9uIDUuMykgdXNlcyBleHBsaWNpdCBsZW5ndGggYnl0ZXMsIGFuZA0KYWxz byBwdXRzIHRoZSB0YWcgX2FmdGVyXyB0aGUgbWVzc2FnZSwgbm90IGJlZm9yZS4gSXQgbWlnaHQg YmUgd29ydGgNCm1lbnRpb25pbmcgaGVyZSB0aGF0IHRoZSAiY29uY2F0ZW5hdGlvbiIgb3BlcmF0 aW9uIG11c3QgYmUgYW4NCmluamVjdGl2ZSBlbmNvZGluZyBvZiB0aGUgdGFnIGFuZCBpbnB1dCB4 LCB3aXRoIGEgZm9yd2FyZCByZWZlcmVuY2UNCnRvIHNlY3Rpb24gNS4zIGZvciBkZXRhaWxzIChl c3BlY2lhbGx5IDUuMy40KS4NCg0KMy4xIChwYWdlIDEyKTogVGhlIHRleHQgZmx1aWRseSBhbmQg aW1wbGljaXRseSBlcXVhdGVzIGNoYXJhY3RlciBzdHJpbmdzDQphbmQgYnl0ZSBzdHJpbmdzLiBK YXZhIGFuZCBDIy8uTkVUIGRldmVsb3BlcnMgbWlnaHQgdGFrZSBpc3N1ZSB3aXRoDQp0aGF0LiBU aGlzIG1pZ2h0IGJlIHdvcnRoIGFuIGV4cGxpY2l0IHNlbnRlbmNlIGhlcmU7IG90aGVyd2lzZSwg c29tZQ0KZGV2ZWxvcGVyIHNvbWV3aGVyZSB3aWxsIHVzZSBVVEYtMTYgKGFuZCBjYWxsaW5nIGl0 ICJVbmljb2RlIiBpbiBwdXJlDQpNaWNyb3NvZnQgZmFzaGlvbiksIG90aGVycyB3aWxsIGFkZCBh IHRlcm1pbmF0aW5nIHplcm8sIG9yIHVzZQ0KYmlnLWVuZGlhbiwgb3IgYWRkIGEgQk9NLCBvciBh bnkgY29tYmluYXRpb24gdGhlcmVvZiwgYW5kIG11Y2ggY29uZnVzaW9uDQphbmQgaW50ZXJvcGVy YWJpbGl0eSBzb3Jyb3cgd2lsbCBlbnN1ZS4NCg0KNCAocGFnZSAxMik6ICJTSE9VTEQgYmUgY29u c3RhbnQgdGltZSIgLT4gIlNIT1VMRCBiZSBjb25zdGFudC10aW1lIi4NCg0KQWxzbywgdGhlIHRy YWRpdGlvbmFsIGFjY2VwdGlvbiBvZiAiY29uc3RhbnQtdGltZSIgY292ZXJzIG1vcmUgdGhhbg0K aW5kZXBlbmRlbmNlIG9mIHRoZSBleGVjdXRpb24gdGltZSB3aXRoIHJlZ2FyZCB0byB0aGUgaW5w dXQgdmFsdWVzOg0KDQogIC0gSXQgcmVhbGx5IGlzIGluZGVwZW5kZW5jZSB3aXRoIHJlZ2FyZCB0 byBhbGwgc2VjcmV0IHZhbHVlcywgaW5jbHVkaW5nDQogICAgaW50ZXJtZWRpYXRlIHZhbHVlcyBh bmQgb3V0cHV0cywgbm90IGp1c3QgaW5wdXRzLg0KDQogIC0gQ29uc3RhbnQtdGltZSBjb2RlIHNo b3VsZCBub3QgbGVhdmUgYW55IHRyYWNlIHRoYXQgY2FuIGJlIGxldmVyYWdlZA0KICAgIHdpdGgg dGltZS1iYXNlZCBtZWFzdXJlbWVudHMuIEZvciBpbnN0YW5jZSwgaW4gYSBmbHVzaCtyZWxvYWQN CiAgICBhdHRhY2ssIHRoZSB2aWN0aW0ncyBleGVjdXRpb24gdGltZSBpcyBpbmRlcGVuZGVudCBv ZiB0aGUgc2VjcmV0DQogICAgdmFsdWVzOyB0aGUgdGltaW5nIG1lYXN1cmVtZW50IGlzIG9uIGEg cmVsb2FkIG9wZXJhdGlvbiBwZXJmb3JtZWQgYnkNCiAgICB0aGUgYXR0YWNrZXIgdGhlbXNlbHZl cywgX2FmdGVyXyB0aGUgdmljdGltIGhhcyBmaW5pc2hlZC4gQ29kZSB3aGljaA0KICAgIGlzIHZ1 bG5lcmFibGUgdG8gYSBmbHVzaCtyZWxvYWQgYXR0YWNrIG1heSBzdGlsbCBiZSAiY29uc3RhbnQt dGltZSINCiAgICBpbiB0aGUgc2Vuc2UgZGVzY3JpYmVkIGJ5IHNlY3Rpb24gNCwgYnV0IHdvdWxk IG5vdCBiZQ0KICAgICJjb25zdGFudC10aW1lIiBpbiB0aGUgdXN1YWwgc2Vuc2UuDQoNCkkgdGhp bmsgYSBtb3JlIGdlbmVyaWMgZGVmaW5pdGlvbiBvZiAiY29uc3RhbnQtdGltZSIgaXMgbmVlZGVk IGhlcmUuIEkNCnN1Z2dlc3QgdGhlIGZvbGxvd2luZzogIkZvciBzZWN1cml0eSwgaW1wbGVtZW50 YXRpb25zIG9mIHRoZXNlIGZ1bmN0aW9ucw0KU0hPVUxEIGJlIGNvbnN0YW50LXRpbWUsIGkuZS4g bm9uZSBvZiB0aGUgcG9zc2libGUgdGltaW5nIG1lYXN1cmVtZW50cw0KdGhhdCBjYW4gYmUgZWZm ZWN0ZWQgYnkgYW4gYWR2ZXJzYXJ5IHNob3VsZCBkZXBlbmQgb24gc2VjcmV0IHZhbHVlcy4gSW4N CnBhcnRpY3VsYXIsIGV4ZWN1dGlvbiB0aW1lIGJ1dCBhbHNvIG1lbW9yeSBhY2Nlc3MgcGF0dGVy bnMgc2hvdWxkIGJlDQppbmRlcGVuZGVudCBvZiBhbnkgc2VjcmV0IGlucHV0LCBvdXRwdXQgb3Ig aW50ZXJtZWRpYXRlIHZhbHVlLiINCg0KNCAocGFnZSAxMyk6ICJ0aGVyZSBleGlzdCB0d28gcm9v dHMgb2YgeCBpbiB0aGUgZmllbGQgRiB3aGVuZXZlciB4IGlzDQpzcXVhcmUuIiAtPiBleGNlcHQg d2hlbiB4ID0gMC4gWmVybyBoYXMgYSB1bmlxdWUgc3F1YXJlIHJvb3QgaW4gRi4NCg0KNCAocGFn ZSAxMyk6ICJUbyBpbXBsZW1lbnQgaW52MCBpbiBjb25zdGFudCB0aW1lLCBjb21wdXRlIGludjAo eCkgOj0NCnheKHEtMikiIC0+IERlcGVuZGluZyBvbiB0aGUgZmllbGQsIHRoZXJlIG1heSBiZSAo bXVjaCkgZmFzdGVyIHdheXMsIGluDQpwYXJ0aWN1bGFyIGluIGZpZWxkIGV4dGVuc2lvbnMgKGUu Zy4gaW4gQ3VydmU5NzY3LCBpbnZlcnNpb24gY29zdCBpcw0KYWJvdXQgNk0sIHdoaWxlIEZlcm1h dCdzIExpdHRsZSBUaGVvcmVtIHdvdWxkIGJyaW5nIGl0IHRvIGFib3V0IDMwME0hKS4NCkV2ZW4g aW4gcHJpbWUgZmllbGRzLCBhIGNvbnN0YW50LXRpbWUgZXh0ZW5kZWQgYmluYXJ5IEdDRCB3aWxs IHR5cGljYWxseQ0KaGF2ZSBjb3N0IGJldHdlZW4gNDBNIGFuZCAxMDBNIGZvciBpbnZlcnNpb24g KGJ1dCBzb21lIHNwZWNpZmljIGNhcmUgaXMNCnJlcXVpcmVkIHRvIGVuc3VyZSB0aGF0IGludjAo MCkgPSAwKS4gSG93ZXZlciwgaXQgbXVzdCBiZSBzYWlkIHRoYXQgdGhlDQpleHBvbmVudGlhdGlv biBpcyBhIHNpbXBsZSB0byBpbXBsZW1lbnQgaW4gY29uc3RhbnQtdGltZSBpZg0KY29uc3RhbnQt dGltZSBtdWx0aXBsaWNhdGlvbiBpcyBhdmFpbGFibGUgKGFuZCBpdCBzaG91bGQsIG90aGVyd2lz ZSB0aGUNCndob2xlIHRoaW5nIGlzIGhvcGVsZXNzKS4NCg0KNCAocGFnZSAxMyk6IEl0IG1heSBi ZSB3b3J0aCBtZW50aW9uaW5nIHRoYXQgSTJPU1AgYW5kIE9TMklQLCBhcyBkZWZpbmVkDQppbiBQ S0NTIzEgKGFrYSBSRkMgODAxNyksIGFyZSBiaWctZW5kaWFuLiBJbiBwYXJ0aWN1bGFyLCBtb3N0 IG9mIHRoZQ0KY3VydmUyNTUxOS9lZHdhcmRzMjU1MTkgZWNvc3lzdGVtIHRlbmRzIHRvIGJlIGxp dHRsZS1lbmRpYW4sIHNvIHRoYXQncyBhDQpwbGF1c2libGUgc291cmNlIG9mIG1pc3Rha2VzLg0K DQo1IChwYWdlIDUpOiBUaGUgZHJhZnQgdXNlcyAiU0hBS0UtMTI4IiBhcyB0aGUgbmFtZSBvZiBT SEFLRSB3aXRoIGENCjEyOC1iaXQgb3V0cHV0LCBidXQgdGhlIE5JU1Qgc3BlY2lmaWNhdGlvbiAo RklQUyAyMDIpIGRlZmluZXMgIlNIQUtFMTI4Ig0Kd2l0aG91dCB0aGUgZGFzaC4gVGhpcyBpbXBh Y3RzIHRoZSB1c2Ugb2YgdGhlIG5hbWUgaW4gSURzIChlLmcuIGluDQpzZWN0aW9uIDguMTAsIHBh Z2UgNDMpLg0KDQo1LjIgKHBhZ2UgMTcpOiBNYXliZSBub3RlIHNvbWV3aGVyZSB0aGF0IGltcGxl bWVudGF0aW9uIG9mICJtb2QgcCIgd2l0aA0KY29uc3RhbnQtdGltZSBjb2RlIGlzIG5vdCBjb21w bGV0ZWx5IG9idmlvdXMuIFVzaW5nIEV1Y2xpZGVhbiBkaXZpc2lvbg0KaXMgbm90IGNvbnN0YW50 LXRpbWUuIE1vc3QgY29uc3RhbnQtdGltZSBpbXBsZW1lbnRhdGlvbnMgdXNlIEJhcnJldHQNCnJl ZHVjdGlvbiwgYWx0aG91Z2ggc29tZSB1c2UgTW9udGdvbWVyeSBpbnN0ZWFkLg0KDQo1LjIgKHBh Z2UgMTcpOiBXaGVuIG1hcHBpbmcgdG8gYSBmaWVsZCBHRihwXm0pIHdpdGggYSByZWxhdGl2ZWx5 IHNtYWxsIHANCihlLmcuIGxlc3MgMzIgYml0cyksIHRoZW4gdGhlIHByb3Bvc2VkIGhhc2hfdG9f ZmllbGQoKSBpcyByYXRoZXINCndhc3RlZnVsIGluIGhhc2ggb3V0cHV0LiBGb3Igc3VjaCBmaWVs ZHMsIGdlbmVyYXRpbmcgaytsb2cyKHBebSkgYml0cw0KYW5kIHRoZW4gcmVwZWF0ZWRseSBkaXZp ZGluZyB0aGF0IGJpZyBpbnRlZ2VyIGJ5IHAgd2lsbCBiZSBmYXN0ZXIsDQplc3BlY2lhbGx5IHdo ZW4gd29ya2luZyBvbiBlbWJlZGRlZCBzeXN0ZW1zLiBPbiBhbiBBUk0gQ29ydGV4IE0wKywgd2l0 aA0KZmllbGQgR0YoOTc2N14xOSksIEkgY2FuIGdldCBhIG1hcF90b19maWVsZCgpIGluIGFib3V0 IDIwMDAwIGN5Y2xlcywNCndoaWxlIGVhY2ggaW52b2NhdGlvbiBvZiB0aGUgU0hBS0UgaW50ZXJu YWwgZnVuY3Rpb24gY29zdHMgMzQwMDAgY3ljbGVzDQphbmQgdGhlIHByb3Bvc2VkIG1ldGhvZCB3 b3VsZCByZXF1aXJlIHRocmVlIGludm9jYXRpb25zIG9mIHRoYXQgaW50ZXJuYWwNCmZ1bmN0aW9u IHRvIGdldCBlbm91Z2ggYnl0ZXMuDQoNCjUuMy4xIChwYWdlIDE4KTogSSBuZWVkZWQgdG8gdmVy aWZ5LCBidXQgIkRhbWdhYXJkIiBpcyBpbmRlZWQgdGhlDQpjb3JyZWN0IEFTQ0lJLWNvbXBhdGli bGUgYWx0ZXJuYXRpdmUgc3BlbGxpbmcgb2YgIkRhbWfDpXJkIi4gTmljZSBqb2IhDQoNCjUuMy4x IChwYWdlIDE5KTogRGVmaW5pdGlvbiBvZiBiX2luX2J5dGVzIHVzZXMgY2VpbCgpLCBpLmUuIGFj Y291bnRzIGZvcg0KdGhlIHBvc3NpYmlsaXR5IHRoYXQgSCBvdXRwdXRzIHNvbWV0aGluZyBlbHNl IHRoYW4gYW4gaW50ZWdyYWwgbnVtYmVyDQpvZiBieXRlcy4gQnV0IGlmIHRoYXQgaXMgdGhlIGNh c2UsIHRoZSAidW5pZm9ybV9ieXRlcyIgYXJlIG5vdCB1bmlmb3JtIQ0KSXQgd291bGQgYmUgYmV0 dGVyIHRvIG1ha2UgaXQgYW4gZXhwbGljaXQgcmVxdWlyZW1lbnQgdGhhdCB0aGUgb3V0cHV0DQps ZW5ndGggb2YgSCwgaW4gYml0cywgTVVTVCBiZSBhIG11bHRpcGxlIG9mIDguDQoNCjUuMy4xIChw YWdlIDE5KTogcl9pbl9ieXRlcyBpcyBzYWlkIHRvIGJlIHRoZSAiYmxvY2sgc2l6ZSIgb2YgYSBo YXNoDQpmdW5jdGlvbiwgYnV0IHRoYXQgbm90aW9uIGhhcyBub3QgYmVlbiBkZWZpbmVkLiBHZW5l cmFsbHkgc3BlYWtpbmcsIHNvbWUNCmhhc2ggZnVuY3Rpb25zIGRvIG5vdCBoYXZlIGEgd2VsbC1k ZWZpbmVkICJibG9jayBzaXplIi4gWW91IG1heSBmYWxsDQpiYWNrIGhlcmUgb24gSE1BQywgc2lu Y2UgSE1BQyBhbHNvIG5lZWRzIGEgImJsb2NrIHNpemUiOyBmb3IgaW5zdGFuY2UsDQpGSVBTIDIw MiBkZWZpbmVzIHRoZSBibG9jayBzaXplIG9mIFNIQTMtMjU2IHRvIGJlIDEzNiBieXRlcy4NCg0K NS4zLjQgKHBhZ2UgMjEpOiAicHJlcGVuZGVkIG9yIGFwcGVuZGVkIiAtPiB0ZWNobmljYWxseSwg InByZXBlbmRlZCIgaXMNCmFuIGFjdHVhbCBFbmdsaXNoIHdvcmQsIGJ1dCBub3Qgd2l0aCB0aGF0 IG1lYW5pbmcuIEl0IG1lYW5zIHNvbWV0aGluZw0KbGlrZSAicHJlbWVkaXRhdGUiLiBJIHN1Z2dl c3Q6ICJhbiBlbmNvZGluZyBvZiBEU1QgTVVTVCBiZSBhZGRlZCBlaXRoZXINCmFzIGEgcHJlZml4 IG9yIHN1ZmZpeCB0byB0aGUgaW5wdXQgdG8gZWFjaCBpbnZvY2F0aW9uIG9mIEggKGEgc3VmZml4 IGlzDQp0aGUgUkVDT01NRU5ERUQgYXBwcm9hY2gpLiINCg0KNi42LjEgKHBhZ2UgMjUpOiBJdCBt YXkgYmUgd29ydGggbWVudGlvbmluZyB0aGF0IHNvbWUgb2YgdGhlIGNvbXB1dGVkDQp2YWx1ZXMg YXJlIGFjdHVhbGx5IGNvbnN0YW50cywgZS5nLiB0djQgKHN0ZXAgNSkgb3IgLTQqZyhaKS8oMypa XjIrNCpBKQ0KKHVzZWQgaW4gc3RlcCAxMCkgKHRoaXMgaXMgYXBwbGllZCBpbiBhcHBlbmRpeCBE LjEpLiBJbiBlZmZlY3QsIHRoZQ0KImV4cGVuc2l2ZSIgb3BlcmF0aW9ucyBpbiB0aGlzIGFsZ29y aXRobSB0aGF0IGNhbm5vdCBiZSBwcmVjb21wdXRlZCBhcmUNCjEgaW52MCgpLCAyIGlzX3NxdWFy ZSgpLCBhbmQgMSBzcXJ0KCkuIFRoaXMgbWFrZXMgaXQgYXBwYXJlbnQgdGhhdCB0aGUNCnNwZWVk IGFkdmFudGFnZSBvZiB0aGUgc2ltcGxpZmllZCBTV1UgbWFwIGlzIHRoYXQgaXQgc2F2ZXMgMSBp c19zcXVhcmUoKQ0KY2FsbCwgaS5lLiBhYm91dCAyNSUgb2YgdGhlIG92ZXJhbGwgY29zdCBpZiBp bnYwKCksIGlzX3NxdWFyZSgpIGFuZA0Kc3FydCgpIGFyZSBpbXBsZW1lbnRlZCB3aXRoIG1vZHVs YXIgZXhwb25lbnRpYXRpb25zLg0KDQoxMCAocGFnZSA0NSk6IGZvciBwYXNzd29yZCBoYXNoaW5n LCBkaXNjdXNzaW9uIHBvaW50cyB0byBQQktERjIgYW5kDQpTY3J5cHQuIEl0IG1pZ2h0IGJlIHdv cnRoIG1lbnRpb25pbmcgQXJnb24yLCBmb3Igd2hpY2ggdGhlcmUgaXMgYW4NCmluLXByb2dyZXNz IGRyYWZ0Og0KICAgaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaXJ0Zi1j ZnJnLWFyZ29uMi8NCg0KMTAgKHBhZ2UgNDUpOiAidGhlIG5hdHVyZSBvZiB0aGUgbGVha2FnZSBh bmQgdGhlIGFwcHJvcHJpYXRlIGRlZmVuc2UNCmRlcGVuZHMgb24gdGhlIGFwcGxpY2F0aW9uLiIg LT4gc2hvdWxkIGJlICJkZXBlbmQiIGhlcmUuDQoNCkUuMSAocGFnZSA3NSk6IEl0IG1heSBiZSB3 b3J0aCBtZW50aW9uaW5nIGhlcmUgdGhhdCB0aGUgcmFuZG9tIG9yYWNsZQ0KbWFwcGluZyByZXF1 aXJlcyBkb2luZyB0d28gbWFwX3RvX2N1cnZlKCkgYW5kIGFkZGluZyB0aGUgcmVzdWx0cw0KdG9n ZXRoZXIsIGFuZCB0aGlzIGlzLCBpbiBpdHNlbGYsIGVub3VnaCB0byBtYWtlIHByb2plY3RpdmUg Y29vcmRpbmF0ZXMNCnVzZWZ1bC4gSW4gcGFydGljdWxhciwgd2hlbiB1c2luZyBhIFdlaWVyc3Ry YcOfIGN1cnZlLCB5b3UgbXVzdCB0YWtlIGludG8NCmFjY291bnQgdGhlIChyZW1vdGUpIHBvc3Np YmlsaXR5IHRoYXQgdGhlIHR3byBwb2ludHMgbWF5IGJlIHRoZSBzYW1lLA0KdGhlcmVmb3JlIHJl cXVpcmluZyBhIGNvbnN0YW50LXRpbWUgZ2VuZXJpYyBwb2ludCBhZGRpdGlvbiByb3V0aW5lOw0K dGhlcmUgYXJlIGNvbXBsZXRlIGZvcm11bGFzIGZvciBXZWllcnN0cmHDnyBjdXJ2ZXMgaW4gaG9t b2dlbm91cw0KcHJvamVjdGl2ZSBjb29yZGluYXRlcy4NCg0KRy41IChwYWdlIDk2KTogIk90aGVy IG9wdGltaXphdGlvbnMgb2YgdGhpcyB0eXBlIGFyZSBwb3NzaWJsZSBpbiBvdGhlcg0KZXZlbi1v cmRlciBleHRlbnNpb24gZmllbGRzIiAtPiBZb3UgY2FuIGFsc28gaGF2ZSBzaW1pbGFyIG9wdGlt aXphdGlvbnMNCmluIGFueSBleHRlbnNpb24gZmllbGQuIEluIGdlbmVyYWwsIGZvciBhbiBvZGQg cCBhbmQgYW4gYXJiaXRyYXJ5IG0gPiAxOg0KDQogICAgICAocC0xKS8yID0gKChwLTEpLzIpKigx K3ArcF4yKy4uLitwXihtLTEpKQ0KDQpUaHVzLCBpZiB3ZSBjYWxsIHIgPSAxK3ArcF4yKy4uLitw XihtLTEpLCB3ZSBoYXZlOg0KDQogICAgICB4XigocC0xKS8yKSA9ICh4XnIpXigocC0xKS8yKQ0K DQpUaGlzIGNhbiBiZSBjb21wdXRlZCB2ZXJ5IGVmZmljaWVudGx5IGJlY2F1c2U6DQoNCiAgLSB4 XnIgaXMgYW4gZWxlbWVudCBvZiBHRihwKSAoaW5kZWVkLCAoeF5yKV4ocC0xKSA9IDEgZm9yIGFu eSB4ICE9IDAsDQogICAgYW5kIG9ubHkgZWxlbWVudHMgb2YgR0YocCkgYXJlIHJvb3RzIG9mIHRo ZSBwb2x5bm9taWFsIFheKHAtMSktMSBpbg0KICAgIEdGKHBebSlbWF0pLCBzbyB0aGUgZmluYWwg ZXhwb25lbnRpYXRpb24gYnkgKHAtMSkvMiBjYW4gYmUgZG9uZSB3aXRoDQogICAgb25seSB2YWx1 ZXMgaW4gdGhlIHNtYWxsIGZpZWxkIEdGKHApLg0KDQogIC0geF5yIGNhbiBiZSBjb21wdXRlZCBp biBsb2cobSkgbXVsdGlwbGljYXRpb25zIGFuZCBsb2cobSkgYXBwbGljYXRpb25zDQogICAgb2Yg dGhlIEZyb2Jlbml1cyBvcGVyYXRvcjoNCg0KICAgICAgdDEgPSB4ICogeF5wID0geF4oMStwKQ0K ICAgICAgdDIgPSB0MSAqIHQxXihwXjIpID0geF4oMStwK3BeMitwXjMpDQogICAgICB0MyA9IHQy ICogdDJeKHBeNCkgPSB4XigxK3ArcF4yK3BeMytwXjQrcF41K3BeNitwXjcpDQogICAgICAuLi4N Cg0KICAgIFRoZSBGcm9iZW5pdXMgb3BlcmF0b3IgaXRzZWxmIGlzIHR5cGljYWxseSBhcyBlZmZp Y2llbnQsIG9yIGV2ZW4NCiAgICBmYXN0ZXIsIGFzIGEgbXVsdGlwbGljYXRpb24sIHNpbmNlIGl0 IGlzIGEgbGluZWFyIHRyYW5zZm9ybSBvdmVyIHRoZQ0KICAgIHNvdXJjZSBwb2x5bm9taWFsIChz ZWVuIGFzIGEgdmVjdG9yIGluIGEgc3BhY2Ugb2YgZGltZW5zaW9uIG0gb3Zlcg0KICAgIEdGKHAp KS4gSWYgR0YocF5tKSB3YXMgZGVmaW5lZCBtb2R1bG8gTSA9IFhebS1jIGZvciBzb21lIGNvbnN0 YW50IGMsDQogICAgdGhlbiB0aGUgRnJvYmVuaXVzIG9wZXJhdG9yIGlzIGEgc2ltcGxlIHBlci1j b2VmZmljaWVudA0KICAgIG11bHRpcGxpY2F0aW9uLCBpLmUuIGEgY29zdCBjbG9zZSB0byB0aGF0 IG9mIGFuIGFkZGl0aW9uIGluIEdGKHBebSkuDQoNClRoZSBhbGdvcml0aG0gaW4gYXBwZW5kaXgg Ry41IGlzIGEgc2ltcGxlIHN1Yi1jYXNlIG9mIHRoaXMsIHdoZW4gbSA9IDIuDQoNCg0KVGhvbWFz DQoNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCkZyb206IENy eXB0by1wYW5lbCA8Y3J5cHRvLXBhbmVsLWJvdW5jZXNAaXJ0Zi5vcmc+IG9uIGJlaGFsZiBvZiAi U3RhbmlzbGF2IFYuIFNteXNobHlhZXYiIDxzbXlzaHN2QGdtYWlsLmNvbT4NCkRhdGU6IEZyaWRh eSwgSnVuZSA1LCAyMDIwIGF0IDA4OjExDQpUbzogVGhvbWFzIFBvcm5pbiA8dGhvbWFzLnBvcm5p bj00MG5jY2dyb3VwLmNvbUBkbWFyYy5pZXRmLm9yZz4NCkNjOiAiY3J5cHRvLXBhbmVsQGlydGYu b3JnIiA8Y3J5cHRvLXBhbmVsQGlydGYub3JnPiwgImRyYWZ0LWlydGYtY2ZyZy1oYXNoLXRvLWN1 cnZlLmF1dGhvcnNAaWV0Zi5vcmciIDxkcmFmdC1pcnRmLWNmcmctaGFzaC10by1jdXJ2ZS5hdXRo b3JzQGlldGYub3JnPiwgImNmcmctY2hhaXJzQGlldGYub3JnIiA8Y2ZyZy1jaGFpcnNAaWV0Zi5v cmc+DQpTdWJqZWN0OiBSZTogW0NyeXB0by1wYW5lbF0gRVhURVJOQUw6IFJlcXVlc3QgZm9yIHJl dmlldzogZHJhZnQtaXJ0Zi1jZnJnLWhhc2gtdG8tY3VydmUtMDgNCg0KR3JlYXQsIG1hbnkgdGhh bmtzLCBUaG9tYXMhDQoNClN0YW5pc2xhdiAoZm9yIENoYWlycykNCg0KT24gRnJpLCA1IEp1biAy MDIwIGF0IDE0OjUzLCBUaG9tYXMgUG9ybmluIDx0aG9tYXMucG9ybmluPW1haWx0bzo0MG5jY2dy b3VwLmNvbUBkbWFyYy5pZXRmLm9yZz4gd3JvdGU6DQpJIGNhbiBkbyB0aGF0Lg0KwqANClRob21h cw0KwqANCkZyb206IENyeXB0by1wYW5lbCA8bWFpbHRvOmNyeXB0by1wYW5lbC1ib3VuY2VzQGly dGYub3JnPiBvbiBiZWhhbGYgb2YgIlN0YW5pc2xhdiBWLiBTbXlzaGx5YWV2IiA8bWFpbHRvOnNt eXNoc3ZAZ21haWwuY29tPg0KRGF0ZTogRnJpZGF5LCBKdW5lIDUsIDIwMjAgYXQgMDA6MTcNClRv OiAibWFpbHRvOmNyeXB0by1wYW5lbEBpcnRmLm9yZyIgPG1haWx0bzpjcnlwdG8tcGFuZWxAaXJ0 Zi5vcmc+DQpDYzogIm1haWx0bzpkcmFmdC1pcnRmLWNmcmctaGFzaC10by1jdXJ2ZS5hdXRob3Jz QGlldGYub3JnIiA8bWFpbHRvOmRyYWZ0LWlydGYtY2ZyZy1oYXNoLXRvLWN1cnZlLmF1dGhvcnNA aWV0Zi5vcmc+LCAibWFpbHRvOmNmcmctY2hhaXJzQGlldGYub3JnIiA8bWFpbHRvOmNmcmctY2hh aXJzQGlldGYub3JnPg0KU3ViamVjdDogRVhURVJOQUw6IFtDcnlwdG8tcGFuZWxdIFJlcXVlc3Qg Zm9yIHJldmlldzogZHJhZnQtaXJ0Zi1jZnJnLWhhc2gtdG8tY3VydmUtMDgNCsKgDQpEZWFyIENy eXB0byBQYW5lbCBtZW1iZXJzLMKgDQrCoA0KQWxleGV5LCBOaWNrIGFuZCBJIHdvdWxkIGxpa2Ug dG8gYXNrIENyeXB0byBSZXZpZXcgUGFuZWwgbWVtYmVycyBhYm91dCB0aGUgcmV2aWV3KHMpIG9m IGRyYWZ0LWlydGYtY2ZyZy1oYXNoLXRvLWN1cnZlLTA4Lg0KwqANClRoZSBkb2N1bWVudCBzcGVj aWZpZXMgYSBudW1iZXIgb2YgYWxnb3JpdGhtcyBmb3IgZW5jb2Rpbmcgb3IgaGFzaGluZyBhbiBh cmJpdHJhcnkgc3RyaW5nIHRvIGEgcG9pbnQgb24gYW4gZWxsaXB0aWMgY3VydmUuwqANCsKgDQrC oA0KQ2FuIHdlIGhhdmUgYW55IHZvbHVudGVlcnMsIHBsZWFzZT8NCsKgDQrCoA0KQmVzdCByZWdh cmRzLA0KU3RhbmlzbGF2IChvbiBiZWhhbGYgb2YgY2hhaXJzKQ0KX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCkNyeXB0by1wYW5lbCBtYWlsaW5nIGxpc3QN Cm1haWx0bzpDcnlwdG8tcGFuZWxAaXJ0Zi5vcmcNCmh0dHBzOi8vd3d3LmlydGYub3JnL21haWxt YW4vbGlzdGluZm8vY3J5cHRvLXBhbmVsDQoNCg== From nobody Tue Jun 9 21:06:40 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 825FB3A0E31 for ; Tue, 9 Jun 2020 21:06:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lepidum-co-jp.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id r9kx8dLFbVM7 for ; Tue, 9 Jun 2020 21:06:35 -0700 (PDT) Received: from mail-lj1-x22a.google.com (mail-lj1-x22a.google.com [IPv6:2a00:1450:4864:20::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id F17A43A0E2A for ; Tue, 9 Jun 2020 21:06:34 -0700 (PDT) Received: by mail-lj1-x22a.google.com with SMTP id a25so719107ljp.3 for ; Tue, 09 Jun 2020 21:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lepidum-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=SnrCFlsVqGidGIP0fnsTdDEcayDCOgfZEjFcWjXV7vE=; b=TWqpNfB7785ABSthZakUxm4tf3olUhmUNQDUT/Ug1DWPWcflcRqLbTwKTDDWIJx7u6 L/WsOaQ0CmmD+9FXeG1s6PfwFo5y+UplgOWHnSWNLbJAspp+50n3Z8DOv2ohUhJJEmFF xLp5t3tRQjtSM/cb8BnyBkygu9TJ8X9if1dUuDxPx1c6qG+wKnDqokeSp87TiXJ+VxEF fdlo/WalgssxN7a+LHzqpf755gWCU5sDjfdyOcl4Ktp8SIv3Nuub26E7fozYwxQ3Kxse CYA//iYcPlQyly+8Z4UlfL8x/+FgJF3ZkKMXOYtMjCDSo8eJ6b0pntYBbo8yVfAyfwPI HxSA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=SnrCFlsVqGidGIP0fnsTdDEcayDCOgfZEjFcWjXV7vE=; b=q6a8f6RnzN1S4P9//MfEGDaGO0Q5oJtcEp9/t9wRZGGrMAFIr9U5dz+Ty4DRhHHh1l dAoiyWQ9ST+IgM6VdoJSjJTCszsw+qjTzO5UzwKR1yXrJt7O0thpsvhRfagICp4lMOe5 YTIsSHgjZNrNXDzAGg3rRJ6S4wjvHGFf9LUHLYBXny2Wpg4J5HLtjgezTOxE0C/5BGy2 RkFwc8LIJrMDmza8mq/FbXETKzY7WNtKOr7cFeY+RFPbmHv25ErCqf91Z5Jj9kz4RfKE 6QxO7fSj/hcZDSNZYXRl1QV8wyWAO5GofvZDtI9h1XByNV8EPNLEwprhhW9e273GBjb6 2pcg== X-Gm-Message-State: AOAM5305Gpzzs4/3WIITp9RwoBR5spvmO3RBfjwNyJ1g5EGp84CuYqI7 hjiO1KCcRKFYkcJEozRh5aueyw93a6VMaNFUcyOACA== X-Google-Smtp-Source: ABdhPJwzAwrHrR46QD6LRzNDwPay1SOU//S8wgtmBURpNhI+vzJHbWrIxPxZtqY33Z5tu3MB8LJqio5uId//FdHyJ/U= X-Received: by 2002:a2e:800c:: with SMTP id j12mr645516ljg.218.1591761991341; Tue, 09 Jun 2020 21:06:31 -0700 (PDT) MIME-Version: 1.0 References: <002201d61c30$4f561da0$ee0258e0$@hco.ntt.co.jp_1> In-Reply-To: From: Yumi Sakemi Date: Wed, 10 Jun 2020 13:06:20 +0900 Message-ID: To: Chloe Martindale Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org, Tetsutaro Kobayashi , SAITO Tsunekazu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-pairing-friendly-curves-03 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 04:06:38 -0000 Dear Alexey, Nick, Stanislav, and Chloe We have submitted the latest version 05 of the draft "Pairing-Friendly Curv= es". https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves/ We have categorized a lot of comments received in the Expert Review into more than 40 issues, and reflected the results which we considered all of issues to the latest version. While we revised the draft, we received comments from other CFRG members and the authors of the draft "BLS Signatures", and reflected them to the latest version. If you want to know the details of how to revise, you can check them by closed issues on the official CFRG GitHub page. https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/issues?q=3D= is%3Aissue+is%3Aclosed Thanks to valuable and constructive comments from Chloe and CFRG members, our draft became readable and higher quality. We strongly believe that the draft is ready for RG Last Call. If there are other necessary procedures for RGLC, could you tell us? Best regards, Yumi 2020=E5=B9=B46=E6=9C=889=E6=97=A5(=E7=81=AB) 20:02 Yumi Sakemi : > > Dear Chloe > > Thank you for your e-mail. > > We are very glad to reach a rough consensus with you. > We believe that our draft became very readable and higher quality by > reflecting your comments. > We appreciate your valuable and constructive comments. > > We'd like to express our gratitude and include your name in Acknowledgeme= nt. > The version 05 that is reflected your comments will be submitted today > or tomorrow, then we will contact you again. > > Best regards, > Yumi > > 2020=E5=B9=B46=E6=9C=881=E6=97=A5(=E6=9C=88) 18:53 Chloe Martindale : > > > > Dear Yumi, dear all, > > > > thank you for the update and for involving me in your thought process r= egarding the curve choices. I understand and agree with your reasoning (and= approach) regarding including both BLS12-381 and BN462, however I think I = would make a different 'safer choice'. > > > > My reason is this: if the attack is improved further (which you are com= pletely right, it may), it is very likely to have a bigger impact on curves= constructed via polynomial methods with embedding degree 8 (such as BN462)= than on any other curves for this security level, so it's not unlikely tha= t the security of BN462 would be pushed below 128 bits. A safer choice in m= y view would be to take the Cocks-Pinch curve (not constructed using polyno= mial methods) defined using a 544-bit prime implemented in RELIC, from [GMT= 19]*. The TNFS attacks cannot be applied to Cocks-Pinch curves (at least no= t without a fundamental new attack idea, since they rely on the polynomial = construction), so small improvements will not decrease the security level a= t all, and this curve is actually still more efficient than BN462 so there'= s nothing to lose there. I appreciate that such a choice would mean also in= cluding some background on Cocks-Pinch and a reference/short explanation of= the fact that TNFS attacks don't apply to these, which would be a major ch= ange to the original document, so I appreciate it if you'd rather not do th= is, but just thought I'd suggest it as I think it would increase the lifeti= me of your document. > > > > *In your draft this is [GME19], but it should be [GMT19], and can now b= e updated to the peer-reviewed version of course (this is the paper I point= ed out in my review). > > > > All the best, > > Chloe > > > > On Fri, 29 May 2020 at 16:21, Yumi Sakemi w= rote: > >> > >> Dear Chloe > >> > >> We appreciate a lot of constructive comments received at Expert Review= . > >> > >> We are currently working on updating our draft. > >> Last week, Nick created a repository for pairing-friendly curves on > >> CFRG's official GitHub, so we plan to update our draft using the issue > >> tracker. > >> The updating for your comments will be made available to you on the > >> following issue page. > >> > >> https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/issues > >> > >> We will contact you again when all the comments have been updated. > >> In that case, we would be glad if you could check them. > >> > >> In addition, before updating, there is a comment that we would like to > >> inform you about the policy of update. > >> The comment is about the recommended curve for 128-bit security level. > >> > >> First of all, thank you for teaching us a peer-reviewed paper for BLS1= 2-381. > >> The comment is about the recommended curve for 128-bit security level. > >> Due to our lack of investigation, we made the wrong decision that > >> BLS12-381 was not matched in our selection policy. > >> > >> Your comment pointed out that BLS12-381 is moved to the recommended > >> curve and BN462 is moved to the Appendix. > >> We understood the disadvantages of BN462 that you were concerned > >> about, but we would like to recommend both BLS12-381 and BN462. > >> The reason is as follows. > >> > >> CFRG aims to standardize cryptographic technology for future Internet = use. > >> We agree that BLS12-381 with a 126-bit security level is the best > >> match as a curve of 128-bit security level "at this time" from the > >> viewpoint of security and efficiency. > >> On the other hand, the security of BLS12-381 is already less than > >> 128bit, so from the viewpoint of future use, if the attack is improved > >> even a little, it will not be suitable for a curve of 128-bit security > >> level. > >> Considering that the curve of 128-bit security level is often used at = current. > >> So, we would like to recommend both BLS12-381 and BN462 considering > >> the future use and the safety side. > >> > >> However, as you pointed out, BN462 has the disadvantage of being too > >> slow compared to BLS12-381. > >> Then, the reader will be confused if there are two parameters of > >> 128-bit security level, so we will add the basis for selection by > >> adding the explanation of merits and demerits for each parameter. > >> And, we will also add a description about the disadvantages of BN462 > >> regarding efficiency. > >> > >> If you have any problems with the updating policy, we would like you t= o comment. > >> > >> Best regards, > >> Yumi > >> > >> > >> > >> > >> > >> > >> 2020=E5=B9=B44=E6=9C=8827=E6=97=A5(=E6=9C=88) 21:58 Yumi Sakemi : > >> > > >> > Dear Chloe > >> > > >> > I appreciate your review. > >> > I'm very glad to receive many constructive comments! > >> > I will discuss about your comments with co-authors and revise our > >> > draft to reflect your comments in our draft. > >> > I think it will be a better draft by reflecting your comments. > >> > > >> > As co-author Tsunekazu e-mailed, we're planning to submit version 0= 4, > >> > because we were independently working on updating of abstract, > >> > introduction (sec. 1.3) and proofreading of English in parallel with > >> > the expert review. > >> > (Version 04 will not be reflected your comments.) > >> > > >> > Comments from Chloe will be reflected in the version 05. > >> > We will submit version 05 in mid-May and we will report you when we > >> > submit version 05. > >> > > >> > Dear Stanislav > >> > > >> > Thank you very much for proceeding to the Expert review. > >> > We received a lot of constructive comments from Chloe, so I think it > >> > is difficult to manage comments by email. > >> > (Because there are over 100 comments from Chloe.) > >> > > >> > Therefore, I would like to use the issue management function of GitH= ub > >> > so that it is easy to check the reflecting status of Chloe's comment= s. > >> > So, I'd like to use the repository of pairing-friendly curves draft = on > >> > CFRG's GitHub > >> > because BLS signature which is similar in terms of IRTF stream is al= so > >> > registered on the GitHub. > >> > Could you register the repository for the draft of pairing-friendly > >> > curves on the following CFRG's GitHub? > >> > > >> > https://github.com/cfrg > >> > > >> > Best regards, > >> > Yumi > >> > > >> > 2020=E5=B9=B44=E6=9C=8827=E6=97=A5(=E6=9C=88) 10:09 SAITO Tsunekazu = : > >> > > > >> > > Dear Chloe, Stanislav, > >> > > > >> > > > >> > > > >> > > This is Tsunekazu. > >> > > > >> > > > >> > > > >> > > We plan to update the draft to version 04 soon. > >> > > > >> > > As the contents of the update, we changed the wording of Section 1= .3 and security consideration. > >> > > > >> > > Yumi will submit the 4th edition, so please wait a moment. > >> > > > >> > > > >> > > > >> > > Best regards, > >> > > > >> > > Tsunekazu > >> > > > >> > > > >> > > > >> > > From: Stanislav V. Smyshlyaev > >> > > Sent: Sunday, April 26, 2020 2:30 PM > >> > > To: Chloe Martindale ; SAITO Tsunekazu = ; Tetsutaro Kobayashi ; Yumi Sakemi > >> > > Cc: cfrg-chairs@ietf.org; crypto-panel@irtf.org > >> > > Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-pa= iring-friendly-curves-03 > >> > > > >> > > > >> > > > >> > > Dear Chloe, > >> > > > >> > > Many thanks for your review (such a great and a prompt one!). > >> > > > >> > > > >> > > > >> > > Dear Yumi, Saito, Tetsutaro, do you plan to update your draft taki= ng into account Chloe=E2=80=99s review? > >> > > > >> > > > >> > > > >> > > Best regards, > >> > > > >> > > Stanislav > >> > > > >> > > > >> > > > >> > > =D0=BF=D1=82, 24 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 19:49, Ch= loe Martindale : > >> > > > >> > > Hi all, > >> > > > >> > > > >> > > > >> > > review is attached. > >> > > > >> > > > >> > > > >> > > All the best, > >> > > > >> > > Chloe > >> > > > >> > > > >> > > > >> > > On Tue, 21 Apr 2020 at 18:05, Stanislav V. Smyshlyaev wrote: > >> > > > >> > > Sure - it is > >> > > > >> > > https://tools.ietf.org/html/draft-irtf-cfrg-pairing-friendly-curve= s-03 > >> > > > >> > > > >> > > > >> > > Thank you again! > >> > > > >> > > > >> > > > >> > > Regards, > >> > > > >> > > Stanislav > >> > > > >> > > > >> > > > >> > > =D0=B2=D1=82, 21 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 19:10, Ch= loe Martindale : > >> > > > >> > > Just to be sure, can you point me towards the most recent version = of the draft please? > >> > > > >> > > > >> > > > >> > > Thanks, > >> > > > >> > > Chloe > >> > > > >> > > > >> > > > >> > > On Tue, 21 Apr 2020 at 13:17, Stanislav V. Smyshlyaev wrote: > >> > > > >> > > Great, many thanks, Chloe! > >> > > > >> > > > >> > > > >> > > Kind regards, > >> > > > >> > > Nick, Alexey, Stanislav > >> > > > >> > > > >> > > > >> > > On Tue, 21 Apr 2020 at 15:16, Chloe Martindale wrote: > >> > > > >> > > I'll take a look this week. > >> > > > >> > > > >> > > > >> > > All the best, > >> > > > >> > > Chloe > >> > > > >> > > > >> > > > >> > > On Tue, 21 Apr 2020, 13:10 Stanislav V. Smyshlyaev, wrote: > >> > > > >> > > Dear Crypto Panel members, > >> > > > >> > > > >> > > > >> > > The authors of the Pairing-Friendly Curves draft have addressed th= e concerns raised during the discussion and are ready to move to the next s= tage with the draft. > >> > > > >> > > > >> > > > >> > > Alexey, Nick and I would like to ask Crypto Review Panel members a= bout the review(s) of draft-irtf-cfrg-pairing-friendly-curves-03. > >> > > > >> > > > >> > > > >> > > This memo introduces pairing-friendly curves used for constructing= pairing-based cryptography. It describes recommended parameters for each s= ecurity level and recent implementations of pairing-friendly curves. > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > Can we have any volunteers, please?.. > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > Best regards, > >> > > > >> > > Stanislav (on behalf of chairs) > >> > > > >> > > _______________________________________________ > >> > > Crypto-panel mailing list > >> > > Crypto-panel@irtf.org > >> > > https://www.irtf.org/mailman/listinfo/crypto-panel > >> > > >> > > >> > > >> > -- > >> > Yumi Sakemi, Ph. D. > >> > Lepidum Co. Ltd. > >> > E-Mail: yumi.sakemi@lepidum.co.jp > >> > >> > >> > >> -- > >> Yumi Sakemi, Ph. D. > >> Lepidum Co. Ltd. > >> > >> E-Mail: yumi.sakemi@lepidum.co.jp > > > > -- > Yumi Sakemi > Lepidum Co. Ltd. > > E-Mail: yumi.sakemi@lepidum.co.jp --=20 Yumi Sakemi, Ph. D. Lepidum Co. Ltd. E-Mail: yumi.sakemi@lepidum.co.jp From nobody Tue Jun 9 22:27:12 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A1DC83A0EF3 for ; Tue, 9 Jun 2020 22:27:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id T_EDFhYpFD_9 for ; Tue, 9 Jun 2020 22:27:07 -0700 (PDT) Received: from mail-lj1-x22d.google.com (mail-lj1-x22d.google.com [IPv6:2a00:1450:4864:20::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E3A4F3A0EF4 for ; Tue, 9 Jun 2020 22:27:06 -0700 (PDT) Received: by mail-lj1-x22d.google.com with SMTP id 9so846071ljc.8 for ; Tue, 09 Jun 2020 22:27:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4pVBuEbbizMopfsbLrD2jL6q2wzxLtsSGxCX73vLfvo=; b=W2EiZIwrG2HhqvXpUNF5bjk4D215TrDeY1shZIzjaNfQcvIy70MXJ89XeqQ/qeez6d oFB1FttAAJqasJ7GiseQ3BDGyQjhfY8Ph/RBpjQw1IIfFz/I1L047ut8DgB5FX5Bg9Dl Ph8lZjfAEITLBKjLXZl1qzkYGz35oG8XfA4xrUmm0Gm45aWtp5hnRoeuqkIBS8g0v2Bp SEOxND0zUKI8s7jX4SCQWstwa8ER+G17a9x26kzm0X9zbdgNkQQg6l3/zzrxklm2VYbt dmmV28CsdYyGboTS2Rn06hmUKH8zL4VN4rgf8ISeOq3N6w+HJXBSzflnohdYU8qKqzRS k/oQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4pVBuEbbizMopfsbLrD2jL6q2wzxLtsSGxCX73vLfvo=; b=FnXiQQQDaz1hDfVzBSPoFyJj2qmscQAmXPRE54+Tj9WgST3lljQrpJM8cF50M9BdM0 PbClGn2qj29tbJlci+0HcYePDGjnIqSQuPn4Ro2ztK4J52zzRAawwG9/ASCxyr2KJ4H4 nEToqsRscyhZ+3ACcgthgsnTL43caQfKpzcjjK8m9fAHiueP6TUEJ68M8F6O0CSPg9Ia RFIMU139RJh/h82Huvm0UzGp+5blr56e1OPuTa/zHVv5zjH5cIp4K8DbNreq4nGgPl3Y cN74W7iWJLUtEFcAeEAAzq0uZFYJlNwxi+z29drzjiCRXtVzztInR3rbYiJuQrBfG2cf puKw== X-Gm-Message-State: AOAM530dDAhmzQNXHJqs7JO0xpdkqpAoPSbPO0F+jM3+cITjnjOcKcwl LyatIa0iKzmGBtkgqLGG+0lJWX/yvjn2isGWJqw= X-Google-Smtp-Source: ABdhPJzaSmijRx51xP1kgLGg7bddu7dhyHJRMQF6rTVnxIgeDk0MIxbw88ltG5d3E2FAPj7Tnr/FGBmDKLhnl0eghGk= X-Received: by 2002:a2e:974a:: with SMTP id f10mr834933ljj.283.1591766824593; Tue, 09 Jun 2020 22:27:04 -0700 (PDT) MIME-Version: 1.0 References: <27FC2D65-658D-4E21-8484-E95927CCA1BF@nccgroup.com> In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Wed, 10 Jun 2020 08:26:53 +0300 Message-ID: To: Thomas Pornin Cc: "cfrg-chairs@ietf.org" , "crypto-panel@irtf.org" , "draft-irtf-cfrg-hash-to-curve.authors@ietf.org" Content-Type: multipart/alternative; boundary="000000000000252f8805a7b41821" Archived-At: Subject: Re: [Crypto-panel] EXTERNAL: Request for review: draft-irtf-cfrg-hash-to-curve-08 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Jun 2020 05:27:11 -0000 --000000000000252f8805a7b41821 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Thomas, Thanks a lot for your review! Kind regards, Stanislav =D1=81=D1=80, 10 =D0=B8=D1=8E=D0=BD=D1=8F 2020 =D0=B3. =D0=B2 01:42, Thomas= Pornin : > Here is my review. > > Hashing to Elliptic Curves > draft-irtf-cfrg-hash-to-curve-08 > > This draft is well-written. I have not verified that all pseudocode > and all test vectors are correct, but I did not see anything obviously > wrong. All proposed constructions make sense to me, from a cryptographic > point of view. > (I can reimplement stuff in Sage and check the results, but it will take > me more time, and I don't have a lot of it at the moment.) > > A generic remark: there is not a word about intellectual property > issues. I understand that this is a contentious issue, and that nobody > wants to assert that any specific method is patent-free. But I would > have expected a disclaimer somewhere. Otherwise, it feels weird that > Icart's map is not used as a possible method, since, when p^m =3D 2 mod 3= , > it should be faster than the simplified SWU (it uses one inversion > and one cube root, no extra is_square() or similar). > (Also, I heard some rumours that simplified SWU is also patented, > albeit with a less proactively enforced patent. The same rumours say > that the original Shallue-van de Woestijne method is patent-free. These > are only rumours.) > > Some other remarks, in appearance order: > > 2.1 (page 6): Maybe note that there are multiple choices for the > representation of GF(p^m) as polynomials: any irreducible modulus M (of > degree m) is fine (all finite fields with the same cardinal are > isomorphic to each other), but no M is more canonical than any other. > Choice of M is often driven by implementation performance (some M lead > to faster code). > > 2.1 (page 6): "elements are those points with coordinates (x, y) > satisfying the curve equation": some curves (in particular Weierstra=C3= =9F > and Montgomery curves) also include a special point-at-infinity which > does not have coordinates (x, y). > > 2.2.2 (page 8): "Section 10 discusses further." -> This lacks a > complement. Maybe: "See section 10 for further discussion."? > > 2.2.5 (page 9): Concatenation can be ambiguous, i.e. > "RO10" || x =3D=3D "RO1" || ("0" || x) > The actual usage (in section 5.3) uses explicit length bytes, and > also puts the tag _after_ the message, not before. It might be worth > mentioning here that the "concatenation" operation must be an > injective encoding of the tag and input x, with a forward reference > to section 5.3 for details (especially 5.3.4). > > 3.1 (page 12): The text fluidly and implicitly equates character strings > and byte strings. Java and C#/.NET developers might take issue with > that. This might be worth an explicit sentence here; otherwise, some > developer somewhere will use UTF-16 (and calling it "Unicode" in pure > Microsoft fashion), others will add a terminating zero, or use > big-endian, or add a BOM, or any combination thereof, and much confusion > and interoperability sorrow will ensue. > > 4 (page 12): "SHOULD be constant time" -> "SHOULD be constant-time". > > Also, the traditional acception of "constant-time" covers more than > independence of the execution time with regard to the input values: > > - It really is independence with regard to all secret values, including > intermediate values and outputs, not just inputs. > > - Constant-time code should not leave any trace that can be leveraged > with time-based measurements. For instance, in a flush+reload > attack, the victim's execution time is independent of the secret > values; the timing measurement is on a reload operation performed by > the attacker themselves, _after_ the victim has finished. Code which > is vulnerable to a flush+reload attack may still be "constant-time" > in the sense described by section 4, but would not be > "constant-time" in the usual sense. > > I think a more generic definition of "constant-time" is needed here. I > suggest the following: "For security, implementations of these functions > SHOULD be constant-time, i.e. none of the possible timing measurements > that can be effected by an adversary should depend on secret values. In > particular, execution time but also memory access patterns should be > independent of any secret input, output or intermediate value." > > 4 (page 13): "there exist two roots of x in the field F whenever x is > square." -> except when x =3D 0. Zero has a unique square root in F. > > 4 (page 13): "To implement inv0 in constant time, compute inv0(x) :=3D > x^(q-2)" -> Depending on the field, there may be (much) faster ways, in > particular in field extensions (e.g. in Curve9767, inversion cost is > about 6M, while Fermat's Little Theorem would bring it to about 300M!). > Even in prime fields, a constant-time extended binary GCD will typically > have cost between 40M and 100M for inversion (but some specific care is > required to ensure that inv0(0) =3D 0). However, it must be said that the > exponentiation is a simple to implement in constant-time if > constant-time multiplication is available (and it should, otherwise the > whole thing is hopeless). > > 4 (page 13): It may be worth mentioning that I2OSP and OS2IP, as defined > in PKCS#1 (aka RFC 8017), are big-endian. In particular, most of the > curve25519/edwards25519 ecosystem tends to be little-endian, so that's a > plausible source of mistakes. > > 5 (page 5): The draft uses "SHAKE-128" as the name of SHAKE with a > 128-bit output, but the NIST specification (FIPS 202) defines "SHAKE128" > without the dash. This impacts the use of the name in IDs (e.g. in > section 8.10, page 43). > > 5.2 (page 17): Maybe note somewhere that implementation of "mod p" with > constant-time code is not completely obvious. Using Euclidean division > is not constant-time. Most constant-time implementations use Barrett > reduction, although some use Montgomery instead. > > 5.2 (page 17): When mapping to a field GF(p^m) with a relatively small p > (e.g. less 32 bits), then the proposed hash_to_field() is rather > wasteful in hash output. For such fields, generating k+log2(p^m) bits > and then repeatedly dividing that big integer by p will be faster, > especially when working on embedded systems. On an ARM Cortex M0+, with > field GF(9767^19), I can get a map_to_field() in about 20000 cycles, > while each invocation of the SHAKE internal function costs 34000 cycles > and the proposed method would require three invocations of that internal > function to get enough bytes. > > 5.3.1 (page 18): I needed to verify, but "Damgaard" is indeed the > correct ASCII-compatible alternative spelling of "Damg=C3=A5rd". Nice job= ! > > 5.3.1 (page 19): Definition of b_in_bytes uses ceil(), i.e. accounts for > the possibility that H outputs something else than an integral number > of bytes. But if that is the case, the "uniform_bytes" are not uniform! > It would be better to make it an explicit requirement that the output > length of H, in bits, MUST be a multiple of 8. > > 5.3.1 (page 19): r_in_bytes is said to be the "block size" of a hash > function, but that notion has not been defined. Generally speaking, some > hash functions do not have a well-defined "block size". You may fall > back here on HMAC, since HMAC also needs a "block size"; for instance, > FIPS 202 defines the block size of SHA3-256 to be 136 bytes. > > 5.3.4 (page 21): "prepended or appended" -> technically, "prepended" is > an actual English word, but not with that meaning. It means something > like "premeditate". I suggest: "an encoding of DST MUST be added either > as a prefix or suffix to the input to each invocation of H (a suffix is > the RECOMMENDED approach)." > > 6.6.1 (page 25): It may be worth mentioning that some of the computed > values are actually constants, e.g. tv4 (step 5) or -4*g(Z)/(3*Z^2+4*A) > (used in step 10) (this is applied in appendix D.1). In effect, the > "expensive" operations in this algorithm that cannot be precomputed are > 1 inv0(), 2 is_square(), and 1 sqrt(). This makes it apparent that the > speed advantage of the simplified SWU map is that it saves 1 is_square() > call, i.e. about 25% of the overall cost if inv0(), is_square() and > sqrt() are implemented with modular exponentiations. > > 10 (page 45): for password hashing, discussion points to PBKDF2 and > Scrypt. It might be worth mentioning Argon2, for which there is an > in-progress draft: > https://datatracker.ietf.org/doc/draft-irtf-cfrg-argon2/ > > 10 (page 45): "the nature of the leakage and the appropriate defense > depends on the application." -> should be "depend" here. > > E.1 (page 75): It may be worth mentioning here that the random oracle > mapping requires doing two map_to_curve() and adding the results > together, and this is, in itself, enough to make projective coordinates > useful. In particular, when using a Weierstra=C3=9F curve, you must take = into > account the (remote) possibility that the two points may be the same, > therefore requiring a constant-time generic point addition routine; > there are complete formulas for Weierstra=C3=9F curves in homogenous > projective coordinates. > > G.5 (page 96): "Other optimizations of this type are possible in other > even-order extension fields" -> You can also have similar optimizations > in any extension field. In general, for an odd p and an arbitrary m > 1: > > (p-1)/2 =3D ((p-1)/2)*(1+p+p^2+...+p^(m-1)) > > Thus, if we call r =3D 1+p+p^2+...+p^(m-1), we have: > > x^((p-1)/2) =3D (x^r)^((p-1)/2) > > This can be computed very efficiently because: > > - x^r is an element of GF(p) (indeed, (x^r)^(p-1) =3D 1 for any x !=3D = 0, > and only elements of GF(p) are roots of the polynomial X^(p-1)-1 in > GF(p^m)[X]), so the final exponentiation by (p-1)/2 can be done with > only values in the small field GF(p). > > - x^r can be computed in log(m) multiplications and log(m) applications > of the Frobenius operator: > > t1 =3D x * x^p =3D x^(1+p) > t2 =3D t1 * t1^(p^2) =3D x^(1+p+p^2+p^3) > t3 =3D t2 * t2^(p^4) =3D x^(1+p+p^2+p^3+p^4+p^5+p^6+p^7) > ... > > The Frobenius operator itself is typically as efficient, or even > faster, as a multiplication, since it is a linear transform over the > source polynomial (seen as a vector in a space of dimension m over > GF(p)). If GF(p^m) was defined modulo M =3D X^m-c for some constant c= , > then the Frobenius operator is a simple per-coefficient > multiplication, i.e. a cost close to that of an addition in GF(p^m). > > The algorithm in appendix G.5 is a simple sub-case of this, when m =3D 2. > > > Thomas > > > -------------------------------------------------------------------------= --------------------------- > From: Crypto-panel on behalf of > "Stanislav V. Smyshlyaev" > Date: Friday, June 5, 2020 at 08:11 > To: Thomas Pornin > Cc: "crypto-panel@irtf.org" , " > draft-irtf-cfrg-hash-to-curve.authors@ietf.org" < > draft-irtf-cfrg-hash-to-curve.authors@ietf.org>, "cfrg-chairs@ietf.org" < > cfrg-chairs@ietf.org> > Subject: Re: [Crypto-panel] EXTERNAL: Request for review: > draft-irtf-cfrg-hash-to-curve-08 > > Great, many thanks, Thomas! > > Stanislav (for Chairs) > > On Fri, 5 Jun 2020 at 14:53, Thomas Pornin 40nccgroup.com@dmarc.ietf.org> wrote: > I can do that. > > Thomas > > From: Crypto-panel on behalf of > "Stanislav V. Smyshlyaev" > Date: Friday, June 5, 2020 at 00:17 > To: "mailto:crypto-panel@irtf.org" > Cc: "mailto:draft-irtf-cfrg-hash-to-curve.authors@ietf.org" draft-irtf-cfrg-hash-to-curve.authors@ietf.org>, "mailto: > cfrg-chairs@ietf.org" > Subject: EXTERNAL: [Crypto-panel] Request for review: > draft-irtf-cfrg-hash-to-curve-08 > > Dear Crypto Panel members, > > Alexey, Nick and I would like to ask Crypto Review Panel members about th= e > review(s) of draft-irtf-cfrg-hash-to-curve-08. > > The document specifies a number of algorithms for encoding or hashing an > arbitrary string to a point on an elliptic curve. > > > Can we have any volunteers, please? > > > Best regards, > Stanislav (on behalf of chairs) > _______________________________________________ > Crypto-panel mailing list > mailto:Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > > --000000000000252f8805a7b41821 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Thomas,

=
Thanks a lot for your review!

=
Kind regards,
Stanislav

= =D1=81=D1=80, 10 =D0=B8=D1=8E=D0=BD=D1=8F 2020 =D0=B3. =D0=B2 01:42, Thomas= Pornin <thomas.pornin@ncc= group.com>:
Here is my revie= w.

Hashing to Elliptic Curves
draft-irtf-cfrg-hash-to-curve-08

This draft is well-written. I have not verified that all pseudocode
and all test vectors are correct, but I did not see anything obviously
wrong. All proposed constructions make sense to me, from a cryptographic point of view.
(I can reimplement stuff in Sage and check the results, but it will take me more time, and I don't have a lot of it at the moment.)

A generic remark: there is not a word about intellectual property
issues. I understand that this is a contentious issue, and that nobody
wants to assert that any specific method is patent-free. But I would
have expected a disclaimer somewhere. Otherwise, it feels weird that
Icart's map is not used as a possible method, since, when p^m =3D 2 mod= 3,
it should be faster than the simplified SWU (it uses one inversion
and one cube root, no extra is_square() or similar).
(Also, I heard some rumours that simplified SWU is also patented,
albeit with a less proactively enforced patent. The same rumours say
that the original Shallue-van de Woestijne method is patent-free. These
are only rumours.)

Some other remarks, in appearance order:

2.1 (page 6): Maybe note that there are multiple choices for the
representation of GF(p^m) as polynomials: any irreducible modulus M (of
degree m) is fine (all finite fields with the same cardinal are
isomorphic to each other), but no M is more canonical than any other.
Choice of M is often driven by implementation performance (some M lead
to faster code).

2.1 (page 6): "elements are those points with coordinates (x, y)
satisfying the curve equation": some curves (in particular Weierstra= =C3=9F
and Montgomery curves) also include a special point-at-infinity which
does not have coordinates (x, y).

2.2.2 (page 8): "Section 10 discusses further." -> This lacks = a
complement. Maybe: "See section 10 for further discussion."?

2.2.5 (page 9): Concatenation can be ambiguous, i.e.
=C2=A0 =C2=A0"RO10" || x =3D=3D "RO1" || ("0"= || x)
The actual usage (in section 5.3) uses explicit length bytes, and
also puts the tag _after_ the message, not before. It might be worth
mentioning here that the "concatenation" operation must be an
injective encoding of the tag and input x, with a forward reference
to section 5.3 for details (especially 5.3.4).

3.1 (page 12): The text fluidly and implicitly equates character strings and byte strings. Java and C#/.NET developers might take issue with
that. This might be worth an explicit sentence here; otherwise, some
developer somewhere will use UTF-16 (and calling it "Unicode" in = pure
Microsoft fashion), others will add a terminating zero, or use
big-endian, or add a BOM, or any combination thereof, and much confusion and interoperability sorrow will ensue.

4 (page 12): "SHOULD be constant time" -> "SHOULD be cons= tant-time".

Also, the traditional acception of "constant-time" covers more th= an
independence of the execution time with regard to the input values:

=C2=A0 - It really is independence with regard to all secret values, includ= ing
=C2=A0 =C2=A0 intermediate values and outputs, not just inputs.

=C2=A0 - Constant-time code should not leave any trace that can be leverage= d
=C2=A0 =C2=A0 with time-based measurements. For instance, in a flush+reload=
=C2=A0 =C2=A0 attack, the victim's execution time is independent of the= secret
=C2=A0 =C2=A0 values; the timing measurement is on a reload operation perfo= rmed by
=C2=A0 =C2=A0 the attacker themselves, _after_ the victim has finished. Cod= e which
=C2=A0 =C2=A0 is vulnerable to a flush+reload attack may still be "con= stant-time"
=C2=A0 =C2=A0 in the sense described by section 4, but would not be
=C2=A0 =C2=A0 "constant-time" in the usual sense.

I think a more generic definition of "constant-time" is needed he= re. I
suggest the following: "For security, implementations of these functio= ns
SHOULD be constant-time, i.e. none of the possible timing measurements
that can be effected by an adversary should depend on secret values. In
particular, execution time but also memory access patterns should be
independent of any secret input, output or intermediate value."

4 (page 13): "there exist two roots of x in the field F whenever x is<= br> square." -> except when x =3D 0. Zero has a unique square root in F= .

4 (page 13): "To implement inv0 in constant time, compute inv0(x) :=3D=
x^(q-2)" -> Depending on the field, there may be (much) faster ways= , in
particular in field extensions (e.g. in Curve9767, inversion cost is
about 6M, while Fermat's Little Theorem would bring it to about 300M!).=
Even in prime fields, a constant-time extended binary GCD will typically have cost between 40M and 100M for inversion (but some specific care is
required to ensure that inv0(0) =3D 0). However, it must be said that the exponentiation is a simple to implement in constant-time if
constant-time multiplication is available (and it should, otherwise the
whole thing is hopeless).

4 (page 13): It may be worth mentioning that I2OSP and OS2IP, as defined in PKCS#1 (aka RFC 8017), are big-endian. In particular, most of the
curve25519/edwards25519 ecosystem tends to be little-endian, so that's = a
plausible source of mistakes.

5 (page 5): The draft uses "SHAKE-128" as the name of SHAKE with = a
128-bit output, but the NIST specification (FIPS 202) defines "SHAKE12= 8"
without the dash. This impacts the use of the name in IDs (e.g. in
section 8.10, page 43).

5.2 (page 17): Maybe note somewhere that implementation of "mod p"= ; with
constant-time code is not completely obvious. Using Euclidean division
is not constant-time. Most constant-time implementations use Barrett
reduction, although some use Montgomery instead.

5.2 (page 17): When mapping to a field GF(p^m) with a relatively small p (e.g. less 32 bits), then the proposed hash_to_field() is rather
wasteful in hash output. For such fields, generating k+log2(p^m) bits
and then repeatedly dividing that big integer by p will be faster,
especially when working on embedded systems. On an ARM Cortex M0+, with
field GF(9767^19), I can get a map_to_field() in about 20000 cycles,
while each invocation of the SHAKE internal function costs 34000 cycles
and the proposed method would require three invocations of that internal function to get enough bytes.

5.3.1 (page 18): I needed to verify, but "Damgaard" is indeed the=
correct ASCII-compatible alternative spelling of "Damg=C3=A5rd". = Nice job!

5.3.1 (page 19): Definition of b_in_bytes uses ceil(), i.e. accounts for the possibility that H outputs something else than an integral number
of bytes. But if that is the case, the "uniform_bytes" are not un= iform!
It would be better to make it an explicit requirement that the output
length of H, in bits, MUST be a multiple of 8.

5.3.1 (page 19): r_in_bytes is said to be the "block size" of a h= ash
function, but that notion has not been defined. Generally speaking, some hash functions do not have a well-defined "block size". You may f= all
back here on HMAC, since HMAC also needs a "block size"; for inst= ance,
FIPS 202 defines the block size of SHA3-256 to be 136 bytes.

5.3.4 (page 21): "prepended or appended" -> technically, "= ;prepended" is
an actual English word, but not with that meaning. It means something
like "premeditate". I suggest: "an encoding of DST MUST be a= dded either
as a prefix or suffix to the input to each invocation of H (a suffix is
the RECOMMENDED approach)."

6.6.1 (page 25): It may be worth mentioning that some of the computed
values are actually constants, e.g. tv4 (step 5) or -4*g(Z)/(3*Z^2+4*A)
(used in step 10) (this is applied in appendix D.1). In effect, the
"expensive" operations in this algorithm that cannot be precomput= ed are
1 inv0(), 2 is_square(), and 1 sqrt(). This makes it apparent that the
speed advantage of the simplified SWU map is that it saves 1 is_square() call, i.e. about 25% of the overall cost if inv0(), is_square() and
sqrt() are implemented with modular exponentiations.

10 (page 45): for password hashing, discussion points to PBKDF2 and
Scrypt. It might be worth mentioning Argon2, for which there is an
in-progress draft:
=C2=A0 =C2=A0https://datatracker.ietf.org/do= c/draft-irtf-cfrg-argon2/

10 (page 45): "the nature of the leakage and the appropriate defense depends on the application." -> should be "depend" here.<= br>
E.1 (page 75): It may be worth mentioning here that the random oracle
mapping requires doing two map_to_curve() and adding the results
together, and this is, in itself, enough to make projective coordinates
useful. In particular, when using a Weierstra=C3=9F curve, you must take in= to
account the (remote) possibility that the two points may be the same,
therefore requiring a constant-time generic point addition routine;
there are complete formulas for Weierstra=C3=9F curves in homogenous
projective coordinates.

G.5 (page 96): "Other optimizations of this type are possible in other=
even-order extension fields" -> You can also have similar optimizat= ions
in any extension field. In general, for an odd p and an arbitrary m > 1:=

=C2=A0 =C2=A0 =C2=A0 (p-1)/2 =3D ((p-1)/2)*(1+p+p^2+...+p^(m-1))

Thus, if we call r =3D 1+p+p^2+...+p^(m-1), we have:

=C2=A0 =C2=A0 =C2=A0 x^((p-1)/2) =3D (x^r)^((p-1)/2)

This can be computed very efficiently because:

=C2=A0 - x^r is an element of GF(p) (indeed, (x^r)^(p-1) =3D 1 for any x != =3D 0,
=C2=A0 =C2=A0 and only elements of GF(p) are roots of the polynomial X^(p-1= )-1 in
=C2=A0 =C2=A0 GF(p^m)[X]), so the final exponentiation by (p-1)/2 can be do= ne with
=C2=A0 =C2=A0 only values in the small field GF(p).

=C2=A0 - x^r can be computed in log(m) multiplications and log(m) applicati= ons
=C2=A0 =C2=A0 of the Frobenius operator:

=C2=A0 =C2=A0 =C2=A0 t1 =3D x * x^p =3D x^(1+p)
=C2=A0 =C2=A0 =C2=A0 t2 =3D t1 * t1^(p^2) =3D x^(1+p+p^2+p^3)
=C2=A0 =C2=A0 =C2=A0 t3 =3D t2 * t2^(p^4) =3D x^(1+p+p^2+p^3+p^4+p^5+p^6+p^= 7)
=C2=A0 =C2=A0 =C2=A0 ...

=C2=A0 =C2=A0 The Frobenius operator itself is typically as efficient, or e= ven
=C2=A0 =C2=A0 faster, as a multiplication, since it is a linear transform o= ver the
=C2=A0 =C2=A0 source polynomial (seen as a vector in a space of dimension m= over
=C2=A0 =C2=A0 GF(p)). If GF(p^m) was defined modulo M =3D X^m-c for some co= nstant c,
=C2=A0 =C2=A0 then the Frobenius operator is a simple per-coefficient
=C2=A0 =C2=A0 multiplication, i.e. a cost close to that of an addition in G= F(p^m).

The algorithm in appendix G.5 is a simple sub-case of this, when m =3D 2.

Thomas

---------------------------------------------------------------------------= -------------------------
From: Crypto-panel <crypto-panel-bounces@irtf.org> on behalf of "Sta= nislav V. Smyshlyaev" <smyshsv@gmail.com>
Date: Friday, June 5, 2020 at 08:11
To: Thomas Pornin <thomas.pornin=3D40nccgroup.com@dmarc.ietf.org>
Cc: "crypto= -panel@irtf.org" <crypto-panel@irtf.org>, "draft-irtf-cfrg= -hash-to-curve.authors@ietf.org" <draft-irtf-cfrg-hash= -to-curve.authors@ietf.org>, "cfrg-chairs@ietf.org" <cfrg-chairs@ietf.org>
Subject: Re: [Crypto-panel] EXTERNAL: Request for review: draft-irtf-cfrg-h= ash-to-curve-08

Great, many thanks, Thomas!

Stanislav (for Chairs)

On Fri, 5 Jun 2020 at 14:53, Thomas Pornin <thomas.pornin=3Dmailto:40nccgroup.co= m@dmarc.ietf.org> wrote:
I can do that.
=C2=A0
Thomas
=C2=A0
From: Crypto-panel <mailto:crypto-panel-bounces@irtf.org> on behalf of &q= uot;Stanislav V. Smyshlyaev" <mailto:smyshsv@gmail.com>
Date: Friday, June 5, 2020 at 00:17
To: "mailto:crypto-panel@irtf.org" <mailto:crypto-panel@irtf.org>
Cc: "mailto:draft-irtf-cfrg-hash-to-curve.authors@ietf.org" <mailto:draft-irtf-cfrg-hash-to-curve.authors@ietf.org<= /a>>, "mailto:cfrg-chairs@ietf.org" <mailto:cfrg-chairs@ietf.org>
Subject: EXTERNAL: [Crypto-panel] Request for review: draft-irtf-cfrg-hash-= to-curve-08
=C2=A0
Dear Crypto Panel members,=C2=A0
=C2=A0
Alexey, Nick and I would like to ask Crypto Review Panel members about the = review(s) of draft-irtf-cfrg-hash-to-curve-08.
=C2=A0
The document specifies a number of algorithms for encoding or hashing an ar= bitrary string to a point on an elliptic curve.=C2=A0
=C2=A0
=C2=A0
Can we have any volunteers, please?
=C2=A0
=C2=A0
Best regards,
Stanislav (on behalf of chairs)
_______________________________________________
Crypto-panel mailing list
mailto:Crypto-pa= nel@irtf.org
https://www.irtf.org/mailman/listinfo/crypto-panel=

--000000000000252f8805a7b41821-- From nobody Thu Jun 11 10:57:18 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F6BA3A0D4B for ; Thu, 11 Jun 2020 10:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vgw3ZWCOGT1s for ; Thu, 11 Jun 2020 10:57:15 -0700 (PDT) Received: from mail-lj1-x230.google.com (mail-lj1-x230.google.com [IPv6:2a00:1450:4864:20::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBA713A0D48 for ; Thu, 11 Jun 2020 10:57:14 -0700 (PDT) Received: by mail-lj1-x230.google.com with SMTP id 9so7998140ljc.8 for ; Thu, 11 Jun 2020 10:57:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VWufz+9wD2MKdr9Lyskb5A22bDLwQhM3DWmTwxTmk9s=; b=lh2YL4WiUl5m+HCZttEQP2Gp1KwbD5QXG4RyaOzMWPg5f/iyYN3UZ40m9XyoRRuLVx VQVX9bBR6E9UAhQyVDvTftevKE181bp0CsqcrJZyW7u0oKiRIVttN3DlafAUFvcZI5Ex OJPI3skmnIc6YbY1kXGCrK4MJQtjBU+esWsWj/1JkbhQv+2GM7IC7Nrhy3VkHMIk61ZE dD9nXQTl8WvGMj+hjyFlDPpBJpju2bNiAojMgls6VsdumcuEuEIGM4iTPGhqcnz/a/Ci XOyCfff6Y3w5gNVNcsvPr8KwPKvPFAOKXxhedQ3UJ4dB1fItHxrUNBDiFGfWPcf3g/bC 3znQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VWufz+9wD2MKdr9Lyskb5A22bDLwQhM3DWmTwxTmk9s=; b=qzfpIEMcIOeRMaAD5g9PwlHC/8QO26oQ7HtEiYgSux4xVnlB/dyKPNmKexHGDo1QgL 3jwiR2hl2PuohqEvoz9C8MnpDLxoKV/PKv/0ssM3daP/8Nr+G61IbVIaSeH/YL607fwl sYVKU4v8oAigdUX7F55jhhsb7Tkn+kpumpt3FfzBRbEFBu/151S21HuV/hmkvmo+ewSe bRd5ghZChNBvC/qdTFGBjlak6dnqJh4pnx55eUADSC/3rjRppqPKzK83SQd9Fsk+hli6 B+DmXoeJFj6kz5lR9CrwfHvJF/tV5i77oz52fz4oN8MPDhVyXzoe67WpsMKV+G8kXeUN kIXQ== X-Gm-Message-State: AOAM532mzfvKHmVE+mIarGa6LTi0k+HAOo9KaXS26DT2YqA+METIc3Yh tCljbvSL9Npdm1Qz645IyszMRUlGN5d5HnNrZjZmDA== X-Google-Smtp-Source: ABdhPJxm+6x8hUDXbjW6s/KXaxSB/w9W0dTDxZ0mxLyDoAFfyYitzpX7OKegyQg9kki/QvxPNNgcajhubwH8c7eleKA= X-Received: by 2002:a2e:8347:: with SMTP id l7mr5147957ljh.182.1591898232729; Thu, 11 Jun 2020 10:57:12 -0700 (PDT) MIME-Version: 1.0 References: <20200318130152.57FD7F4071D@rfc-editor.org> In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Thu, 11 Jun 2020 20:57:01 +0300 Message-ID: To: "crypto-panel@irtf.org" Cc: "cfrg-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000ae343d05a7d2b044" Archived-At: Subject: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024) X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 17:57:17 -0000 --000000000000ae343d05a7d2b044 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Crypto Review Panel members, There is a need to validate the following errata: https://www.rfc-editor.org/errata/eid6024 Any volunteers? Regards, CFRG chairs ---------- =D0=9F=D0=B5=D1=80=D0=B5=D1=81=D1=8B=D0=BB=D0=B0=D0=B5=D0=BC=D0= =BE=D0=B5 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B5 --------- =D0=9E=D1=82: Colin Perkins =D0=94=D0=B0=D1=82=D0=B0: =D1=81=D0=B1, 6 =D0=B8=D1=8E=D0=BD=D1=8F 2020 =D0= =B3. =D0=B2 16:03 =D0=A2=D0=B5=D0=BC=D0=B0: Fwd: [irsg] [Technical Errata Reported] RFC8391 (= 6024) =D0=9A=D0=BE=D0=BC=D1=83: Hi CFRG chairs, Can you discuss, and review with the RG if necessary, and let me know if the following errata should be marked as verified. Thanks, Colin Begin forwarded message: *From: *RFC Errata System *Subject: **[irsg] [Technical Errata Reported] RFC8391 (6024)* *Date: *18 March 2020 at 13:01:52 GMT *To: *ietf@huelsing.net, dbutin@cdc.informatik.tu-darmstadt.de, ietf@gazdag.de, ietf@joostrijneveld.nl, mohaisen@ieee.org, irsg@irtf.org *Cc: *ietf@huelsing.net, rfc-editor@rfc-editor.org The following errata report has been submitted for RFC8391, "XMSS: eXtended Merkle Signature Scheme". -------------------------------------- You may review the report below and at: https://www.rfc-editor.org/errata/eid6024 -------------------------------------- Type: Technical Reported by: Andreas H=C3=BClsing Section: 5 Original Text ------------- This section provides basic parameter sets that are assumed to cover most relevant applications. Parameter sets for two classical security levels are defined. Parameters with n =3D 32 provide a classical security level o= f 256 bits. Parameters with n =3D 64 provide a classical security level of 5= 12 bits. Considering quantum-computer-aided attacks, these output sizes yield post-quantum security of 128 and 256 bits, respectively. Corrected Text -------------- This section provides basic parameter sets that are assumed to cover most relevant applications. Parameter sets for two classical security levels are defined using the cryptographic functions SHA2 and SHAKE. Parameters with SHA2 and n =3D 32 provide a classical security level of 256 bits. Parameter= s with SHA2 and n =3D 64 provide a classical security level of 512 bits. Considering quantum-computer-aided attacks, these parameters yield post-quantum security of 128 and 256 bits, respectively. Parameters with SHAKE and n =3D 32 provide a classical security level of 128 bits. Parameters with SHAKE and n =3D 64 provide a classical security level of 25= 6 bits. Considering quantum-computer-aided attacks, these parameters yield post-quantum security of 86 and 170 bits, respectively. Notes ----- Traditionally, a hash function with n-bit outputs is assumed to have n-bit security against classical preimage and second-preimage attacks, and n/2-bit security against classical collision attacks. For adversaries with access to a quantum computer, these bounds change to n/2 and n/3 bits when only counting queries to the hash function. This also applies to SHA2 and SHA3. In contrast, SHAKE follows a different reasoning. SHAKE with an internal state of n bits and an output length of n bits achieves n/2 bit security against classical preimage, second-preimage and collision attacks. For quantum attacks security changes to n/3 bits. The reason is that SHAKE allows for meet-in-the-middle preimage attacks that reduce to a collision search on the internal state. The same applies for SHA3 but for SHA3 a bigger internal state is used. In consequence, SHAKE-128 cannot provide more security than NIST post-quantum security level II (Any attack that breaks the relevant security definition must require computational resources comparable to or greater than those required for collision search on a 256-bit hash function (e.g. SHA256 / SHA3-256)). Instructions: ------------- This erratum is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party can log in to change the status and edit the report, if necessary. -------------------------------------- RFC8391 (draft-irtf-cfrg-xmss-hash-based-signatures-12) -------------------------------------- Title : XMSS: eXtended Merkle Signature Scheme Publication Date : May 2018 Author(s) : A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A. Mohaisen Category : INFORMATIONAL Source : Crypto Forum Research Group Area : N/A Stream : IRTF Verifying Party : IRSG --000000000000ae343d05a7d2b044 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Crypto Review Panel members,

There is a need to validate the foll= owing errata:
Any volunteers?

Regards,
CFRG chairs


=

---------- =D0=9F=D0=B5=D1=80=D0=B5=D1=81=D1=8B=D0=BB=D0=B0=D0=B5=D0= =BC=D0=BE=D0=B5 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B5 ----= -----
=D0=9E=D1=82: Coli= n Perkins <csp@csperkins.org>
=D0=94=D0=B0=D1=82=D0=B0: =D1=81=D0= =B1, 6 =D0=B8=D1=8E=D0=BD=D1=8F 2020 =D0=B3. =D0=B2 16:03
=D0=A2=D0=B5= =D0=BC=D0=B0: Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024)
=D0= =9A=D0=BE=D0=BC=D1=83: <cfrg-ch= airs@ietf.org>


Hi CFRG chairs,

Can you = discuss, and review with the RG if necessary, and let me know =C2=A0if the = following errata should be marked as verified.

Tha= nks,
Colin



Begin forwarded message:

= From: RFC Errata System <rfc-editor@rfc-editor.org&g= t;
Subject: [irsg] [Technical Errata Reported] RFC8391 (6024)
<= /div>
Date: 18 March 2020 at 13:01:52= GMT
=
The following errata repor= t has been submitted for RFC8391,
"XMSS: eXtended Merkle Signature = Scheme".

--------------------------------------
You may revi= ew the report below and at:
https://www.rfc-editor.org/errata/eid6024
--------------------------------------
Type: Technical
Reported= by: Andreas H=C3=BClsing <ietf@huelsing.net>

Section: 5

Original Tex= t
-------------
This section provides basic parameter sets that are a= ssumed to cover most relevant applications.=C2=A0 Parameter sets for two cl= assical security levels are defined.=C2=A0 Parameters with n =3D 32 provide= a classical security level of 256 bits.=C2=A0 Parameters with n =3D 64 pro= vide a classical security level of 512 bits.=C2=A0 Considering quantum-comp= uter-aided attacks, these output sizes yield post-quantum security of 128 a= nd 256 bits, respectively.

Corrected Text
--------------
This = section provides basic parameter sets that are assumed to cover most releva= nt applications. Parameter sets for two classical security levels are defin= ed using the cryptographic functions SHA2 and SHAKE.=C2=A0 Parameters with = SHA2 and n =3D 32 provide a classical security level of 256 bits. Parameter= s with SHA2 and n =3D 64 provide a classical security level of 512 bits.=C2= =A0 Considering quantum-computer-aided attacks, these parameters yield post= -quantum security of 128 and 256 bits, respectively. Parameters with SHAKE = and n =3D 32 provide a classical security level of 128 bits.=C2=A0 Paramete= rs with SHAKE and n =3D 64 provide a classical security level of 256 bits.= =C2=A0 Considering quantum-computer-aided attacks, these parameters yield p= ost-quantum security of 86 and 170 bits, respectively.

Notes
---= --
Traditionally, a hash function with n-bit outputs is assumed to have = n-bit security against classical preimage and second-preimage attacks, and = n/2-bit security against classical collision attacks. For adversaries with = access to a quantum computer, these bounds change to n/2 and n/3 bits when = only counting queries to the hash function. This also applies to SHA2 and S= HA3. In contrast, SHAKE follows a different reasoning. SHAKE with an intern= al state of n bits and an output length of n bits achieves n/2 bit security= against classical preimage, second-preimage and collision attacks. For qua= ntum attacks security changes to n/3 bits. The reason is that SHAKE allows = for meet-in-the-middle preimage attacks that reduce to a collision search o= n the internal state. The same applies for SHA3 but for SHA3 a bigger inter= nal state is used.

In consequence, SHAKE-128 cannot provide more se= curity than NIST post-quantum security level II (Any attack that breaks the= relevant security definition must require computational resources comparab= le to or greater than those required for collision search on a 256-bit hash= function (e.g. SHA256 / SHA3-256)).

Instructions:
-------------<= br>This erratum is currently posted as "Reported". If necessary, = please
use "Reply All" to discuss whether it should be verifie= d or
rejected. When a decision is reached, the verifying party =C2=A0can log in to change the status and edit the report, if necessary.
--------------------------------------
RFC8391 (draft-irtf-cfrg-xmss-ha= sh-based-signatures-12)
--------------------------------------
Title = =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0: XMSS: eXtended Merkle Signature Scheme
Publication Date =C2= =A0=C2=A0=C2=A0: May 2018
Author(s) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0: A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A= . Mohaisen
Category =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0: INFORMATIONAL
Source =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: Crypto Forum Research Group<= br>Area =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0: N/A
Stream =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: IRTF
Verifying Party =C2= =A0=C2=A0=C2=A0=C2=A0: IRSG



--000000000000ae343d05a7d2b044-- From nobody Thu Jun 11 12:12:44 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F3E7C3A0528 for ; Thu, 11 Jun 2020 12:12:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.596 X-Spam-Level: X-Spam-Status: No, score=-9.596 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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=c9OD/BkI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=mzzA8GVZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yLAE7owuTQZI for ; Thu, 11 Jun 2020 12:12:32 -0700 (PDT) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 05A0B3A03EA for ; Thu, 11 Jun 2020 12:12:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=24468; q=dns/txt; s=iport; t=1591902752; x=1593112352; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=oGOHJgviZaG91tfLyd9VEK6sRryj4rc4X30+UbScrgc=; b=c9OD/BkIbiugkCaayPCOZcN/893937roJOE/UJ0L8sBCbhg0svcqSeBh 7ukKm80KKmhTTuQZMUwti04tKWDauN3qyyoakuvGd3lbhnoToU/skCxMo kjdlHxGa6woYD3grlasSOOpdJ+4YyqPZYdlbdOic1mLW+bHjv1O46uWAq Q=; IronPort-PHdr: =?us-ascii?q?9a23=3AXJ0OPhMiAYiR7RMIQz8l6mtXPHoupqn0MwgJ65?= =?us-ascii?q?Eul7NJdOG58o//OFDEvKwx3lDMVITfrflDjrmev6PhXDkG5pCM+DAHfYdXXh?= =?us-ascii?q?AIwcMRg0Q7AcGDBEG6SZyibyEzEMlYElMw+Xa9PBtaHc//YxvZpXjhpTIXEw?= =?us-ascii?q?/0YAxyIOm9E4XOjsOxgua1/ZCbYwhBiDenJ71oKxDjpgTKvc5Qioxneas=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAADDgOJe/5tdJa1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQGCCoEjLykpB29YLywKhBqBXYFpA40?= =?us-ascii?q?6k2qEaIFCgRADVQsBAQEMAQEjCgIEAQGDDoE2AheCCwIkOBMCAwEBCwEBBQE?= =?us-ascii?q?BAQIBBgRthVsMhXIBAQEBAxIRChMBATcBDwIBBgIRAwEBASgDAgICMBQJCAI?= =?us-ascii?q?EAQ0FCBqDBYF+TQMuAQ6YGJBnAoE5iGF2gTKDAQEBBYUpGIIOAwaBOAGCY4c?= =?us-ascii?q?bgQiBRBqBQT+BEUOCTT6BBIMQPB4NCYJeM4ItjxEngmmGNoMGmF4KglmZNYJ?= =?us-ascii?q?viRiFFo0/kROeKAIEAgQFAg4BAQWBaiKBVnAVGoMKUBcCDY4eCwEXgQIBCIJ?= =?us-ascii?q?DhRSFQnQCNQIGAQcBAQMJfI0VLYEGAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,500,1583193600"; d="scan'208,217";a="505630920" Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jun 2020 19:12:30 +0000 Received: from XCH-RCD-001.cisco.com (xch-rcd-001.cisco.com [173.37.102.11]) by rcdn-core-4.cisco.com (8.15.2/8.15.2) with ESMTPS id 05BJCU8V029745 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Jun 2020 19:12:30 GMT Received: from xhs-rtp-002.cisco.com (64.101.210.229) by XCH-RCD-001.cisco.com (173.37.102.11) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 11 Jun 2020 14:12:30 -0500 Received: from xhs-rtp-001.cisco.com (64.101.210.228) by xhs-rtp-002.cisco.com (64.101.210.229) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 11 Jun 2020 15:12:28 -0400 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (64.101.32.56) by xhs-rtp-001.cisco.com (64.101.210.228) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 11 Jun 2020 15:12:29 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=JbKikc/qnzkNh1+B6tq7E10zEWq+a5zZRRdNIYnS1uDXYUqX0Lde7aZ7XcS+8dtoCeamryM/70+G9w2kbvCnIk6LEvfQZSDq1wAwu3MOp+SYiVHtXlu9n/Ih48Q/fBTR/fNLqYx3scXA8V2aOEx4yIaW2BpbqznxDd14k73wsQfnWZti8CbJMCjXvO762fJ5say540vRJ+KNphBFSOFNYBo6Yvc1JFrDIAANInGVxC1G9awQ6RxYIGe6V9Fpv5zSsl/hdNKrO7wcEnSDMSQjxdWrplq0X6XXUCJRhvPX+p77KceL/cJnKTZDaa2rU0Fjm2tODyYkn5rLIpO3jmSgKA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oGOHJgviZaG91tfLyd9VEK6sRryj4rc4X30+UbScrgc=; b=BdR3izSxuzzn4mPZi6WTQ1YNIsDLBOILKtg1nxTYYG5y7H//Hb0xQb4UR9w8tJGZZ969BuwtpjVkWbsxyzkf78mjCapNm+oSvoSFYli35W5cQZL5H5Gq4n0FZF0MT0MDEJWNGMKqRLm7yOyklgbMlM9aX53LP+D2as1G8YkGCf2ZKuLeMJioTaNCAF6XxbCxAsfZyNW1MZWysMYcq+6KMtrV91IucJbDsdHCcZv0BPot+n4raXxyNQs25IZqKKdjD3gtueKhnptBwibuLceMwmFQMkrNOeSXBrV9RUKeXqawxKs9F2L2VGRipk3fW92cWRV4MVSRgDYsANP1TcOrXQ== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oGOHJgviZaG91tfLyd9VEK6sRryj4rc4X30+UbScrgc=; b=mzzA8GVZ9kaD5I18v+9Pvphuy+F2PFIr0F1JRw3VMziQPjNZfAUwTr4SnJp6q7qfBHm/Jql/tHtAl0tizRzt1C8U6t+//FcQ1xQkjtCB7RoaPm1R7q02i6nWEljuADIn6gFMACvqVWUPam0TRBZLfZORrd5P0QLzuBvBOngQpig= Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN6PR11MB4178.namprd11.prod.outlook.com (2603:10b6:405:84::23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Thu, 11 Jun 2020 19:12:28 +0000 Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5%5]) with mapi id 15.20.3088.022; Thu, 11 Jun 2020 19:12:28 +0000 From: "Scott Fluhrer (sfluhrer)" To: "Stanislav V. Smyshlyaev" , "crypto-panel@irtf.org" CC: "cfrg-chairs@ietf.org" Thread-Topic: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024) Thread-Index: AQHWQBnJJGAZ+rJ0+0mRx3PaVn0UH6jTxU5w Date: Thu, 11 Jun 2020 19:12:28 +0000 Message-ID: References: <20200318130152.57FD7F4071D@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 4b41de5c-b505-44b6-6746-08d80e3b6203 x-ms-traffictypediagnostic: BN6PR11MB4178: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0431F981D8 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: zqk0KpxUqFkuGyCUrd//OFaptyMqiaRQ50cSjM33ZZgju2JJBsqUoW3AjOlcHn6lgpRR6h3Cw6iS7UtXyi8AWLGY5JZ5N7wXBjvrgsJr8+GeuIX37TtxuP2v5sFpDbB0S+WQPlFnxksYKug1e/mbZaDUlEvOyClg70U8lZkU6VVGX/AccXYMbcJ+GvMNaieyWuTHv4H/glbpdZeiEqDEwJ70G5nauaQhiW/cKZcI+L3hLeBFEYfe2MHhUebkFqoj9sARSx/yHUnAgtQV2tDuDniUZ7QquvpTivT7sOHOkI8oMjuf2fYGUhrWTThZM4B4SDBvnB8IbPoIAZG0In91yT7y0oaZTAjUp6PFmPL3aF/5/9PgNKD8QetruZnBc0T1PQewpnTv/FiJ1MKDMOxsaA== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(396003)(39860400002)(376002)(346002)(366004)(66946007)(52536014)(66476007)(83380400001)(66556008)(66446008)(64756008)(110136005)(66574014)(166002)(71200400001)(33656002)(7696005)(186003)(5660300002)(53546011)(26005)(316002)(86362001)(2906002)(6506007)(966005)(8676002)(8936002)(76116006)(4326008)(9686003)(55016002)(478600001); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: Bhle8xHCr1vK64xstZquD7PDMCIs2IGlR5Dli/HUo4CHpzxz6o4MzHjhZZ10+8REOI8Aru7HXrvjfK5TjyQw3cwiwew61em3PM02shK241cjcHHJuxtJ/KG5EnQhh62zFhf/unyOPVXj4ukdA6s1z17ww79cdA/QF/FiIcS10SkYyJTJz+hVww16Kp6hzbZNGdos2QnuiYGISQzpD2zS1V4qufBGwXeqPwZOaI+9XsvjdD3WpsRGfUfIp2Bz7yS0Kweqor3u/BLi/DgYMWdVxtR/+Ad5ukEyfSu1/bHXTCqX+S/VqVDqGcsZmgEwG86/QQAzkBg781b4rDt3F8dQfrUcezdCmhsQJJtkhfZs/c7zodGWwQQNGwa6ttnwwJaB28UoN5YvEtNHAMhNMslUJ9yqY2l8Np1dCMA3/OGFqZPdiLN82vpbFyXAqSPPDpu6tcBRJ5JRgPnk1MybGhfXNlcWjSOfpZmh5m302iokOaY= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2641C2A92E243A5A8E665162C1800BN7PR11MB2641namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: 4b41de5c-b505-44b6-6746-08d80e3b6203 X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2020 19:12:28.2475 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: 2RyOhXUhI9p4Yn+9De/+bfwLz3tbwkiV+PCJzLNkOg/4uF3wegnfFdi9dwanuQ/NGhrIeUAFs7aVU52RDrCQdQ== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB4178 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.11, xch-rcd-001.cisco.com X-Outbound-Node: rcdn-core-4.cisco.com Archived-At: Subject: Re: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024) X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 19:12:42 -0000 --_000_BN7PR11MB2641C2A92E243A5A8E665162C1800BN7PR11MB2641namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SSB2b2x1bnRlZXI7IGhvd2V2ZXIgSSBjYW7igJl0IHJlYWQgdGhlIGxpbmsuICBEaWQgeW91IHNl bmQgaXQgY29ycmVjdGx5Pw0KDQpBY3R1YWxseSwgdGhlIGNvcnJlY3RlZCB0ZXh0IHlvdSBpbmNs dWRlIGJlbG93IGxvb2tzIGRlY2VudCAoYWx0aG91Z2ggdGhlIGRpc2N1c3Npb24gb2YgU0hBMyBt YXkgYmUgYSBiaXQgbWlzbGVhZGluZyDigJMgU0hBLTMgaGFzIG1vcmUgdGhhbiBuLzIgYml0cyBv ZiBzZWN1cml0eSwgd2hpY2ggc29tZW9uZSBtaWdodCBhc3N1bWUgZnJvbSBhIHF1aWNrIHJlYWRp bmcgb2Yg4oCcVGhlIHNhbWUgYXBwbGllcyBmb3IgU0hBM+KApuKAnSkuDQoNCknigJlkIHdhbnQg dG8gc2VlIHRoZSBmdWxsIGVycmF0YSBiZWZvcmUgSSBwbGFjZSBteSBzZWFsIG9mIGFwcHJvdmFs LCBvZiBjb3Vyc2UuDQoNCkZyb206IENyeXB0by1wYW5lbCA8Y3J5cHRvLXBhbmVsLWJvdW5jZXNA aXJ0Zi5vcmc+IE9uIEJlaGFsZiBPZiBTdGFuaXNsYXYgVi4gU215c2hseWFldg0KU2VudDogVGh1 cnNkYXksIEp1bmUgMTEsIDIwMjAgMTo1NyBQTQ0KVG86IGNyeXB0by1wYW5lbEBpcnRmLm9yZw0K Q2M6IGNmcmctY2hhaXJzQGlldGYub3JnDQpTdWJqZWN0OiBbQ3J5cHRvLXBhbmVsXSBGd2Q6IFtp cnNnXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDODM5MSAoNjAyNCkNCg0KRGVhciBD cnlwdG8gUmV2aWV3IFBhbmVsIG1lbWJlcnMsDQoNClRoZXJlIGlzIGEgbmVlZCB0byB2YWxpZGF0 ZSB0aGUgZm9sbG93aW5nIGVycmF0YToNCmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0 YS9laWQ2MDI0PGh0dHBzOi8vd3d3LnJmYy1lZGl0b3IuLm9yZy9lcnJhdGEvZWlkNjAyND4NCg0K QW55IHZvbHVudGVlcnM/DQoNClJlZ2FyZHMsDQpDRlJHIGNoYWlycw0KDQoNCg0KLS0tLS0tLS0t LSDQn9C10YDQtdGB0YvQu9Cw0LXQvNC+0LUg0YHQvtC+0LHRidC10L3QuNC1IC0tLS0tLS0tLQ0K 0J7RgjogQ29saW4gUGVya2lucyA8Y3NwQGNzcGVya2lucy5vcmc8bWFpbHRvOmNzcEBjc3Blcmtp bnMub3JnPj4NCtCU0LDRgtCwOiDRgdCxLCA2INC40Y7QvdGPIDIwMjAg0LMuINCyIDE2OjAzDQrQ otC10LzQsDogRndkOiBbaXJzZ10gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzgzOTEg KDYwMjQpDQrQmtC+0LzRgzogPGNmcmctY2hhaXJzQGlldGYub3JnPG1haWx0bzpjZnJnLWNoYWly c0BpZXRmLm9yZz4+DQoNCkhpIENGUkcgY2hhaXJzLA0KDQpDYW4geW91IGRpc2N1c3MsIGFuZCBy ZXZpZXcgd2l0aCB0aGUgUkcgaWYgbmVjZXNzYXJ5LCBhbmQgbGV0IG1lIGtub3cgIGlmIHRoZSBm b2xsb3dpbmcgZXJyYXRhIHNob3VsZCBiZSBtYXJrZWQgYXMgdmVyaWZpZWQuDQoNClRoYW5rcywN CkNvbGluDQoNCg0KDQoNCkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOg0KDQpGcm9tOiBSRkMgRXJy YXRhIFN5c3RlbSA8cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZzxtYWlsdG86cmZjLWVkaXRvckBy ZmMtZWRpdG9yLm9yZz4+DQpTdWJqZWN0OiBbaXJzZ10gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0 ZWRdIFJGQzgzOTEgKDYwMjQpDQpEYXRlOiAxOCBNYXJjaCAyMDIwIGF0IDEzOjAxOjUyIEdNVA0K VG86IGlldGZAaHVlbHNpbmcubmV0PG1haWx0bzppZXRmQGh1ZWxzaW5nLm5ldD4sIGRidXRpbkBj ZGMuaW5mb3JtYXRpay50dS1kYXJtc3RhZHQuZGU8bWFpbHRvOmRidXRpbkBjZGMuaW5mb3JtYXRp ay50dS1kYXJtc3RhZHQuZGU+LCBpZXRmQGdhemRhZy5kZTxtYWlsdG86aWV0ZkBnYXpkYWcuZGU+ LCBpZXRmQGpvb3N0cmlqbmV2ZWxkLm5sPG1haWx0bzppZXRmQGpvb3N0cmlqbmV2ZWxkLm5sPiwg bW9oYWlzZW5AaWVlZS5vcmc8bWFpbHRvOm1vaGFpc2VuQGllZWUub3JnPiwgaXJzZ0BpcnRmLm9y ZzxtYWlsdG86aXJzZ0BpcnRmLm9yZz4NCkNjOiBpZXRmQGh1ZWxzaW5nLm5ldDxtYWlsdG86aWV0 ZkBodWVsc2luZy5uZXQ+LCByZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPG1haWx0bzpyZmMtZWRp dG9yQHJmYy1lZGl0b3Iub3JnPg0KDQpUaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJl ZW4gc3VibWl0dGVkIGZvciBSRkM4MzkxLA0KIlhNU1M6IGVYdGVuZGVkIE1lcmtsZSBTaWduYXR1 cmUgU2NoZW1lIi4NCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCllv dSBtYXkgcmV2aWV3IHRoZSByZXBvcnQgYmVsb3cgYW5kIGF0Og0KaHR0cHM6Ly93d3cucmZjLWVk aXRvci5vcmcvZXJyYXRhL2VpZDYwMjQNCg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NClR5cGU6IFRlY2huaWNhbA0KUmVwb3J0ZWQgYnk6IEFuZHJlYXMgSMO8bHNpbmcg PGlldGZAaHVlbHNpbmcubmV0PG1haWx0bzppZXRmQGh1ZWxzaW5nLm5ldD4+DQoNClNlY3Rpb246 IDUNCg0KT3JpZ2luYWwgVGV4dA0KLS0tLS0tLS0tLS0tLQ0KVGhpcyBzZWN0aW9uIHByb3ZpZGVz IGJhc2ljIHBhcmFtZXRlciBzZXRzIHRoYXQgYXJlIGFzc3VtZWQgdG8gY292ZXIgbW9zdCByZWxl dmFudCBhcHBsaWNhdGlvbnMuICBQYXJhbWV0ZXIgc2V0cyBmb3IgdHdvIGNsYXNzaWNhbCBzZWN1 cml0eSBsZXZlbHMgYXJlIGRlZmluZWQuICBQYXJhbWV0ZXJzIHdpdGggbiA9IDMyIHByb3ZpZGUg YSBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2ZWwgb2YgMjU2IGJpdHMuICBQYXJhbWV0ZXJzIHdpdGgg biA9IDY0IHByb3ZpZGUgYSBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2ZWwgb2YgNTEyIGJpdHMuICBD b25zaWRlcmluZyBxdWFudHVtLWNvbXB1dGVyLWFpZGVkIGF0dGFja3MsIHRoZXNlIG91dHB1dCBz aXplcyB5aWVsZCBwb3N0LXF1YW50dW0gc2VjdXJpdHkgb2YgMTI4IGFuZCAyNTYgYml0cywgcmVz cGVjdGl2ZWx5Lg0KDQpDb3JyZWN0ZWQgVGV4dA0KLS0tLS0tLS0tLS0tLS0NClRoaXMgc2VjdGlv biBwcm92aWRlcyBiYXNpYyBwYXJhbWV0ZXIgc2V0cyB0aGF0IGFyZSBhc3N1bWVkIHRvIGNvdmVy IG1vc3QgcmVsZXZhbnQgYXBwbGljYXRpb25zLiBQYXJhbWV0ZXIgc2V0cyBmb3IgdHdvIGNsYXNz aWNhbCBzZWN1cml0eSBsZXZlbHMgYXJlIGRlZmluZWQgdXNpbmcgdGhlIGNyeXB0b2dyYXBoaWMg ZnVuY3Rpb25zIFNIQTIgYW5kIFNIQUtFLiAgUGFyYW1ldGVycyB3aXRoIFNIQTIgYW5kIG4gPSAz MiBwcm92aWRlIGEgY2xhc3NpY2FsIHNlY3VyaXR5IGxldmVsIG9mIDI1NiBiaXRzLiBQYXJhbWV0 ZXJzIHdpdGggU0hBMiBhbmQgbiA9IDY0IHByb3ZpZGUgYSBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2 ZWwgb2YgNTEyIGJpdHMuICBDb25zaWRlcmluZyBxdWFudHVtLWNvbXB1dGVyLWFpZGVkIGF0dGFj a3MsIHRoZXNlIHBhcmFtZXRlcnMgeWllbGQgcG9zdC1xdWFudHVtIHNlY3VyaXR5IG9mIDEyOCBh bmQgMjU2IGJpdHMsIHJlc3BlY3RpdmVseS4gUGFyYW1ldGVycyB3aXRoIFNIQUtFIGFuZCBuID0g MzIgcHJvdmlkZSBhIGNsYXNzaWNhbCBzZWN1cml0eSBsZXZlbCBvZiAxMjggYml0cy4gIFBhcmFt ZXRlcnMgd2l0aCBTSEFLRSBhbmQgbiA9IDY0IHByb3ZpZGUgYSBjbGFzc2ljYWwgc2VjdXJpdHkg bGV2ZWwgb2YgMjU2IGJpdHMuICBDb25zaWRlcmluZyBxdWFudHVtLWNvbXB1dGVyLWFpZGVkIGF0 dGFja3MsIHRoZXNlIHBhcmFtZXRlcnMgeWllbGQgcG9zdC1xdWFudHVtIHNlY3VyaXR5IG9mIDg2 IGFuZCAxNzAgYml0cywgcmVzcGVjdGl2ZWx5Lg0KDQpOb3Rlcw0KLS0tLS0NClRyYWRpdGlvbmFs bHksIGEgaGFzaCBmdW5jdGlvbiB3aXRoIG4tYml0IG91dHB1dHMgaXMgYXNzdW1lZCB0byBoYXZl IG4tYml0IHNlY3VyaXR5IGFnYWluc3QgY2xhc3NpY2FsIHByZWltYWdlIGFuZCBzZWNvbmQtcHJl aW1hZ2UgYXR0YWNrcywgYW5kIG4vMi1iaXQgc2VjdXJpdHkgYWdhaW5zdCBjbGFzc2ljYWwgY29s bGlzaW9uIGF0dGFja3MuIEZvciBhZHZlcnNhcmllcyB3aXRoIGFjY2VzcyB0byBhIHF1YW50dW0g Y29tcHV0ZXIsIHRoZXNlIGJvdW5kcyBjaGFuZ2UgdG8gbi8yIGFuZCBuLzMgYml0cyB3aGVuIG9u bHkgY291bnRpbmcgcXVlcmllcyB0byB0aGUgaGFzaCBmdW5jdGlvbi4gVGhpcyBhbHNvIGFwcGxp ZXMgdG8gU0hBMiBhbmQgU0hBMy4gSW4gY29udHJhc3QsIFNIQUtFIGZvbGxvd3MgYSBkaWZmZXJl bnQgcmVhc29uaW5nLiBTSEFLRSB3aXRoIGFuIGludGVybmFsIHN0YXRlIG9mIG4gYml0cyBhbmQg YW4gb3V0cHV0IGxlbmd0aCBvZiBuIGJpdHMgYWNoaWV2ZXMgbi8yIGJpdCBzZWN1cml0eSBhZ2Fp bnN0IGNsYXNzaWNhbCBwcmVpbWFnZSwgc2Vjb25kLXByZWltYWdlIGFuZCBjb2xsaXNpb24gYXR0 YWNrcy4gRm9yIHF1YW50dW0gYXR0YWNrcyBzZWN1cml0eSBjaGFuZ2VzIHRvIG4vMyBiaXRzLiBU aGUgcmVhc29uIGlzIHRoYXQgU0hBS0UgYWxsb3dzIGZvciBtZWV0LWluLXRoZS1taWRkbGUgcHJl aW1hZ2UgYXR0YWNrcyB0aGF0IHJlZHVjZSB0byBhIGNvbGxpc2lvbiBzZWFyY2ggb24gdGhlIGlu dGVybmFsIHN0YXRlLiBUaGUgc2FtZSBhcHBsaWVzIGZvciBTSEEzIGJ1dCBmb3IgU0hBMyBhIGJp Z2dlciBpbnRlcm5hbCBzdGF0ZSBpcyB1c2VkLg0KDQpJbiBjb25zZXF1ZW5jZSwgU0hBS0UtMTI4 IGNhbm5vdCBwcm92aWRlIG1vcmUgc2VjdXJpdHkgdGhhbiBOSVNUIHBvc3QtcXVhbnR1bSBzZWN1 cml0eSBsZXZlbCBJSSAoQW55IGF0dGFjayB0aGF0IGJyZWFrcyB0aGUgcmVsZXZhbnQgc2VjdXJp dHkgZGVmaW5pdGlvbiBtdXN0IHJlcXVpcmUgY29tcHV0YXRpb25hbCByZXNvdXJjZXMgY29tcGFy YWJsZSB0byBvciBncmVhdGVyIHRoYW4gdGhvc2UgcmVxdWlyZWQgZm9yIGNvbGxpc2lvbiBzZWFy Y2ggb24gYSAyNTYtYml0IGhhc2ggZnVuY3Rpb24gKGUuZy4gU0hBMjU2IC8gU0hBMy0yNTYpKS4N Cg0KSW5zdHJ1Y3Rpb25zOg0KLS0tLS0tLS0tLS0tLQ0KVGhpcyBlcnJhdHVtIGlzIGN1cnJlbnRs eSBwb3N0ZWQgYXMgIlJlcG9ydGVkIi4gSWYgbmVjZXNzYXJ5LCBwbGVhc2UNCnVzZSAiUmVwbHkg QWxsIiB0byBkaXNjdXNzIHdoZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yDQpyZWplY3Rl ZC4gV2hlbiBhIGRlY2lzaW9uIGlzIHJlYWNoZWQsIHRoZSB2ZXJpZnlpbmcgcGFydHkNCmNhbiBs b2cgaW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNz YXJ5Lg0KDQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KUkZDODM5MSAo ZHJhZnQtaXJ0Zi1jZnJnLXhtc3MtaGFzaC1iYXNlZC1zaWduYXR1cmVzLTEyKQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NClRpdGxlICAgICAgICAgICAgICAgOiBYTVNT OiBlWHRlbmRlZCBNZXJrbGUgU2lnbmF0dXJlIFNjaGVtZQ0KUHVibGljYXRpb24gRGF0ZSAgICA6 IE1heSAyMDE4DQpBdXRob3IocykgICAgICAgICAgIDogQS4gSHVlbHNpbmcsIEQuIEJ1dGluLCBT LiBHYXpkYWcsIEouIFJpam5ldmVsZCwgQS4uIE1vaGFpc2VuDQpDYXRlZ29yeSAgICAgICAgICAg IDogSU5GT1JNQVRJT05BTA0KU291cmNlICAgICAgICAgICAgICA6IENyeXB0byBGb3J1bSBSZXNl YXJjaCBHcm91cA0KQXJlYSAgICAgICAgICAgICAgICA6IE4vQQ0KU3RyZWFtICAgICAgICAgICAg ICA6IElSVEYNClZlcmlmeWluZyBQYXJ0eSAgICAgOiBJUlNHDQoNCg0K --_000_BN7PR11MB2641C2A92E243A5A8E665162C1800BN7PR11MB2641namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNhIE5ldWUiO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SSB2b2x1bnRlZXI7 IGhvd2V2ZXIgSSBjYW7igJl0IHJlYWQgdGhlIGxpbmsuJm5ic3A7IERpZCB5b3Ugc2VuZCBpdCBj b3JyZWN0bHk/PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNw OzwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkFjdHVhbGx5LCB0aGUgY29ycmVjdGVk IHRleHQgeW91IGluY2x1ZGUgYmVsb3cgbG9va3MgZGVjZW50IChhbHRob3VnaCB0aGUgZGlzY3Vz c2lvbiBvZiBTSEEzIG1heSBiZSBhIGJpdCBtaXNsZWFkaW5nIOKAkyBTSEEtMyBoYXMgbW9yZSB0 aGFuIG4vMiBiaXRzIG9mIHNlY3VyaXR5LCB3aGljaCBzb21lb25lIG1pZ2h0IGFzc3VtZSBmcm9t IGEgcXVpY2sgcmVhZGluZyBvZiDigJxUaGUgc2FtZSBhcHBsaWVzIGZvciBTSEEz4oCm4oCdKS48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9w Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+SeKAmWQgd2FudCB0byBzZWUgdGhlIGZ1bGwgZXJyYXRh IGJlZm9yZSBJIHBsYWNlIG15IHNlYWwgb2YgYXBwcm92YWwsIG9mIGNvdXJzZS48bzpwPjwvbzpw PjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdiBz dHlsZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBp biAwaW4gMGluIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXIt dG9wOnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwaW4gMGluIDBpbiI+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48Yj5Gcm9tOjwvYj4gQ3J5cHRvLXBhbmVsICZsdDtjcnlwdG8tcGFu ZWwtYm91bmNlc0BpcnRmLm9yZyZndDsgPGI+DQpPbiBCZWhhbGYgT2YgPC9iPlN0YW5pc2xhdiBW LiBTbXlzaGx5YWV2PGJyPg0KPGI+U2VudDo8L2I+IFRodXJzZGF5LCBKdW5lIDExLCAyMDIwIDE6 NTcgUE08YnI+DQo8Yj5Ubzo8L2I+IGNyeXB0by1wYW5lbEBpcnRmLm9yZzxicj4NCjxiPkNjOjwv Yj4gY2ZyZy1jaGFpcnNAaWV0Zi5vcmc8YnI+DQo8Yj5TdWJqZWN0OjwvYj4gW0NyeXB0by1wYW5l bF0gRndkOiBbaXJzZ10gW1RlY2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzgzOTEgKDYwMjQp PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkRl YXIgQ3J5cHRvIFJldmlldyBQYW5lbCBtZW1iZXJzLDxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZXJlIGlzIGEgbmVlZCB0byB2 YWxpZGF0ZSB0aGUgZm9sbG93aW5nIGVycmF0YTo8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YSBocmVmPSJodHRwczovL3d3dy5yZmMt ZWRpdG9yLi5vcmcvZXJyYXRhL2VpZDYwMjQiPmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2Vy cmF0YS9laWQ2MDI0PC9hPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5Bbnkgdm9sdW50ZWVycz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkNGUkcgY2hhaXJzPG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZu YnNwOzwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+LS0tLS0t LS0tLSDQn9C10YDQtdGB0YvQu9Cw0LXQvNC+0LUg0YHQvtC+0LHRidC10L3QuNC1IC0tLS0tLS0t LTxicj4NCtCe0YI6IDxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0NhbGli cmkmcXVvdDssc2Fucy1zZXJpZiI+Q29saW4gUGVya2luczwvc3Bhbj48L3N0cm9uZz4gJmx0Ozxh IGhyZWY9Im1haWx0bzpjc3BAY3NwZXJraW5zLm9yZyI+Y3NwQGNzcGVya2lucy5vcmc8L2E+Jmd0 Ozxicj4NCtCU0LDRgtCwOiDRgdCxLCA2INC40Y7QvdGPIDIwMjAg0LMuINCyIDE2OjAzPGJyPg0K 0KLQtdC80LA6IEZ3ZDogW2lyc2ddIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM4Mzkx ICg2MDI0KTxicj4NCtCa0L7QvNGDOiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNmcmctY2hhaXJzQGll dGYub3JnIj5jZnJnLWNoYWlyc0BpZXRmLm9yZzwvYT4mZ3Q7PG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtYXJnaW4tYm90dG9tOjEyLjBwdCI+PG86 cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkhp IENGUkcgY2hhaXJzLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwi PjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCI+Q2FuIHlvdSBkaXNjdXNzLCBhbmQgcmV2aWV3IHdpdGggdGhlIFJHIGlmIG5lY2Vzc2FyeSwg YW5kIGxldCBtZSBrbm93ICZuYnNwO2lmIHRoZSBmb2xsb3dpbmcgZXJyYXRhIHNob3VsZCBiZSBt YXJrZWQgYXMgdmVyaWZpZWQuPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPlRoYW5rcyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPkNvbGluPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxicj4NCjxicj4NCjxvOnA+PC9vOnA+PC9wPg0KPGJsb2NrcXVvdGUg c3R5bGU9Im1hcmdpbi10b3A6NS4wcHQ7bWFyZ2luLWJvdHRvbTo1LjBwdCI+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+QmVnaW4gZm9yd2FyZGVkIG1lc3NhZ2U6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVv dDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjpibGFjayI+RnJvbToNCjwvc3Bhbj48L2I+PHNw YW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij5SRkMgRXJy YXRhIFN5c3RlbSAmbHQ7PGEgaHJlZj0ibWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmci IHRhcmdldD0iX2JsYW5rIj5yZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPC9hPiZndDs8L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48 c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6 YmxhY2siPlN1YmplY3Q6DQo8L3NwYW4+PC9iPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTom cXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+W2lyc2ddIFtUZWNobmljYWwgRXJyYXRhIFJlcG9y dGVkXSBSRkM4MzkxICg2MDI0KTwvc3Bhbj48L2I+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6YmxhY2siPkRhdGU6DQo8L3NwYW4+PC9iPjxz cGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+MTggTWFy Y2ggMjAyMCBhdCAxMzowMTo1MiBHTVQ8L3NwYW4+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1 b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6YmxhY2siPlRvOg0KPC9zcGFuPjwvYj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPjxhIGhyZWY9 Im1haWx0bzppZXRmQGh1ZWxzaW5nLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmlldGZAaHVlbHNpbmcu bmV0PC9hPiwNCjxhIGhyZWY9Im1haWx0bzpkYnV0aW5AY2RjLmluZm9ybWF0aWsudHUtZGFybXN0 YWR0LmRlIiB0YXJnZXQ9Il9ibGFuayI+ZGJ1dGluQGNkYy5pbmZvcm1hdGlrLnR1LWRhcm1zdGFk dC5kZTwvYT4sDQo8YSBocmVmPSJtYWlsdG86aWV0ZkBnYXpkYWcuZGUiIHRhcmdldD0iX2JsYW5r Ij5pZXRmQGdhemRhZy5kZTwvYT4sIDxhIGhyZWY9Im1haWx0bzppZXRmQGpvb3N0cmlqbmV2ZWxk Lm5sIiB0YXJnZXQ9Il9ibGFuayI+DQppZXRmQGpvb3N0cmlqbmV2ZWxkLm5sPC9hPiwgPGEgaHJl Zj0ibWFpbHRvOm1vaGFpc2VuQGllZWUub3JnIiB0YXJnZXQ9Il9ibGFuayI+bW9oYWlzZW5AaWVl ZS5vcmc8L2E+LA0KPGEgaHJlZj0ibWFpbHRvOmlyc2dAaXJ0Zi5vcmciIHRhcmdldD0iX2JsYW5r Ij5pcnNnQGlydGYub3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xvcjpibGFjayI+Q2M6DQo8L3NwYW4+PC9iPjxzcGFuIHN0 eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+PGEgaHJlZj0ibWFp bHRvOmlldGZAaHVlbHNpbmcubmV0IiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkBodWVsc2luZy5uZXQ8 L2E+LA0KPGEgaHJlZj0ibWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmciIHRhcmdldD0i X2JsYW5rIj5yZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlRoZSBmb2xsb3dpbmcgZXJyYXRhIHJl cG9ydCBoYXMgYmVlbiBzdWJtaXR0ZWQgZm9yIFJGQzgzOTEsPGJyPg0KJnF1b3Q7WE1TUzogZVh0 ZW5kZWQgTWVya2xlIFNpZ25hdHVyZSBTY2hlbWUmcXVvdDsuPGJyPg0KPGJyPg0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpZb3UgbWF5IHJldmlldyB0aGUgcmVw b3J0IGJlbG93IGFuZCBhdDo8YnI+DQo8YSBocmVmPSJodHRwczovL3d3dy5yZmMtZWRpdG9yLm9y Zy9lcnJhdGEvZWlkNjAyNCIgdGFyZ2V0PSJfYmxhbmsiPmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iu b3JnL2VycmF0YS9laWQ2MDI0PC9hPjxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tPGJyPg0KVHlwZTogVGVjaG5pY2FsPGJyPg0KUmVwb3J0ZWQgYnk6IEFu ZHJlYXMgSMO8bHNpbmcgJmx0OzxhIGhyZWY9Im1haWx0bzppZXRmQGh1ZWxzaW5nLm5ldCIgdGFy Z2V0PSJfYmxhbmsiPmlldGZAaHVlbHNpbmcubmV0PC9hPiZndDs8YnI+DQo8YnI+DQpTZWN0aW9u OiA1PGJyPg0KPGJyPg0KT3JpZ2luYWwgVGV4dDxicj4NCi0tLS0tLS0tLS0tLS08YnI+DQpUaGlz IHNlY3Rpb24gcHJvdmlkZXMgYmFzaWMgcGFyYW1ldGVyIHNldHMgdGhhdCBhcmUgYXNzdW1lZCB0 byBjb3ZlciBtb3N0IHJlbGV2YW50IGFwcGxpY2F0aW9ucy4mbmJzcDsgUGFyYW1ldGVyIHNldHMg Zm9yIHR3byBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2ZWxzIGFyZSBkZWZpbmVkLiZuYnNwOyBQYXJh bWV0ZXJzIHdpdGggbiA9IDMyIHByb3ZpZGUgYSBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2ZWwgb2Yg MjU2IGJpdHMuJm5ic3A7IFBhcmFtZXRlcnMgd2l0aCBuID0gNjQgcHJvdmlkZQ0KIGEgY2xhc3Np Y2FsIHNlY3VyaXR5IGxldmVsIG9mIDUxMiBiaXRzLiZuYnNwOyBDb25zaWRlcmluZyBxdWFudHVt LWNvbXB1dGVyLWFpZGVkIGF0dGFja3MsIHRoZXNlIG91dHB1dCBzaXplcyB5aWVsZCBwb3N0LXF1 YW50dW0gc2VjdXJpdHkgb2YgMTI4IGFuZCAyNTYgYml0cywgcmVzcGVjdGl2ZWx5Ljxicj4NCjxi cj4NCkNvcnJlY3RlZCBUZXh0PGJyPg0KLS0tLS0tLS0tLS0tLS08YnI+DQpUaGlzIHNlY3Rpb24g cHJvdmlkZXMgYmFzaWMgcGFyYW1ldGVyIHNldHMgdGhhdCBhcmUgYXNzdW1lZCB0byBjb3ZlciBt b3N0IHJlbGV2YW50IGFwcGxpY2F0aW9ucy4gUGFyYW1ldGVyIHNldHMgZm9yIHR3byBjbGFzc2lj YWwgc2VjdXJpdHkgbGV2ZWxzIGFyZSBkZWZpbmVkIHVzaW5nIHRoZSBjcnlwdG9ncmFwaGljIGZ1 bmN0aW9ucyBTSEEyIGFuZCBTSEFLRS4mbmJzcDsgUGFyYW1ldGVycyB3aXRoIFNIQTIgYW5kIG4g PSAzMiBwcm92aWRlIGEgY2xhc3NpY2FsDQogc2VjdXJpdHkgbGV2ZWwgb2YgMjU2IGJpdHMuIFBh cmFtZXRlcnMgd2l0aCBTSEEyIGFuZCBuID0gNjQgcHJvdmlkZSBhIGNsYXNzaWNhbCBzZWN1cml0 eSBsZXZlbCBvZiA1MTIgYml0cy4mbmJzcDsgQ29uc2lkZXJpbmcgcXVhbnR1bS1jb21wdXRlci1h aWRlZCBhdHRhY2tzLCB0aGVzZSBwYXJhbWV0ZXJzIHlpZWxkIHBvc3QtcXVhbnR1bSBzZWN1cml0 eSBvZiAxMjggYW5kIDI1NiBiaXRzLCByZXNwZWN0aXZlbHkuIFBhcmFtZXRlcnMgd2l0aCBTSEFL RSBhbmQNCiBuID0gMzIgcHJvdmlkZSBhIGNsYXNzaWNhbCBzZWN1cml0eSBsZXZlbCBvZiAxMjgg Yml0cy4mbmJzcDsgUGFyYW1ldGVycyB3aXRoIFNIQUtFIGFuZCBuID0gNjQgcHJvdmlkZSBhIGNs YXNzaWNhbCBzZWN1cml0eSBsZXZlbCBvZiAyNTYgYml0cy4mbmJzcDsgQ29uc2lkZXJpbmcgcXVh bnR1bS1jb21wdXRlci1haWRlZCBhdHRhY2tzLCB0aGVzZSBwYXJhbWV0ZXJzIHlpZWxkIHBvc3Qt cXVhbnR1bSBzZWN1cml0eSBvZiA4NiBhbmQgMTcwIGJpdHMsIHJlc3BlY3RpdmVseS4NCjxicj4N Cjxicj4NCk5vdGVzPGJyPg0KLS0tLS08YnI+DQpUcmFkaXRpb25hbGx5LCBhIGhhc2ggZnVuY3Rp b24gd2l0aCBuLWJpdCBvdXRwdXRzIGlzIGFzc3VtZWQgdG8gaGF2ZSBuLWJpdCBzZWN1cml0eSBh Z2FpbnN0IGNsYXNzaWNhbCBwcmVpbWFnZSBhbmQgc2Vjb25kLXByZWltYWdlIGF0dGFja3MsIGFu ZCBuLzItYml0IHNlY3VyaXR5IGFnYWluc3QgY2xhc3NpY2FsIGNvbGxpc2lvbiBhdHRhY2tzLiBG b3IgYWR2ZXJzYXJpZXMgd2l0aCBhY2Nlc3MgdG8gYSBxdWFudHVtIGNvbXB1dGVyLCB0aGVzZSBi b3VuZHMNCiBjaGFuZ2UgdG8gbi8yIGFuZCBuLzMgYml0cyB3aGVuIG9ubHkgY291bnRpbmcgcXVl cmllcyB0byB0aGUgaGFzaCBmdW5jdGlvbi4gVGhpcyBhbHNvIGFwcGxpZXMgdG8gU0hBMiBhbmQg U0hBMy4gSW4gY29udHJhc3QsIFNIQUtFIGZvbGxvd3MgYSBkaWZmZXJlbnQgcmVhc29uaW5nLiBT SEFLRSB3aXRoIGFuIGludGVybmFsIHN0YXRlIG9mIG4gYml0cyBhbmQgYW4gb3V0cHV0IGxlbmd0 aCBvZiBuIGJpdHMgYWNoaWV2ZXMgbi8yIGJpdCBzZWN1cml0eQ0KIGFnYWluc3QgY2xhc3NpY2Fs IHByZWltYWdlLCBzZWNvbmQtcHJlaW1hZ2UgYW5kIGNvbGxpc2lvbiBhdHRhY2tzLiBGb3IgcXVh bnR1bSBhdHRhY2tzIHNlY3VyaXR5IGNoYW5nZXMgdG8gbi8zIGJpdHMuIFRoZSByZWFzb24gaXMg dGhhdCBTSEFLRSBhbGxvd3MgZm9yIG1lZXQtaW4tdGhlLW1pZGRsZSBwcmVpbWFnZSBhdHRhY2tz IHRoYXQgcmVkdWNlIHRvIGEgY29sbGlzaW9uIHNlYXJjaCBvbiB0aGUgaW50ZXJuYWwgc3RhdGUu IFRoZSBzYW1lIGFwcGxpZXMNCiBmb3IgU0hBMyBidXQgZm9yIFNIQTMgYSBiaWdnZXIgaW50ZXJu YWwgc3RhdGUgaXMgdXNlZC48YnI+DQo8YnI+DQpJbiBjb25zZXF1ZW5jZSwgU0hBS0UtMTI4IGNh bm5vdCBwcm92aWRlIG1vcmUgc2VjdXJpdHkgdGhhbiBOSVNUIHBvc3QtcXVhbnR1bSBzZWN1cml0 eSBsZXZlbCBJSSAoQW55IGF0dGFjayB0aGF0IGJyZWFrcyB0aGUgcmVsZXZhbnQgc2VjdXJpdHkg ZGVmaW5pdGlvbiBtdXN0IHJlcXVpcmUgY29tcHV0YXRpb25hbCByZXNvdXJjZXMgY29tcGFyYWJs ZSB0byBvciBncmVhdGVyIHRoYW4gdGhvc2UgcmVxdWlyZWQgZm9yIGNvbGxpc2lvbiBzZWFyY2gg b24NCiBhIDI1Ni1iaXQgaGFzaCBmdW5jdGlvbiAoZS5nLiBTSEEyNTYgLyBTSEEzLTI1NikpLjxi cj4NCjxicj4NCkluc3RydWN0aW9uczo8YnI+DQotLS0tLS0tLS0tLS0tPGJyPg0KVGhpcyBlcnJh dHVtIGlzIGN1cnJlbnRseSBwb3N0ZWQgYXMgJnF1b3Q7UmVwb3J0ZWQmcXVvdDsuIElmIG5lY2Vz c2FyeSwgcGxlYXNlPGJyPg0KdXNlICZxdW90O1JlcGx5IEFsbCZxdW90OyB0byBkaXNjdXNzIHdo ZXRoZXIgaXQgc2hvdWxkIGJlIHZlcmlmaWVkIG9yPGJyPg0KcmVqZWN0ZWQuIFdoZW4gYSBkZWNp c2lvbiBpcyByZWFjaGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5ICZuYnNwOzxicj4NCmNhbiBsb2cg aW4gdG8gY2hhbmdlIHRoZSBzdGF0dXMgYW5kIGVkaXQgdGhlIHJlcG9ydCwgaWYgbmVjZXNzYXJ5 LiA8YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N ClJGQzgzOTEgKGRyYWZ0LWlydGYtY2ZyZy14bXNzLWhhc2gtYmFzZWQtc2lnbmF0dXJlcy0xMik8 YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClRpdGxlICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogWE1TUzogZVh0ZW5kZWQgTWVya2xlIFNpZ25hdHVy ZSBTY2hlbWU8YnI+DQpQdWJsaWNhdGlvbiBEYXRlICZuYnNwOyZuYnNwOyZuYnNwOzogTWF5IDIw MTg8YnI+DQpBdXRob3IocykgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBBLiBIdWVsc2luZywgRC4gQnV0aW4sIFMuIEdhemRhZywg Si4gUmlqbmV2ZWxkLCBBLi4gTW9oYWlzZW48YnI+DQpDYXRlZ29yeSAmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IElORk9S TUFUSU9OQUw8YnI+DQpTb3VyY2UgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBDcnlwdG8gRm9ydW0g UmVzZWFyY2ggR3JvdXA8YnI+DQpBcmVhICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzogTi9BPGJyPg0KU3RyZWFtICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogSVJURjxicj4NClZlcmlm eWluZyBQYXJ0eSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IElSU0c8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRvbToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+ PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0K PC9ib2R5Pg0KPC9odG1sPg0K --_000_BN7PR11MB2641C2A92E243A5A8E665162C1800BN7PR11MB2641namp_-- From nobody Thu Jun 11 12:48:17 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 55AB03A08AF for ; Thu, 11 Jun 2020 12:48:09 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=UXeZg0ok; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=kq7wCFTZ Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MfGlYQmC0ViF for ; Thu, 11 Jun 2020 12:48:06 -0700 (PDT) Received: from alln-iport-8.cisco.com (alln-iport-8.cisco.com [173.37.142.95]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 432B93A08B9 for ; Thu, 11 Jun 2020 12:48:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=27966; q=dns/txt; s=iport; t=1591904886; x=1593114486; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=AxeVnzSkRpcqxzc1kSJ5VADi3UQN5bGc50fWdmGiPwM=; b=UXeZg0oknGwrTqywFhm5j9ZUbPxHG1FnpdP2TH9DUeuC4/0V4I+6m/t6 mlVQYbMrtvlBCHyvNM6OURuprX8aTn//hc1k5QakZd+GPvFyZY/S1qOiC UCUhUBZ8ivR78LrH/8JvQwLDwfF8xXBMWSUhrXVcvlugxoQylWnF5Wd/h Y=; IronPort-PHdr: =?us-ascii?q?9a23=3AZc1rVRDAfvsKo+qU6GcTUyQJPHJ1sqjoPgMT9p?= =?us-ascii?q?ssgq5PdaLm5Zn5IUjD/qw00A3GWIza77RPjO+F+6zjWGlV55GHvThCdZFXTB?= =?us-ascii?q?YKhI0QmBBoG8+KD0D3bZuIJyw3FchPThlpqne8N0UGF8P3ZlmUqXq3vnYeHx?= =?us-ascii?q?zlPl9zIeL4UofZk8Ww0bW0/JveKwVFjTawe/V8NhKz+A7QrcIRx4BlL/U8?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CAAAA5iuJe/4ENJK1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQGCCoEjLykpB29YLywKhBqBXYFpA40?= =?us-ascii?q?4mFKBQoEQA1ULAQEBDAEBIwoCBAEBgw6BNgIXggsCJDgTAgMBAQsBAQUBAQE?= =?us-ascii?q?CAQYEbYVbDIVyAQEBAQMSEQoTAQE3AQ8CAQYCEQMBAQEoAwICAjAUCQgCBAE?= =?us-ascii?q?NBQgagwWBfk0DLgEOmAuQZwKBOYhhdoEygwEBAQWFBBiCDgMGgTgBgmOHG4E?= =?us-ascii?q?IgUQagUE/gRFDgk0+gQSDEDweDQmCXjOCLY8RJ4JphjaDBpheCoJZmTWCb4k?= =?us-ascii?q?YhRaNP5ETnigCBAIEBQIOAQEFgWoigVZwFRqDClAXAg2OHgsYgQIBCIJDhRS?= =?us-ascii?q?FQnQCNQIGAQcBAQMJfI0VLYEGAYEPAQE?= X-IronPort-AV: E=Sophos;i="5.73,500,1583193600"; d="scan'208,217";a="509435873" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-8.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 11 Jun 2020 19:47:48 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-9.cisco.com (8.15.2/8.15.2) with ESMTPS id 05BJlmlj019877 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Jun 2020 19:47:48 GMT Received: from xhs-aln-003.cisco.com (173.37.135.120) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 11 Jun 2020 14:47:48 -0500 Received: from xhs-rcd-002.cisco.com (173.37.227.247) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 11 Jun 2020 14:47:47 -0500 Received: from NAM10-DM6-obe.outbound.protection.outlook.com (72.163.14.9) by xhs-rcd-002.cisco.com (173.37.227.247) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Thu, 11 Jun 2020 14:47:46 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=ocewvdF9zf0Ys+4/tRQBlvjAHmNsdomoi3sDXoMyVhHpXQRm1C3lWTKRb11+D8oZI966ft98TdNc4nEfLEzlSxN2JjnOL5IW5ws4xQJdtqr6keLW8l9Q6JPVNJGYE8h7+vqYvGO6E/YTt2DEU9oOWo91+yOR95JjLcJkM5iUs1eH4NTL+w0NOnpJ2FyCyhITR5Ni6NoW7T3paJK/iu7rJ2w8FX9aWDJejy2xLiz+4OpE9lX6R7P3RoVHlfJvuttTbfCsvHdW7KsYmAXAhKkpisCCCmn9rcNFRckrdQC7dYX/JBpMD2wU0gRFhG1yVamybibBRSKkYgG5sarMGAN9Qw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AxeVnzSkRpcqxzc1kSJ5VADi3UQN5bGc50fWdmGiPwM=; b=ORuSJt2S2HxbFMxfb69uLDsJC/ud/yddO2P5NRLRGhGcz0X5WL4JN56eOlOzm7iDjewXUOb4sRpL6oiRzaUjMnW6pi63Xm3biphm1oFb6Za/wSjCHafwIi7zvuIxmdvaWmngnCR41GcCSACBfOlzimS5aHmQ3ewnKnCbGXs1D1s1R15E2wcQ870gtOsMppOiTGVY+7I5C1yx2bgWFZyZdboqdhpD8B2lpXIEeMgMg6YUGxElD0skjFWvO7RTO67qdo1Bnvzq6TkAQr8EgMK8/lwkQNtgldDgtUooFKOva0HyYO8UBb1R/I6YEYVn/1vo/bDvPT0lk4FOikqlTy/ozw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=AxeVnzSkRpcqxzc1kSJ5VADi3UQN5bGc50fWdmGiPwM=; b=kq7wCFTZXC+FtqcpBBXQld0vEXzUBaPpBDMOdBPsSOY6AGJM2G2ulCzYfpT+rpn5CwipQpOLzgBugsvurmksM0oODilmD3Na4JfUNxqjkdZfmUbvr3GPOfoIVQeXSt9N5TjOgcvpwXmTjZc0Nrmh//cGecnPO+BG1DXgu2ldW/E= Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN6PR11MB1250.namprd11.prod.outlook.com (2603:10b6:404:49::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.23; Thu, 11 Jun 2020 19:47:46 +0000 Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5%5]) with mapi id 15.20.3088.022; Thu, 11 Jun 2020 19:47:45 +0000 From: "Scott Fluhrer (sfluhrer)" To: "Stanislav V. Smyshlyaev" , "crypto-panel@irtf.org" CC: "cfrg-chairs@ietf.org" Thread-Topic: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024) Thread-Index: AQHWQBnJJGAZ+rJ0+0mRx3PaVn0UH6jTyyvg Date: Thu, 11 Jun 2020 19:47:45 +0000 Message-ID: References: <20200318130152.57FD7F4071D@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: e9a94db4-6a35-47c5-c82a-08d80e40503f x-ms-traffictypediagnostic: BN6PR11MB1250: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-forefront-prvs: 0431F981D8 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: U4JOBsWDyHkTHIc36+xWHiYbRFbwg9i0d4HbsvSuoDmydgDRDbqAh25M/Dnw38RO0LV+BwqGqZGecJH0i0oV9DB2zFExMfdOC/ti4AmLz5zGqCkdBAQE784paxjkyyQtsuEi6bGOgR3imzSd82DE1oG3hA0NDGOE1F1wRSIAFg3jK+n+r8J+ngKdBRpIMvYauE1swdEMmWGoceWHWFJ63hE5HOZJDRIVboWDER9GNdZkt2MEVZveEpWlkPrkc3DNoveQlVXmamcxm/LnWxDD4tUItXxcI2vQ0RQwpjGUSrHuBjGSj75V1WMA4I9JsKSKI5C8VwMBPTPLcfS6Vsy2YbYEcOxnD78JtQdvSVQSCLM5C7hdInme9qXWannNJgvgHO3zOGLVSVJqCIYFWtn1ww== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(346002)(396003)(366004)(376002)(39860400002)(136003)(86362001)(76116006)(26005)(64756008)(9686003)(66476007)(53546011)(6506007)(33656002)(66946007)(186003)(66446008)(66556008)(83380400001)(5660300002)(166002)(55016002)(66574014)(2906002)(4326008)(7696005)(71200400001)(110136005)(316002)(966005)(478600001)(8676002)(8936002)(52536014); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: 3P535CdD29Tw/l1XmNJ42Pb4mV1xbwfdwdWG0nzdFH4eQbL+9x1dNNUzYehWTz986qMCr7AIOdpf+Dk9E9qpFtAqUCU8cKeUA/qsNuIJ0bnVEKgSwxoFhl8pahOQulNczIQmVbi5KhUHQ90CxH80H5xiwsieQMqLLyFEl2k6EjkwdXVaXfjDthZ9rlOVTnYnL4Lnen3GhISH0bvlDrlxMosGCr/pcJ7dKkWr72v4qJeSbHEctFXQyQeMo707aLgTRNmsELxLMtdhw7kw+mEJmnUOlh9JEQrBikmGNrdAN3rMxYfoqUR+pEtnLs91Qge2B9CcGxlOjvct9fK+d4BubqTyceadYC6gPz2A5jkRxYPxMoyg/ogXDBod+Ga5rVC5ig7MTn1wKhwL+c6op94nZ0DbHBAn40ixOKHXMnIKYFRzL75/NKkTWzrRtFE3IO8Ut9vrri+R6tiUNExw4T85DHzB9oAluJnnpKUkMP2BaKUpKmWN6IsMb9SoqW7pEmW3 x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2641199090BA16B1DE9C1375C1800BN7PR11MB2641namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: e9a94db4-6a35-47c5-c82a-08d80e40503f X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Jun 2020 19:47:45.8679 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: i23TWG/xrwSthWtCTIIygA2DCtRAV87iVx2JHg74sBmIJpDFPqH1qkkSwJYYed9t4zOf1wzzgSoDqVTJtjlYPA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN6PR11MB1250 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-9.cisco.com Archived-At: Subject: Re: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024) X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 19:48:16 -0000 --_000_BN7PR11MB2641199090BA16B1DE9C1375C1800BN7PR11MB2641namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 VGhlIHRleHQgbG9va3MgY29ycmVjdCwgaG93ZXZlciBJIGRvIGhhdmUgYSBmZXcgbml0cyBhYm91 dCB0aGUgbm90ZXMuICBPbmUgaXMgdGhlIHJlZmVyZW5jZSB0byBTSEEzLCB3aGljaCBvbiBhIHF1 aWNrIHJlYWQgbWlnaHQgYmUgbWlzbGVhZGluZzsgaGVyZSBpcyBzb21lIGFsdGVyYXRpdmUgdGV4 dDoNCg0KVGhlIHJlYXNvbiBpcyB0aGF0IFNIQUtFIGFsbG93cyBmb3IgbWVldC1pbi10aGUtbWlk ZGxlIHByZWltYWdlIGF0dGFja3MgdGhhdCByZWR1Y2UgdG8gYSBjb2xsaXNpb24gc2VhcmNoIG9u IHRoZSBpbnRlcm5hbCBzdGF0ZS4gVGhlc2UgaW50ZXJuYWwgY29sbGlzaW9uIGF0dGFja3MgZG8g bm90IGFmZmVjdCB0aGUgc2VjdXJpdHkgb2YgU0hBMywgYmVjYXVzZSBvZiB0aGUgbGFyZ2VyIGNh cGFjaXR5IHVzZWQuDQoNCkFsdGVybmF0aXZlbHksIGp1c3QgZHJvcCB0aGUgcmVmZXJlbmNlIHRv IFNIQTMsIHdoaWNoIGlzbuKAmXQgcmVsZXZlbnQgdG8gWE1TUy4NCg0KVGhlIG90aGVyIG5pdCBp cyB3aXRoIHRoZSBzZW50ZW5jZSB0aGF0IHN0YXJ0czoNCg0KQW55IGF0dGFjayB0aGF0IGJyZWFr cyB0aGUgcmVsZXZhbnQgc2VjdXJpdHkgZGVmaW5pdGlvbiBtdXN0IHJlcXVpcmUgY29tcHV0YXRp b25hbCByZXNvdXJjZXPigKYNCg0KVGhhdCBzb3J0IG9mIHN0YXRlbWVudCBhbHdheXMgaGFzIGFu IGltcGxpY2l0IGFzc3VtcHRpb24gb2YgdGhlIGZvcm0g4oCcdW5sZXNzIHNvbWVvbmUgaGFzIGEg Y3J5cHRvZ3JhcGhpY2FsIHJlc3VsdCBhZ2FpbnN0IHRoZSBTSEEtMyBwZXJtdXRhdGlvbuKAnTsg d2hpbGUgd2UgYXJlIHVzZWQgdG8gdGhhdCBzb3J0IG9mIGFzc3VtcHRpb24sIGEgY2F1c2FsIHJl YWRlciBtaWdodCBub3QgYmUuICBJIGRvbuKAmXQgc2VlIHdoYXQgdGhhdCBzZW50ZW5jZSBicmlu Z3MgdG8gdGhlIHRhYmxlOyBJ4oCZZCBzdWdnZXN0IGRyb3BwaW5nIGl0Lg0KDQpGcm9tOiBDcnlw dG8tcGFuZWwgPGNyeXB0by1wYW5lbC1ib3VuY2VzQGlydGYub3JnPiBPbiBCZWhhbGYgT2YgU3Rh bmlzbGF2IFYuIFNteXNobHlhZXYNClNlbnQ6IFRodXJzZGF5LCBKdW5lIDExLCAyMDIwIDE6NTcg UE0NClRvOiBjcnlwdG8tcGFuZWxAaXJ0Zi5vcmcNCkNjOiBjZnJnLWNoYWlyc0BpZXRmLm9yZw0K U3ViamVjdDogW0NyeXB0by1wYW5lbF0gRndkOiBbaXJzZ10gW1RlY2huaWNhbCBFcnJhdGEgUmVw b3J0ZWRdIFJGQzgzOTEgKDYwMjQpDQoNCkRlYXIgQ3J5cHRvIFJldmlldyBQYW5lbCBtZW1iZXJz LA0KDQpUaGVyZSBpcyBhIG5lZWQgdG8gdmFsaWRhdGUgdGhlIGZvbGxvd2luZyBlcnJhdGE6DQpo dHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNjAyNDxodHRwczovL3d3dy5yZmMt ZWRpdG9yLi5vcmcvZXJyYXRhL2VpZDYwMjQ+DQoNCkFueSB2b2x1bnRlZXJzPw0KDQpSZWdhcmRz LA0KQ0ZSRyBjaGFpcnMNCg0KDQoNCi0tLS0tLS0tLS0g0J/QtdGA0LXRgdGL0LvQsNC10LzQvtC1 INGB0L7QvtCx0YnQtdC90LjQtSAtLS0tLS0tLS0NCtCe0YI6IENvbGluIFBlcmtpbnMgPGNzcEBj c3BlcmtpbnMub3JnPG1haWx0bzpjc3BAY3NwZXJraW5zLm9yZz4+DQrQlNCw0YLQsDog0YHQsSwg NiDQuNGO0L3RjyAyMDIwINCzLiDQsiAxNjowMw0K0KLQtdC80LA6IEZ3ZDogW2lyc2ddIFtUZWNo bmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM4MzkxICg2MDI0KQ0K0JrQvtC80YM6IDxjZnJnLWNo YWlyc0BpZXRmLm9yZzxtYWlsdG86Y2ZyZy1jaGFpcnNAaWV0Zi5vcmc+Pg0KDQpIaSBDRlJHIGNo YWlycywNCg0KQ2FuIHlvdSBkaXNjdXNzLCBhbmQgcmV2aWV3IHdpdGggdGhlIFJHIGlmIG5lY2Vz c2FyeSwgYW5kIGxldCBtZSBrbm93ICBpZiB0aGUgZm9sbG93aW5nIGVycmF0YSBzaG91bGQgYmUg bWFya2VkIGFzIHZlcmlmaWVkLg0KDQpUaGFua3MsDQpDb2xpbg0KDQoNCg0KDQpCZWdpbiBmb3J3 YXJkZWQgbWVzc2FnZToNCg0KRnJvbTogUkZDIEVycmF0YSBTeXN0ZW0gPHJmYy1lZGl0b3JAcmZj LWVkaXRvci5vcmc8bWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc+Pg0KU3ViamVjdDog W2lyc2ddIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM4MzkxICg2MDI0KQ0KRGF0ZTog MTggTWFyY2ggMjAyMCBhdCAxMzowMTo1MiBHTVQNClRvOiBpZXRmQGh1ZWxzaW5nLm5ldDxtYWls dG86aWV0ZkBodWVsc2luZy5uZXQ+LCBkYnV0aW5AY2RjLmluZm9ybWF0aWsudHUtZGFybXN0YWR0 LmRlPG1haWx0bzpkYnV0aW5AY2RjLmluZm9ybWF0aWsudHUtZGFybXN0YWR0LmRlPiwgaWV0ZkBn YXpkYWcuZGU8bWFpbHRvOmlldGZAZ2F6ZGFnLmRlPiwgaWV0ZkBqb29zdHJpam5ldmVsZC5ubDxt YWlsdG86aWV0ZkBqb29zdHJpam5ldmVsZC5ubD4sIG1vaGFpc2VuQGllZWUub3JnPG1haWx0bzpt b2hhaXNlbkBpZWVlLm9yZz4sIGlyc2dAaXJ0Zi5vcmc8bWFpbHRvOmlyc2dAaXJ0Zi5vcmc+DQpD YzogaWV0ZkBodWVsc2luZy5uZXQ8bWFpbHRvOmlldGZAaHVlbHNpbmcubmV0PiwgcmZjLWVkaXRv ckByZmMtZWRpdG9yLm9yZzxtYWlsdG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZz4NCg0KVGhl IGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDODM5MSwN CiJYTVNTOiBlWHRlbmRlZCBNZXJrbGUgU2lnbmF0dXJlIFNjaGVtZSIuDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJl bG93IGFuZCBhdDoNCmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YS9laWQ2MDI0DQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUeXBlOiBUZWNobmljYWwN ClJlcG9ydGVkIGJ5OiBBbmRyZWFzIEjDvGxzaW5nIDxpZXRmQGh1ZWxzaW5nLm5ldDxtYWlsdG86 aWV0ZkBodWVsc2luZy5uZXQ+Pg0KDQpTZWN0aW9uOiA1DQoNCk9yaWdpbmFsIFRleHQNCi0tLS0t LS0tLS0tLS0NClRoaXMgc2VjdGlvbiBwcm92aWRlcyBiYXNpYyBwYXJhbWV0ZXIgc2V0cyB0aGF0 IGFyZSBhc3N1bWVkIHRvIGNvdmVyIG1vc3QgcmVsZXZhbnQgYXBwbGljYXRpb25zLiAgUGFyYW1l dGVyIHNldHMgZm9yIHR3byBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2ZWxzIGFyZSBkZWZpbmVkLiAg UGFyYW1ldGVycyB3aXRoIG4gPSAzMiBwcm92aWRlIGEgY2xhc3NpY2FsIHNlY3VyaXR5IGxldmVs IG9mIDI1NiBiaXRzLiAgUGFyYW1ldGVycyB3aXRoIG4gPSA2NCBwcm92aWRlIGEgY2xhc3NpY2Fs IHNlY3VyaXR5IGxldmVsIG9mIDUxMiBiaXRzLiAgQ29uc2lkZXJpbmcgcXVhbnR1bS1jb21wdXRl ci1haWRlZCBhdHRhY2tzLCB0aGVzZSBvdXRwdXQgc2l6ZXMgeWllbGQgcG9zdC1xdWFudHVtIHNl Y3VyaXR5IG9mIDEyOCBhbmQgMjU2IGJpdHMsIHJlc3BlY3RpdmVseS4NCg0KQ29ycmVjdGVkIFRl eHQNCi0tLS0tLS0tLS0tLS0tDQpUaGlzIHNlY3Rpb24gcHJvdmlkZXMgYmFzaWMgcGFyYW1ldGVy IHNldHMgdGhhdCBhcmUgYXNzdW1lZCB0byBjb3ZlciBtb3N0IHJlbGV2YW50IGFwcGxpY2F0aW9u cy4gUGFyYW1ldGVyIHNldHMgZm9yIHR3byBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2ZWxzIGFyZSBk ZWZpbmVkIHVzaW5nIHRoZSBjcnlwdG9ncmFwaGljIGZ1bmN0aW9ucyBTSEEyIGFuZCBTSEFLRS4g IFBhcmFtZXRlcnMgd2l0aCBTSEEyIGFuZCBuID0gMzIgcHJvdmlkZSBhIGNsYXNzaWNhbCBzZWN1 cml0eSBsZXZlbCBvZiAyNTYgYml0cy4gUGFyYW1ldGVycyB3aXRoIFNIQTIgYW5kIG4gPSA2NCBw cm92aWRlIGEgY2xhc3NpY2FsIHNlY3VyaXR5IGxldmVsIG9mIDUxMiBiaXRzLiAgQ29uc2lkZXJp bmcgcXVhbnR1bS1jb21wdXRlci1haWRlZCBhdHRhY2tzLCB0aGVzZSBwYXJhbWV0ZXJzIHlpZWxk IHBvc3QtcXVhbnR1bSBzZWN1cml0eSBvZiAxMjggYW5kIDI1NiBiaXRzLCByZXNwZWN0aXZlbHku IFBhcmFtZXRlcnMgd2l0aCBTSEFLRSBhbmQgbiA9IDMyIHByb3ZpZGUgYSBjbGFzc2ljYWwgc2Vj dXJpdHkgbGV2ZWwgb2YgMTI4IGJpdHMuICBQYXJhbWV0ZXJzIHdpdGggU0hBS0UgYW5kIG4gPSA2 NCBwcm92aWRlIGEgY2xhc3NpY2FsIHNlY3VyaXR5IGxldmVsIG9mIDI1NiBiaXRzLiAgQ29uc2lk ZXJpbmcgcXVhbnR1bS1jb21wdXRlci1haWRlZCBhdHRhY2tzLCB0aGVzZSBwYXJhbWV0ZXJzIHlp ZWxkIHBvc3QtcXVhbnR1bSBzZWN1cml0eSBvZiA4NiBhbmQgMTcwIGJpdHMsIHJlc3BlY3RpdmVs eS4NCg0KTm90ZXMNCi0tLS0tDQpUcmFkaXRpb25hbGx5LCBhIGhhc2ggZnVuY3Rpb24gd2l0aCBu LWJpdCBvdXRwdXRzIGlzIGFzc3VtZWQgdG8gaGF2ZSBuLWJpdCBzZWN1cml0eSBhZ2FpbnN0IGNs YXNzaWNhbCBwcmVpbWFnZSBhbmQgc2Vjb25kLXByZWltYWdlIGF0dGFja3MsIGFuZCBuLzItYml0 IHNlY3VyaXR5IGFnYWluc3QgY2xhc3NpY2FsIGNvbGxpc2lvbiBhdHRhY2tzLiBGb3IgYWR2ZXJz YXJpZXMgd2l0aCBhY2Nlc3MgdG8gYSBxdWFudHVtIGNvbXB1dGVyLCB0aGVzZSBib3VuZHMgY2hh bmdlIHRvIG4vMiBhbmQgbi8zIGJpdHMgd2hlbiBvbmx5IGNvdW50aW5nIHF1ZXJpZXMgdG8gdGhl IGhhc2ggZnVuY3Rpb24uIFRoaXMgYWxzbyBhcHBsaWVzIHRvIFNIQTIgYW5kIFNIQTMuIEluIGNv bnRyYXN0LCBTSEFLRSBmb2xsb3dzIGEgZGlmZmVyZW50IHJlYXNvbmluZy4gU0hBS0Ugd2l0aCBh biBpbnRlcm5hbCBzdGF0ZSBvZiBuIGJpdHMgYW5kIGFuIG91dHB1dCBsZW5ndGggb2YgbiBiaXRz IGFjaGlldmVzIG4vMiBiaXQgc2VjdXJpdHkgYWdhaW5zdCBjbGFzc2ljYWwgcHJlaW1hZ2UsIHNl Y29uZC1wcmVpbWFnZSBhbmQgY29sbGlzaW9uIGF0dGFja3MuIEZvciBxdWFudHVtIGF0dGFja3Mg c2VjdXJpdHkgY2hhbmdlcyB0byBuLzMgYml0cy4gVGhlIHJlYXNvbiBpcyB0aGF0IFNIQUtFIGFs bG93cyBmb3IgbWVldC1pbi10aGUtbWlkZGxlIHByZWltYWdlIGF0dGFja3MgdGhhdCByZWR1Y2Ug dG8gYSBjb2xsaXNpb24gc2VhcmNoIG9uIHRoZSBpbnRlcm5hbCBzdGF0ZS4gVGhlIHNhbWUgYXBw bGllcyBmb3IgU0hBMyBidXQgZm9yIFNIQTMgYSBiaWdnZXIgaW50ZXJuYWwgc3RhdGUgaXMgdXNl ZC4NCg0KSW4gY29uc2VxdWVuY2UsIFNIQUtFLTEyOCBjYW5ub3QgcHJvdmlkZSBtb3JlIHNlY3Vy aXR5IHRoYW4gTklTVCBwb3N0LXF1YW50dW0gc2VjdXJpdHkgbGV2ZWwgSUkgKEFueSBhdHRhY2sg dGhhdCBicmVha3MgdGhlIHJlbGV2YW50IHNlY3VyaXR5IGRlZmluaXRpb24gbXVzdCByZXF1aXJl IGNvbXB1dGF0aW9uYWwgcmVzb3VyY2VzIGNvbXBhcmFibGUgdG8gb3IgZ3JlYXRlciB0aGFuIHRo b3NlIHJlcXVpcmVkIGZvciBjb2xsaXNpb24gc2VhcmNoIG9uIGEgMjU2LWJpdCBoYXNoIGZ1bmN0 aW9uIChlLmcuIFNIQTI1NiAvIFNIQTMtMjU2KSkuDQoNCkluc3RydWN0aW9uczoNCi0tLS0tLS0t LS0tLS0NClRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICJSZXBvcnRlZCIuIElm IG5lY2Vzc2FyeSwgcGxlYXNlDQp1c2UgIlJlcGx5IEFsbCIgdG8gZGlzY3VzcyB3aGV0aGVyIGl0 IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFj aGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5DQpjYW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3RhdHVz IGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClJGQzgzOTEgKGRyYWZ0LWlydGYtY2ZyZy14bXNzLWhhc2gt YmFzZWQtc2lnbmF0dXJlcy0xMikNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpUaXRsZSAgICAgICAgICAgICAgIDogWE1TUzogZVh0ZW5kZWQgTWVya2xlIFNpZ25hdHVy ZSBTY2hlbWUNClB1YmxpY2F0aW9uIERhdGUgICAgOiBNYXkgMjAxOA0KQXV0aG9yKHMpICAgICAg ICAgICA6IEEuIEh1ZWxzaW5nLCBELiBCdXRpbiwgUy4gR2F6ZGFnLCBKLiBSaWpuZXZlbGQsIEEu LiBNb2hhaXNlbg0KQ2F0ZWdvcnkgICAgICAgICAgICA6IElORk9STUFUSU9OQUwNClNvdXJjZSAg ICAgICAgICAgICAgOiBDcnlwdG8gRm9ydW0gUmVzZWFyY2ggR3JvdXANCkFyZWEgICAgICAgICAg ICAgICAgOiBOL0ENClN0cmVhbSAgICAgICAgICAgICAgOiBJUlRGDQpWZXJpZnlpbmcgUGFydHkg ICAgIDogSVJTRw0KDQoNCg== --_000_BN7PR11MB2641199090BA16B1DE9C1375C1800BN7PR11MB2641namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNhIE5ldWUiO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcHJlDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCglt c28tc3R5bGUtbGluazoiSFRNTCBQcmVmb3JtYXR0ZWQgQ2hhciI7DQoJbWFyZ2luOjBpbjsNCglt YXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJZm9udC1zaXplOjEwLjBwdDsNCglmb250LWZhbWlseToi Q291cmllciBOZXciO30NCnAubXNvbm9ybWFsMCwgbGkubXNvbm9ybWFsMCwgZGl2Lm1zb25vcm1h bDANCgl7bXNvLXN0eWxlLW5hbWU6bXNvbm9ybWFsOw0KCW1zby1tYXJnaW4tdG9wLWFsdDphdXRv Ow0KCW1hcmdpbi1yaWdodDowaW47DQoJbXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG87DQoJbWFy Z2luLWxlZnQ6MGluOw0KCWZvbnQtc2l6ZToxMS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTkNCgl7bXNvLXN0eWxlLXR5cGU6cGVyc29u YWw7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4 dDt9DQpzcGFuLkhUTUxQcmVmb3JtYXR0ZWRDaGFyDQoJe21zby1zdHlsZS1uYW1lOiJIVE1MIFBy ZWZvcm1hdHRlZCBDaGFyIjsNCgltc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJbXNvLXN0eWxlLWxp bms6IkhUTUwgUHJlZm9ybWF0dGVkIjsNCglmb250LWZhbWlseToiQ291cmllciBOZXciO30NCnNw YW4uRW1haWxTdHlsZTIyDQoJe21zby1zdHlsZS10eXBlOnBlcnNvbmFsLWNvbXBvc2U7DQoJZm9u dC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNv Q2hwRGVmYXVsdA0KCXttc28tc3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7c2l6ZTo4LjVpbiAx MS4waW47DQoJbWFyZ2luOjEuMGluIDEuMGluIDEuMGluIDEuMGluO30NCmRpdi5Xb3JkU2VjdGlv bjENCgl7cGFnZTpXb3JkU2VjdGlvbjE7fQ0KLS0+PC9zdHlsZT48IS0tW2lmIGd0ZSBtc28gOV0+ PHhtbD4NCjxvOnNoYXBlZGVmYXVsdHMgdjpleHQ9ImVkaXQiIHNwaWRtYXg9IjEwMjYiIC8+DQo8 L3htbD48IVtlbmRpZl0tLT48IS0tW2lmIGd0ZSBtc28gOV0+PHhtbD4NCjxvOnNoYXBlbGF5b3V0 IHY6ZXh0PSJlZGl0Ij4NCjxvOmlkbWFwIHY6ZXh0PSJlZGl0IiBkYXRhPSIxIiAvPg0KPC9vOnNo YXBlbGF5b3V0PjwveG1sPjwhW2VuZGlmXS0tPg0KPC9oZWFkPg0KPGJvZHkgbGFuZz0iRU4tVVMi IGxpbms9ImJsdWUiIHZsaW5rPSJwdXJwbGUiPg0KPGRpdiBjbGFzcz0iV29yZFNlY3Rpb24xIj4N CjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGUgdGV4dCBsb29rcyBj b3JyZWN0LCBob3dldmVyIEkgZG8gaGF2ZSBhIGZldyBuaXRzIGFib3V0IHRoZSBub3Rlcy4mbmJz cDsgT25lIGlzIHRoZSByZWZlcmVuY2UgdG8gU0hBMywgd2hpY2ggb24gYSBxdWljayByZWFkIG1p Z2h0IGJlIG1pc2xlYWRpbmc7IGhlcmUgaXMgc29tZSBhbHRlcmF0aXZlIHRleHQ6PG86cD48L286 cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxv OnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0 eWxlPSJmb250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMt c2VyaWY7Y29sb3I6IzJDNDM1MztiYWNrZ3JvdW5kOiNFM0UzRTMiPlRoZSByZWFzb24gaXMgdGhh dCBTSEFLRSBhbGxvd3MgZm9yIG1lZXQtaW4tdGhlLW1pZGRsZSBwcmVpbWFnZSBhdHRhY2tzIHRo YXQgcmVkdWNlIHRvIGEgY29sbGlzaW9uIHNlYXJjaCBvbiB0aGUgaW50ZXJuYWwgc3RhdGUuDQo8 Yj5UaGVzZSBpbnRlcm5hbCBjb2xsaXNpb24gYXR0YWNrcyBkbyBub3QgYWZmZWN0IHRoZSBzZWN1 cml0eSBvZiBTSEEzLCBiZWNhdXNlIG9mIHRoZSBsYXJnZXIgY2FwYWNpdHkgdXNlZC48bzpwPjwv bzpwPjwvYj48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9 ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJp Zjtjb2xvcjojMkM0MzUzO2JhY2tncm91bmQ6I0UzRTNFMyI+PG86cD4mbmJzcDs8L286cD48L3Nw YW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5BbHRl cm5hdGl2ZWx5LCBqdXN0IGRyb3AgdGhlIHJlZmVyZW5jZSB0byBTSEEzLCB3aGljaCBpc27igJl0 IHJlbGV2ZW50IHRvIFhNU1MuPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tR0IiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGUgb3RoZXIgbml0IGlzIHdp dGggdGhlIHNlbnRlbmNlIHRoYXQgc3RhcnRzOjxvOnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bh bj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVw dDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyQzQzNTM7 YmFja2dyb3VuZDojRTNFM0UzIj5BbnkgYXR0YWNrIHRoYXQgYnJlYWtzIHRoZSByZWxldmFudCBz ZWN1cml0eSBkZWZpbml0aW9uIG11c3QgcmVxdWlyZSBjb21wdXRhdGlvbmFsIHJlc291cmNlc+KA pjwvc3Bhbj48c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1p bHk6JnF1b3Q7QXJpYWwmcXVvdDssc2Fucy1zZXJpZjtjb2xvcjojMkM0MzUzO2JhY2tncm91bmQ6 I0UzRTNFMyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9iPjwvcD4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxzcGFuIGxhbmc9IkVOLUdCIj5UaGF0IHNvcnQgb2Ygc3RhdGVtZW50IGFsd2F5cyBo YXMgYW4gaW1wbGljaXQgYXNzdW1wdGlvbiBvZiB0aGUgZm9ybSDigJx1bmxlc3Mgc29tZW9uZSBo YXMgYSBjcnlwdG9ncmFwaGljYWwgcmVzdWx0IGFnYWluc3QgdGhlIFNIQS0zIHBlcm11dGF0aW9u 4oCdOyB3aGlsZSB3ZSBhcmUgdXNlZCB0byB0aGF0IHNvcnQgb2YgYXNzdW1wdGlvbiwgYSBjYXVz YWwgcmVhZGVyIG1pZ2h0IG5vdA0KIGJlLiZuYnNwOyBJIGRvbuKAmXQgc2VlIHdoYXQgdGhhdCBz ZW50ZW5jZSBicmluZ3MgdG8gdGhlIHRhYmxlOyBJ4oCZZCBzdWdnZXN0IGRyb3BwaW5nIGl0Ljxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzJDNDM1MztiYWNrZ3JvdW5kOiNFM0UzRTMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFu PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+RnJvbTo8L2I+IENyeXB0by1wYW5lbCAm bHQ7Y3J5cHRvLXBhbmVsLWJvdW5jZXNAaXJ0Zi5vcmcmZ3Q7IDxiPg0KT24gQmVoYWxmIE9mIDwv Yj5TdGFuaXNsYXYgVi4gU215c2hseWFldjxicj4NCjxiPlNlbnQ6PC9iPiBUaHVyc2RheSwgSnVu ZSAxMSwgMjAyMCAxOjU3IFBNPGJyPg0KPGI+VG86PC9iPiBjcnlwdG8tcGFuZWxAaXJ0Zi5vcmc8 YnI+DQo8Yj5DYzo8L2I+IGNmcmctY2hhaXJzQGlldGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+ IFtDcnlwdG8tcGFuZWxdIEZ3ZDogW2lyc2ddIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBS RkM4MzkxICg2MDI0KTxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5EZWFyIENyeXB0byBSZXZpZXcgUGFuZWwgbWVtYmVycyw8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZSBp cyBhIG5lZWQgdG8gdmFsaWRhdGUgdGhlIGZvbGxvd2luZyBlcnJhdGE6PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGEgaHJlZj0iaHR0 cHM6Ly93d3cucmZjLWVkaXRvci4ub3JnL2VycmF0YS9laWQ2MDI0Ij5odHRwczovL3d3dy5yZmMt ZWRpdG9yLm9yZy9lcnJhdGEvZWlkNjAyNDwvYT48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QW55IHZvbHVudGVlcnM/PG86cD48L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwv cD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlJlZ2FyZHMsPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5DRlJHIGNoYWlyczxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFs Ij48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3Jt YWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPi0tLS0tLS0tLS0g0J/QtdGA0LXRgdGL0LvQsNC10LzQvtC1INGB0L7QvtCx0YnQtdC9 0LjQtSAtLS0tLS0tLS08YnI+DQrQntGCOiA8c3Ryb25nPjxzcGFuIHN0eWxlPSJmb250LWZhbWls eTomcXVvdDtDYWxpYnJpJnF1b3Q7LHNhbnMtc2VyaWYiPkNvbGluIFBlcmtpbnM8L3NwYW4+PC9z dHJvbmc+ICZsdDs8YSBocmVmPSJtYWlsdG86Y3NwQGNzcGVya2lucy5vcmciPmNzcEBjc3Blcmtp bnMub3JnPC9hPiZndDs8YnI+DQrQlNCw0YLQsDog0YHQsSwgNiDQuNGO0L3RjyAyMDIwINCzLiDQ siAxNjowMzxicj4NCtCi0LXQvNCwOiBGd2Q6IFtpcnNnXSBbVGVjaG5pY2FsIEVycmF0YSBSZXBv cnRlZF0gUkZDODM5MSAoNjAyNCk8YnI+DQrQmtC+0LzRgzogJmx0OzxhIGhyZWY9Im1haWx0bzpj ZnJnLWNoYWlyc0BpZXRmLm9yZyI+Y2ZyZy1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibWFyZ2luLWJvdHRv bToxMi4wcHQiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5IaSBDRlJHIGNoYWlycyw8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPkNhbiB5b3UgZGlzY3VzcywgYW5kIHJldmlldyB3aXRoIHRoZSBSRyBp ZiBuZWNlc3NhcnksIGFuZCBsZXQgbWUga25vdyAmbmJzcDtpZiB0aGUgZm9sbG93aW5nIGVycmF0 YSBzaG91bGQgYmUgbWFya2VkIGFzIHZlcmlmaWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGFua3MsPG86cD48L286cD48L3A+DQo8L2Rp dj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5Db2xpbjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48YnI+DQo8YnI+DQo8bzpwPjwvbzpwPjwvcD4N CjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206NS4wcHQi Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPkJlZ2luIGZvcndhcmRlZCBtZXNzYWdlOjxv OnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwv bzpwPjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9u dC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6YmxhY2siPkZyb206DQo8 L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZx dW90OyI+UkZDIEVycmF0YSBTeXN0ZW0gJmx0OzxhIGhyZWY9Im1haWx0bzpyZmMtZWRpdG9yQHJm Yy1lZGl0b3Iub3JnIiB0YXJnZXQ9Il9ibGFuayI+cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZzwv YT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVl JnF1b3Q7O2NvbG9yOmJsYWNrIj5TdWJqZWN0Og0KPC9zcGFuPjwvYj48Yj48c3BhbiBzdHlsZT0i Zm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsiPltpcnNnXSBbVGVjaG5pY2Fs IEVycmF0YSBSZXBvcnRlZF0gUkZDODM5MSAoNjAyNCk8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOmJsYWNrIj5EYXRlOg0K PC9zcGFuPjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUm cXVvdDsiPjE4IE1hcmNoIDIwMjAgYXQgMTM6MDE6NTIgR01UPC9zcGFuPjxvOnA+PC9vOnA+PC9w Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PGI+PHNwYW4gc3R5bGU9ImZv bnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2NvbG9yOmJsYWNrIj5UbzoNCjwv c3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1 b3Q7Ij48YSBocmVmPSJtYWlsdG86aWV0ZkBodWVsc2luZy5uZXQiIHRhcmdldD0iX2JsYW5rIj5p ZXRmQGh1ZWxzaW5nLm5ldDwvYT4sDQo8YSBocmVmPSJtYWlsdG86ZGJ1dGluQGNkYy5pbmZvcm1h dGlrLnR1LWRhcm1zdGFkdC5kZSIgdGFyZ2V0PSJfYmxhbmsiPmRidXRpbkBjZGMuaW5mb3JtYXRp ay50dS1kYXJtc3RhZHQuZGU8L2E+LA0KPGEgaHJlZj0ibWFpbHRvOmlldGZAZ2F6ZGFnLmRlIiB0 YXJnZXQ9Il9ibGFuayI+aWV0ZkBnYXpkYWcuZGU8L2E+LCA8YSBocmVmPSJtYWlsdG86aWV0ZkBq b29zdHJpam5ldmVsZC5ubCIgdGFyZ2V0PSJfYmxhbmsiPg0KaWV0ZkBqb29zdHJpam5ldmVsZC5u bDwvYT4sIDxhIGhyZWY9Im1haWx0bzptb2hhaXNlbkBpZWVlLm9yZyIgdGFyZ2V0PSJfYmxhbmsi Pm1vaGFpc2VuQGllZWUub3JnPC9hPiwNCjxhIGhyZWY9Im1haWx0bzppcnNnQGlydGYub3JnIiB0 YXJnZXQ9Il9ibGFuayI+aXJzZ0BpcnRmLm9yZzwvYT48L3NwYW4+PG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48Yj48c3BhbiBzdHlsZT0iZm9udC1m YW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6YmxhY2siPkNjOg0KPC9zcGFu PjwvYj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDsi PjxhIGhyZWY9Im1haWx0bzppZXRmQGh1ZWxzaW5nLm5ldCIgdGFyZ2V0PSJfYmxhbmsiPmlldGZA aHVlbHNpbmcubmV0PC9hPiwNCjxhIGhyZWY9Im1haWx0bzpyZmMtZWRpdG9yQHJmYy1lZGl0b3Iu b3JnIiB0YXJnZXQ9Il9ibGFuayI+cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZzwvYT48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7 PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGUgZm9sbG93 aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0dGVkIGZvciBSRkM4MzkxLDxicj4NCiZx dW90O1hNU1M6IGVYdGVuZGVkIE1lcmtsZSBTaWduYXR1cmUgU2NoZW1lJnF1b3Q7Ljxicj4NCjxi cj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tPGJyPg0KWW91IG1heSBy ZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6PGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cu cmZjLWVkaXRvci5vcmcvZXJyYXRhL2VpZDYwMjQiIHRhcmdldD0iX2JsYW5rIj5odHRwczovL3d3 dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNjAyNDwvYT48YnI+DQo8YnI+DQotLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4NClR5cGU6IFRlY2huaWNhbDxicj4NClJl cG9ydGVkIGJ5OiBBbmRyZWFzIEjDvGxzaW5nICZsdDs8YSBocmVmPSJtYWlsdG86aWV0ZkBodWVs c2luZy5uZXQiIHRhcmdldD0iX2JsYW5rIj5pZXRmQGh1ZWxzaW5nLm5ldDwvYT4mZ3Q7PGJyPg0K PGJyPg0KU2VjdGlvbjogNTxicj4NCjxicj4NCk9yaWdpbmFsIFRleHQ8YnI+DQotLS0tLS0tLS0t LS0tPGJyPg0KVGhpcyBzZWN0aW9uIHByb3ZpZGVzIGJhc2ljIHBhcmFtZXRlciBzZXRzIHRoYXQg YXJlIGFzc3VtZWQgdG8gY292ZXIgbW9zdCByZWxldmFudCBhcHBsaWNhdGlvbnMuJm5ic3A7IFBh cmFtZXRlciBzZXRzIGZvciB0d28gY2xhc3NpY2FsIHNlY3VyaXR5IGxldmVscyBhcmUgZGVmaW5l ZC4mbmJzcDsgUGFyYW1ldGVycyB3aXRoIG4gPSAzMiBwcm92aWRlIGEgY2xhc3NpY2FsIHNlY3Vy aXR5IGxldmVsIG9mIDI1NiBiaXRzLiZuYnNwOyBQYXJhbWV0ZXJzIHdpdGggbiA9IDY0IHByb3Zp ZGUNCiBhIGNsYXNzaWNhbCBzZWN1cml0eSBsZXZlbCBvZiA1MTIgYml0cy4mbmJzcDsgQ29uc2lk ZXJpbmcgcXVhbnR1bS1jb21wdXRlci1haWRlZCBhdHRhY2tzLCB0aGVzZSBvdXRwdXQgc2l6ZXMg eWllbGQgcG9zdC1xdWFudHVtIHNlY3VyaXR5IG9mIDEyOCBhbmQgMjU2IGJpdHMsIHJlc3BlY3Rp dmVseS48YnI+DQo8YnI+DQpDb3JyZWN0ZWQgVGV4dDxicj4NCi0tLS0tLS0tLS0tLS0tPGJyPg0K VGhpcyBzZWN0aW9uIHByb3ZpZGVzIGJhc2ljIHBhcmFtZXRlciBzZXRzIHRoYXQgYXJlIGFzc3Vt ZWQgdG8gY292ZXIgbW9zdCByZWxldmFudCBhcHBsaWNhdGlvbnMuIFBhcmFtZXRlciBzZXRzIGZv ciB0d28gY2xhc3NpY2FsIHNlY3VyaXR5IGxldmVscyBhcmUgZGVmaW5lZCB1c2luZyB0aGUgY3J5 cHRvZ3JhcGhpYyBmdW5jdGlvbnMgU0hBMiBhbmQgU0hBS0UuJm5ic3A7IFBhcmFtZXRlcnMgd2l0 aCBTSEEyIGFuZCBuID0gMzIgcHJvdmlkZSBhIGNsYXNzaWNhbA0KIHNlY3VyaXR5IGxldmVsIG9m IDI1NiBiaXRzLiBQYXJhbWV0ZXJzIHdpdGggU0hBMiBhbmQgbiA9IDY0IHByb3ZpZGUgYSBjbGFz c2ljYWwgc2VjdXJpdHkgbGV2ZWwgb2YgNTEyIGJpdHMuJm5ic3A7IENvbnNpZGVyaW5nIHF1YW50 dW0tY29tcHV0ZXItYWlkZWQgYXR0YWNrcywgdGhlc2UgcGFyYW1ldGVycyB5aWVsZCBwb3N0LXF1 YW50dW0gc2VjdXJpdHkgb2YgMTI4IGFuZCAyNTYgYml0cywgcmVzcGVjdGl2ZWx5LiBQYXJhbWV0 ZXJzIHdpdGggU0hBS0UgYW5kDQogbiA9IDMyIHByb3ZpZGUgYSBjbGFzc2ljYWwgc2VjdXJpdHkg bGV2ZWwgb2YgMTI4IGJpdHMuJm5ic3A7IFBhcmFtZXRlcnMgd2l0aCBTSEFLRSBhbmQgbiA9IDY0 IHByb3ZpZGUgYSBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2ZWwgb2YgMjU2IGJpdHMuJm5ic3A7IENv bnNpZGVyaW5nIHF1YW50dW0tY29tcHV0ZXItYWlkZWQgYXR0YWNrcywgdGhlc2UgcGFyYW1ldGVy cyB5aWVsZCBwb3N0LXF1YW50dW0gc2VjdXJpdHkgb2YgODYgYW5kIDE3MCBiaXRzLCByZXNwZWN0 aXZlbHkuDQo8YnI+DQo8YnI+DQpOb3Rlczxicj4NCi0tLS0tPGJyPg0KVHJhZGl0aW9uYWxseSwg YSBoYXNoIGZ1bmN0aW9uIHdpdGggbi1iaXQgb3V0cHV0cyBpcyBhc3N1bWVkIHRvIGhhdmUgbi1i aXQgc2VjdXJpdHkgYWdhaW5zdCBjbGFzc2ljYWwgcHJlaW1hZ2UgYW5kIHNlY29uZC1wcmVpbWFn ZSBhdHRhY2tzLCBhbmQgbi8yLWJpdCBzZWN1cml0eSBhZ2FpbnN0IGNsYXNzaWNhbCBjb2xsaXNp b24gYXR0YWNrcy4gRm9yIGFkdmVyc2FyaWVzIHdpdGggYWNjZXNzIHRvIGEgcXVhbnR1bSBjb21w dXRlciwgdGhlc2UgYm91bmRzDQogY2hhbmdlIHRvIG4vMiBhbmQgbi8zIGJpdHMgd2hlbiBvbmx5 IGNvdW50aW5nIHF1ZXJpZXMgdG8gdGhlIGhhc2ggZnVuY3Rpb24uIFRoaXMgYWxzbyBhcHBsaWVz IHRvIFNIQTIgYW5kIFNIQTMuIEluIGNvbnRyYXN0LCBTSEFLRSBmb2xsb3dzIGEgZGlmZmVyZW50 IHJlYXNvbmluZy4gU0hBS0Ugd2l0aCBhbiBpbnRlcm5hbCBzdGF0ZSBvZiBuIGJpdHMgYW5kIGFu IG91dHB1dCBsZW5ndGggb2YgbiBiaXRzIGFjaGlldmVzIG4vMiBiaXQgc2VjdXJpdHkNCiBhZ2Fp bnN0IGNsYXNzaWNhbCBwcmVpbWFnZSwgc2Vjb25kLXByZWltYWdlIGFuZCBjb2xsaXNpb24gYXR0 YWNrcy4gRm9yIHF1YW50dW0gYXR0YWNrcyBzZWN1cml0eSBjaGFuZ2VzIHRvIG4vMyBiaXRzLiBU aGUgcmVhc29uIGlzIHRoYXQgU0hBS0UgYWxsb3dzIGZvciBtZWV0LWluLXRoZS1taWRkbGUgcHJl aW1hZ2UgYXR0YWNrcyB0aGF0IHJlZHVjZSB0byBhIGNvbGxpc2lvbiBzZWFyY2ggb24gdGhlIGlu dGVybmFsIHN0YXRlLiBUaGUgc2FtZSBhcHBsaWVzDQogZm9yIFNIQTMgYnV0IGZvciBTSEEzIGEg YmlnZ2VyIGludGVybmFsIHN0YXRlIGlzIHVzZWQuPGJyPg0KPGJyPg0KSW4gY29uc2VxdWVuY2Us IFNIQUtFLTEyOCBjYW5ub3QgcHJvdmlkZSBtb3JlIHNlY3VyaXR5IHRoYW4gTklTVCBwb3N0LXF1 YW50dW0gc2VjdXJpdHkgbGV2ZWwgSUkgKEFueSBhdHRhY2sgdGhhdCBicmVha3MgdGhlIHJlbGV2 YW50IHNlY3VyaXR5IGRlZmluaXRpb24gbXVzdCByZXF1aXJlIGNvbXB1dGF0aW9uYWwgcmVzb3Vy Y2VzIGNvbXBhcmFibGUgdG8gb3IgZ3JlYXRlciB0aGFuIHRob3NlIHJlcXVpcmVkIGZvciBjb2xs aXNpb24gc2VhcmNoIG9uDQogYSAyNTYtYml0IGhhc2ggZnVuY3Rpb24gKGUuZy4gU0hBMjU2IC8g U0hBMy0yNTYpKS48YnI+DQo8YnI+DQpJbnN0cnVjdGlvbnM6PGJyPg0KLS0tLS0tLS0tLS0tLTxi cj4NClRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICZxdW90O1JlcG9ydGVkJnF1 b3Q7LiBJZiBuZWNlc3NhcnksIHBsZWFzZTxicj4NCnVzZSAmcXVvdDtSZXBseSBBbGwmcXVvdDsg dG8gZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2ZXJpZmllZCBvcjxicj4NCnJlamVjdGVk LiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhlIHZlcmlmeWluZyBwYXJ0eSAmbmJzcDs8 YnI+DQpjYW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3RhdHVzIGFuZCBlZGl0IHRoZSByZXBvcnQs IGlmIG5lY2Vzc2FyeS4gPGJyPg0KPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS08YnI+DQpSRkM4MzkxIChkcmFmdC1pcnRmLWNmcmcteG1zcy1oYXNoLWJhc2VkLXNp Z25hdHVyZXMtMTIpPGJyPg0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08 YnI+DQpUaXRsZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IFhNU1M6IGVYdGVuZGVkIE1l cmtsZSBTaWduYXR1cmUgU2NoZW1lPGJyPg0KUHVibGljYXRpb24gRGF0ZSAmbmJzcDsmbmJzcDsm bmJzcDs6IE1heSAyMDE4PGJyPg0KQXV0aG9yKHMpICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogQS4gSHVlbHNpbmcsIEQuIEJ1dGlu LCBTLiBHYXpkYWcsIEouIFJpam5ldmVsZCwgQS4uIE1vaGFpc2VuPGJyPg0KQ2F0ZWdvcnkgJm5i c3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7OiBJTkZPUk1BVElPTkFMPGJyPg0KU291cmNlICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOzog Q3J5cHRvIEZvcnVtIFJlc2VhcmNoIEdyb3VwPGJyPg0KQXJlYSAmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDs6IE4vQTxicj4NClN0cmVhbSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IElS VEY8YnI+DQpWZXJpZnlpbmcgUGFydHkgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBJUlNHPG86 cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJz cDs8L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9k aXY+DQo8L2Rpdj4NCjwvYm9keT4NCjwvaHRtbD4NCg== --_000_BN7PR11MB2641199090BA16B1DE9C1375C1800BN7PR11MB2641namp_-- From nobody Thu Jun 11 12:51:42 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F7053A085D for ; Thu, 11 Jun 2020 12:51:41 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b0eZQ4zAHM-J for ; Thu, 11 Jun 2020 12:51:38 -0700 (PDT) Received: from mail-lf1-x131.google.com (mail-lf1-x131.google.com [IPv6:2a00:1450:4864:20::131]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 792343A07DC for ; Thu, 11 Jun 2020 12:51:37 -0700 (PDT) Received: by mail-lf1-x131.google.com with SMTP id j12so4205384lfh.0 for ; Thu, 11 Jun 2020 12:51:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nxT2+T3W+Oj/CLMmyjF+nl/yblXcWUfr37pJ2sy7oGs=; b=mCsk4CKhNbEToDE1Or1VcROUmmurlMpb4w184yLCbzgaBALU9CTeEUtIKq9PUuQhDD idqaqotkDDXbw9WM/jZ9DOeeMqZoRYK8/DjjJQL+38lwYRuBawNUVxMbkXgep5PicZ+T a43fmM314EnFsHZhlpQoRaWeKdfnsFUxXeSrB+XXwb3eGnMBC7g7ES5y1bFty65dfw2+ nlPiNl6i4u1BuD/7x1c0hrVi65T65M0pHPspZ1NKoyRh/M0fecqSoBW0eCBjzKBPYTzJ Pnf0707nnqm0fL6NeQjSVRTBe9+MIFBzc+GpQABQUY9i3jcYg2yy0N8QaiQzAdL4jIWx hc1w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nxT2+T3W+Oj/CLMmyjF+nl/yblXcWUfr37pJ2sy7oGs=; b=FeLENQz2OZ7tljNGiTqxoICZhkrl73TunslS3OrAOIrIHLqNLAhI1Cayc0PgdR1lCa 86p+1B1lGJl3hvKjREfkEKEc2Vs6QdsMowbM6jvmNROzNIK/iQ+aT0FS+Nb/iRSsCzsa TynsbjypVrL/VjSC9raF84/t4odEiCmmDGPWhgH5OsGasL8+zbLTe8Cs/bDarK95Hyg4 r3vnVguiEb6t6zkn2XQTwvZj960LYvj/de4wk+HJwbYtLD+akOl+djLceT0UstkydGSX ERoNj01L62ed2PTOGAiQEE4hea54Y0+8C4Vb8G/8CqWlrTBwLNaR1xmxJ4byXTtOHinb O2tQ== X-Gm-Message-State: AOAM532b/TIIdx6pUJO8BucAaPQEzvmAdFWURZmMuN9kYY3N69btr2jv 3oK0hLk0UZvQcBHn0PbivHQNZ0yHbtGrHxS5Oxw= X-Google-Smtp-Source: ABdhPJwA8CxbWv1aH42hFwhw4Brg6sPjS953/xHNktUZSJHKW98R2h+zw5M7iEw5aV+n/36xhM6vCC3YDa/psopfEpg= X-Received: by 2002:ac2:4ac2:: with SMTP id m2mr3246060lfp.94.1591905095478; Thu, 11 Jun 2020 12:51:35 -0700 (PDT) MIME-Version: 1.0 References: <20200318130152.57FD7F4071D@rfc-editor.org> In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Thu, 11 Jun 2020 22:51:28 +0300 Message-ID: To: "Scott Fluhrer (sfluhrer)" Cc: "crypto-panel@irtf.org" , "cfrg-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000bb735005a7d4499a" Archived-At: Subject: Re: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024) X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jun 2020 19:51:41 -0000 --000000000000bb735005a7d4499a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thank you, Scott! Here is the correct link: https://www.rfc-editor.org/errata/eid6024 Regards, Stanislav On Thu, 11 Jun 2020 at 22:12, Scott Fluhrer (sfluhrer) wrote: > I volunteer; however I can=E2=80=99t read the link. Did you send it corr= ectly? > > > > Actually, the corrected text you include below looks decent (although the > discussion of SHA3 may be a bit misleading =E2=80=93 SHA-3 has more than = n/2 bits > of security, which someone might assume from a quick reading of =E2=80=9C= The same > applies for SHA3=E2=80=A6=E2=80=9D). > > > > I=E2=80=99d want to see the full errata before I place my seal of approva= l, of > course. > > > > *From:* Crypto-panel * On Behalf Of *Stan= islav > V. Smyshlyaev > *Sent:* Thursday, June 11, 2020 1:57 PM > *To:* crypto-panel@irtf.org > *Cc:* cfrg-chairs@ietf.org > *Subject:* [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 > (6024) > > > > Dear Crypto Review Panel members, > > > > There is a need to validate the following errata: > > https://www.rfc-editor.org/errata/eid6024 > > > > > Any volunteers? > > > > Regards, > > CFRG chairs > > > > > > > > ---------- =D0=9F=D0=B5=D1=80=D0=B5=D1=81=D1=8B=D0=BB=D0=B0=D0=B5=D0=BC= =D0=BE=D0=B5 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B5 -------= -- > =D0=9E=D1=82: *Colin Perkins* > =D0=94=D0=B0=D1=82=D0=B0: =D1=81=D0=B1, 6 =D0=B8=D1=8E=D0=BD=D1=8F 2020 = =D0=B3. =D0=B2 16:03 > =D0=A2=D0=B5=D0=BC=D0=B0: Fwd: [irsg] [Technical Errata Reported] RFC8391= (6024) > =D0=9A=D0=BE=D0=BC=D1=83: > > > > Hi CFRG chairs, > > > > Can you discuss, and review with the RG if necessary, and let me know if > the following errata should be marked as verified. > > > > Thanks, > > Colin > > > > > > > > Begin forwarded message: > > > > *From: *RFC Errata System > > *Subject: **[irsg] [Technical Errata Reported] RFC8391 (6024)* > > *Date: *18 March 2020 at 13:01:52 GMT > > *To: *ietf@huelsing.net, dbutin@cdc.informatik.tu-darmstadt.de, > ietf@gazdag.de, ietf@joostrijneveld.nl, mohaisen@ieee.org, irsg@irtf.org > > *Cc: *ietf@huelsing.net, rfc-editor@rfc-editor.org > > > > The following errata report has been submitted for RFC8391, > "XMSS: eXtended Merkle Signature Scheme". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6024 > > -------------------------------------- > Type: Technical > Reported by: Andreas H=C3=BClsing > > Section: 5 > > Original Text > ------------- > This section provides basic parameter sets that are assumed to cover most > relevant applications. Parameter sets for two classical security levels > are defined. Parameters with n =3D 32 provide a classical security level= of > 256 bits. Parameters with n =3D 64 provide a classical security level of= 512 > bits. Considering quantum-computer-aided attacks, these output sizes yie= ld > post-quantum security of 128 and 256 bits, respectively. > > Corrected Text > -------------- > This section provides basic parameter sets that are assumed to cover most > relevant applications. Parameter sets for two classical security levels a= re > defined using the cryptographic functions SHA2 and SHAKE. Parameters wit= h > SHA2 and n =3D 32 provide a classical security level of 256 bits. Paramet= ers > with SHA2 and n =3D 64 provide a classical security level of 512 bits. > Considering quantum-computer-aided attacks, these parameters yield > post-quantum security of 128 and 256 bits, respectively. Parameters with > SHAKE and n =3D 32 provide a classical security level of 128 bits. > Parameters with SHAKE and n =3D 64 provide a classical security level of = 256 > bits. Considering quantum-computer-aided attacks, these parameters yield > post-quantum security of 86 and 170 bits, respectively. > > Notes > ----- > Traditionally, a hash function with n-bit outputs is assumed to have n-bi= t > security against classical preimage and second-preimage attacks, and > n/2-bit security against classical collision attacks. For adversaries wit= h > access to a quantum computer, these bounds change to n/2 and n/3 bits whe= n > only counting queries to the hash function. This also applies to SHA2 and > SHA3. In contrast, SHAKE follows a different reasoning. SHAKE with an > internal state of n bits and an output length of n bits achieves n/2 bit > security against classical preimage, second-preimage and collision attack= s. > For quantum attacks security changes to n/3 bits. The reason is that SHAK= E > allows for meet-in-the-middle preimage attacks that reduce to a collision > search on the internal state. The same applies for SHA3 but for SHA3 a > bigger internal state is used. > > In consequence, SHAKE-128 cannot provide more security than NIST > post-quantum security level II (Any attack that breaks the relevant > security definition must require computational resources comparable to or > greater than those required for collision search on a 256-bit hash functi= on > (e.g. SHA256 / SHA3-256)). > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8391 (draft-irtf-cfrg-xmss-hash-based-signatures-12) > -------------------------------------- > Title : XMSS: eXtended Merkle Signature Scheme > Publication Date : May 2018 > Author(s) : A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A.. > Mohaisen > Category : INFORMATIONAL > Source : Crypto Forum Research Group > Area : N/A > Stream : IRTF > Verifying Party : IRSG > > > > > --000000000000bb735005a7d4499a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thank you, Scott!

Here is the correct l= ink:=C2=A0https://www= .rfc-editor.org/errata/eid6024

Regards,
<= div>Stanislav

On Thu, 11 Jun 2020 at 22:12, Scott Fluhrer (sfluhrer) &= lt;sfluhrer@cisco.com> wrote:<= br>

I volunteer; however I can=E2=80=99t read the link.= =C2=A0 Did you send it correctly?

=C2=A0

Actually, the corrected text you include below looks= decent (although the discussion of SHA3 may be a bit misleading =E2=80=93 = SHA-3 has more than n/2 bits of security, which someone might assume from a= quick reading of =E2=80=9CThe same applies for SHA3=E2=80=A6=E2=80=9D).=

=C2=A0

I=E2=80=99d want to see the full errata before I pla= ce my seal of approval, of course.

=C2=A0

From: Crypto-panel <crypto-panel-bounces@irtf.org<= /a>> On Behalf Of Stanislav V. Smyshlyaev
Sent: Thursday, June 11, 2020 1:57 PM
To: crypt= o-panel@irtf.org
Cc: cfrg-c= hairs@ietf.org
Subject: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8= 391 (6024)

=C2=A0

Dear Crypto Review Panel members,

=C2=A0

There is a need to validate the following errata:=

=C2=A0

Any volunteers?

=C2=A0

Regards,

CFRG chairs

=C2=A0

=C2=A0

=C2=A0

---------- =D0=9F=D0=B5=D1=80=D0=B5=D1=81=D1=8B=D0= =BB=D0=B0=D0=B5=D0=BC=D0=BE=D0=B5 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0= =BD=D0=B8=D0=B5 ---------
=D0=9E=D1=82: Colin = Perkins <csp@csperkins.org>
=D0=94=D0=B0=D1=82=D0=B0: =D1=81=D0=B1, 6 =D0=B8=D1=8E=D0=BD=D1=8F 2020 =D0= =B3. =D0=B2 16:03
=D0=A2=D0=B5=D0=BC=D0=B0: Fwd: [irsg] [Technical Errata Reported] RFC8391 (= 6024)
=D0=9A=D0=BE=D0=BC=D1=83: <cfrg-chairs@ietf.org>

=C2=A0

Hi CFRG chairs,

=C2=A0

Can you discuss, and review with the RG if necessary= , and let me know =C2=A0if the following errata should be marked as verifie= d.

=C2=A0

Thanks,

Colin

=C2=A0

=C2=A0



Begin forwarded message:

=C2=A0

From: RFC Errat= a System <rfc-editor@rfc-editor.org>

Subject: [irsg]= [Technical Errata Reported] RFC8391 (6024)

Date: 18 March = 2020 at 13:01:52 GMT

=C2=A0

The following errata report has been submitted for R= FC8391,
"XMSS: eXtended Merkle Signature Scheme".

--------------------------------------
You may review the report below and at:
htt= ps://www.rfc-editor.org/errata/eid6024

--------------------------------------
Type: Technical
Reported by: Andreas H=C3=BClsing <ietf@huelsing.net>

Section: 5

Original Text
-------------
This section provides basic parameter sets that are assumed to cover most r= elevant applications.=C2=A0 Parameter sets for two classical security level= s are defined.=C2=A0 Parameters with n =3D 32 provide a classical security = level of 256 bits.=C2=A0 Parameters with n =3D 64 provide a classical security level of 512 bits.=C2=A0 Considering quantum-computer= -aided attacks, these output sizes yield post-quantum security of 128 and 2= 56 bits, respectively.

Corrected Text
--------------
This section provides basic parameter sets that are assumed to cover most r= elevant applications. Parameter sets for two classical security levels are = defined using the cryptographic functions SHA2 and SHAKE.=C2=A0 Parameters = with SHA2 and n =3D 32 provide a classical security level of 256 bits. Parameters with SHA2 and n =3D 64 provide a cl= assical security level of 512 bits.=C2=A0 Considering quantum-computer-aide= d attacks, these parameters yield post-quantum security of 128 and 256 bits= , respectively. Parameters with SHAKE and n =3D 32 provide a classical security level of 128 bits.=C2=A0 Parameters = with SHAKE and n =3D 64 provide a classical security level of 256 bits.=C2= =A0 Considering quantum-computer-aided attacks, these parameters yield post= -quantum security of 86 and 170 bits, respectively.

Notes
-----
Traditionally, a hash function with n-bit outputs is assumed to have n-bit = security against classical preimage and second-preimage attacks, and n/2-bi= t security against classical collision attacks. For adversaries with access= to a quantum computer, these bounds change to n/2 and n/3 bits when only counting queries to the hash function= . This also applies to SHA2 and SHA3. In contrast, SHAKE follows a differen= t reasoning. SHAKE with an internal state of n bits and an output length of= n bits achieves n/2 bit security against classical preimage, second-preimage and collision attacks. For qua= ntum attacks security changes to n/3 bits. The reason is that SHAKE allows = for meet-in-the-middle preimage attacks that reduce to a collision search o= n the internal state. The same applies for SHA3 but for SHA3 a bigger internal state is used.

In consequence, SHAKE-128 cannot provide more security than NIST post-quant= um security level II (Any attack that breaks the relevant security definiti= on must require computational resources comparable to or greater than those= required for collision search on a 256-bit hash function (e.g. SHA256 / SHA3-256)).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party =C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8391 (draft-irtf-cfrg-xmss-hash-based-signatures-12)
--------------------------------------
Title =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0: XMSS: eXtended Merkle Signature Scheme
Publication Date =C2=A0=C2=A0=C2=A0: May 2018
Author(s) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: A. = Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A.. Mohaisen
Category =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= : INFORMATIONAL
Source =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0: Crypto Forum Research Group
Area =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0: N/A
Stream =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0: IRTF
Verifying Party =C2=A0=C2=A0=C2=A0=C2=A0: IRSG

=C2=A0

=C2=A0

--000000000000bb735005a7d4499a-- From nobody Mon Jun 15 01:01:40 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9F8573A0AAB for ; Mon, 15 Jun 2020 01:01:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 7RUNlUSiSwoZ for ; Mon, 15 Jun 2020 01:01:35 -0700 (PDT) Received: from mail-lj1-x232.google.com (mail-lj1-x232.google.com [IPv6:2a00:1450:4864:20::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 228B33A0AAD for ; Mon, 15 Jun 2020 01:01:35 -0700 (PDT) Received: by mail-lj1-x232.google.com with SMTP id q19so18022196lji.2 for ; Mon, 15 Jun 2020 01:01:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=wpFCXG30bqULBBMqSe9FzO6YxiL/9JEIzFM1Z0wgYHI=; b=YYEBI2B7ohDIJt/xdDHI11M+h5imfwc3B8Hw2anXpJE9MmUXOjAwjqL6p5qaQ2x7dw /peqdz4tyPpmymZIft/yZ4lwxC9YfIXmW9KeK5sT67rGUCGrpOrxm5pM1reJt/z1BB04 qzCkASM0RIBVvZCy01fNMXhWugfM2Dt2wFlmuYnesGAEtlmsOV+pTsmU8TpIeYpzRlPu fYg9mjX4QE+QaVu9Bo2IDGH5DeOVhZ1PGVbkDIxol6WakHJkfOZBY5rcqVwsfGOfI+IB cseSvHwgTK+8AEmFwWsBwq6yfwJEe6qf9RmO3P3EDMZ2bFJsHIYycAwlkHOoUKP+7Rpo coog== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=wpFCXG30bqULBBMqSe9FzO6YxiL/9JEIzFM1Z0wgYHI=; b=OCvehXsH+Zv37gO8MUj04NRApwlPjoHodcEfz5GAAXu7r/LONCXMhdQ4AHZOKXxASS Sppj1l7MBY/XhX1OORkY6z20RiyFRGcSRzwa/7NkcBgl/NufYfYIDqjAEGmFC5DELkFN BRmiZq7njF8pVr41KdBCxcOwx4tH+qpxTiiXlDA6mGvZM4+BWc/mMEhPs34iGZLcSmoq aAID/4YgKTgVX1NLD+HldBxwVCeHe1jqlrTrMaz9AhjDBTG3h8ifQG8S6odkzc9g/Kvf 5tXWnNDUzw9yq6rkalrXW5SyKnAKLAiP8RCcPkSWOBIRCGTSCyU2KGOVup0X/42czl4d Fn7Q== X-Gm-Message-State: AOAM531O/fqtprELM3blaejHQzFb/xrZU3ns9Q4tLRR3Snml1MwVYWJU fM6IYZ1gtmOtHLhgzFsbWFZDejq3B4yrSdWEplU= X-Google-Smtp-Source: ABdhPJxyHK12NzR0uGQ/v2YoW9phyyj5XTy85FteAN6jeIOI3U5AcCK/R39Nta1w0o66yXR2uraP1UqkD9vbR4fb8MI= X-Received: by 2002:a2e:974a:: with SMTP id f10mr12872084ljj.283.1592208093085; Mon, 15 Jun 2020 01:01:33 -0700 (PDT) MIME-Version: 1.0 References: <20200318130152.57FD7F4071D@rfc-editor.org> In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Mon, 15 Jun 2020 11:01:22 +0300 Message-ID: To: "Scott Fluhrer (sfluhrer)" Cc: "crypto-panel@irtf.org" , "cfrg-chairs@ietf.org" Content-Type: multipart/alternative; boundary="000000000000cc04a805a81ad55e" Archived-At: Subject: Re: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024) X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 08:01:39 -0000 --000000000000cc04a805a81ad55e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Many thanks, Scott! Therefore, you will be happy if the proposed change is applied, with the revised version of notes, dropping the sentences "The same applies for SHA3 ... " and "(Any attack that breaks...", =E2=80=93 right? Regards, Stanislav On Thu, 11 Jun 2020 at 22:48, Scott Fluhrer (sfluhrer) wrote: > The text looks correct, however I do have a few nits about the notes. On= e > is the reference to SHA3, which on a quick read might be misleading; here > is some alterative text: > > > > The reason is that SHAKE allows for meet-in-the-middle preimage attacks > that reduce to a collision search on the internal state. *These internal > collision attacks do not affect the security of SHA3, because of the larg= er > capacity used.* > > > > Alternatively, just drop the reference to SHA3, which isn=E2=80=99t relev= ent to > XMSS. > > > > The other nit is with the sentence that starts: > > > > Any attack that breaks the relevant security definition must require > computational resources=E2=80=A6 > > > > That sort of statement always has an implicit assumption of the form > =E2=80=9Cunless someone has a cryptographical result against the SHA-3 > permutation=E2=80=9D; while we are used to that sort of assumption, a cau= sal reader > might not be. I don=E2=80=99t see what that sentence brings to the table= ; I=E2=80=99d > suggest dropping it. > > > > *From:* Crypto-panel * On Behalf Of *Stan= islav > V. Smyshlyaev > *Sent:* Thursday, June 11, 2020 1:57 PM > *To:* crypto-panel@irtf.org > *Cc:* cfrg-chairs@ietf.org > *Subject:* [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 > (6024) > > > > Dear Crypto Review Panel members, > > > > There is a need to validate the following errata: > > https://www.rfc-editor.org/errata/eid6024 > > > > > Any volunteers? > > > > Regards, > > CFRG chairs > > > > > > > > ---------- =D0=9F=D0=B5=D1=80=D0=B5=D1=81=D1=8B=D0=BB=D0=B0=D0=B5=D0=BC= =D0=BE=D0=B5 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B5 -------= -- > =D0=9E=D1=82: *Colin Perkins* > =D0=94=D0=B0=D1=82=D0=B0: =D1=81=D0=B1, 6 =D0=B8=D1=8E=D0=BD=D1=8F 2020 = =D0=B3. =D0=B2 16:03 > =D0=A2=D0=B5=D0=BC=D0=B0: Fwd: [irsg] [Technical Errata Reported] RFC8391= (6024) > =D0=9A=D0=BE=D0=BC=D1=83: > > > > Hi CFRG chairs, > > > > Can you discuss, and review with the RG if necessary, and let me know if > the following errata should be marked as verified. > > > > Thanks, > > Colin > > > > > > > > Begin forwarded message: > > > > *From: *RFC Errata System > > *Subject: **[irsg] [Technical Errata Reported] RFC8391 (6024)* > > *Date: *18 March 2020 at 13:01:52 GMT > > *To: *ietf@huelsing.net, dbutin@cdc.informatik.tu-darmstadt.de, > ietf@gazdag.de, ietf@joostrijneveld.nl, mohaisen@ieee.org, irsg@irtf.org > > *Cc: *ietf@huelsing.net, rfc-editor@rfc-editor.org > > > > The following errata report has been submitted for RFC8391, > "XMSS: eXtended Merkle Signature Scheme". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6024 > > -------------------------------------- > Type: Technical > Reported by: Andreas H=C3=BClsing > > Section: 5 > > Original Text > ------------- > This section provides basic parameter sets that are assumed to cover most > relevant applications. Parameter sets for two classical security levels > are defined. Parameters with n =3D 32 provide a classical security level= of > 256 bits. Parameters with n =3D 64 provide a classical security level of= 512 > bits. Considering quantum-computer-aided attacks, these output sizes yie= ld > post-quantum security of 128 and 256 bits, respectively. > > Corrected Text > -------------- > This section provides basic parameter sets that are assumed to cover most > relevant applications. Parameter sets for two classical security levels a= re > defined using the cryptographic functions SHA2 and SHAKE. Parameters wit= h > SHA2 and n =3D 32 provide a classical security level of 256 bits. Paramet= ers > with SHA2 and n =3D 64 provide a classical security level of 512 bits. > Considering quantum-computer-aided attacks, these parameters yield > post-quantum security of 128 and 256 bits, respectively. Parameters with > SHAKE and n =3D 32 provide a classical security level of 128 bits. > Parameters with SHAKE and n =3D 64 provide a classical security level of = 256 > bits. Considering quantum-computer-aided attacks, these parameters yield > post-quantum security of 86 and 170 bits, respectively. > > Notes > ----- > Traditionally, a hash function with n-bit outputs is assumed to have n-bi= t > security against classical preimage and second-preimage attacks, and > n/2-bit security against classical collision attacks. For adversaries wit= h > access to a quantum computer, these bounds change to n/2 and n/3 bits whe= n > only counting queries to the hash function. This also applies to SHA2 and > SHA3. In contrast, SHAKE follows a different reasoning. SHAKE with an > internal state of n bits and an output length of n bits achieves n/2 bit > security against classical preimage, second-preimage and collision attack= s. > For quantum attacks security changes to n/3 bits. The reason is that SHAK= E > allows for meet-in-the-middle preimage attacks that reduce to a collision > search on the internal state. The same applies for SHA3 but for SHA3 a > bigger internal state is used. > > In consequence, SHAKE-128 cannot provide more security than NIST > post-quantum security level II (Any attack that breaks the relevant > security definition must require computational resources comparable to or > greater than those required for collision search on a 256-bit hash functi= on > (e.g. SHA256 / SHA3-256)). > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8391 (draft-irtf-cfrg-xmss-hash-based-signatures-12) > -------------------------------------- > Title : XMSS: eXtended Merkle Signature Scheme > Publication Date : May 2018 > Author(s) : A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A.. > Mohaisen > Category : INFORMATIONAL > Source : Crypto Forum Research Group > Area : N/A > Stream : IRTF > Verifying Party : IRSG > > > > > --000000000000cc04a805a81ad55e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Many thanks, Scott!

Therefore, you will= be happy if the proposed change is applied, with the revised version of no= tes, dropping the sentences "The same applies for SHA3 ... " and = "(Any attack that breaks...", =E2=80=93 right?

Regards,
Stanislav


On Thu, 11 Jun 2020= at 22:48, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> wrote:

The text looks correct, however= I do have a few nits about the notes.=C2=A0 One is the reference to SHA3, = which on a quick read might be misleading; here is some alterative text:=

=C2=A0

The reason is tha= t SHAKE allows for meet-in-the-middle preimage attacks that reduce to a col= lision search on the internal state. These internal collision attacks do not affect the security of SHA3, bec= ause of the larger capacity used.

=C2=A0<= u>

Alternatively, just drop the re= ference to SHA3, which isn=E2=80=99t relevent to XMSS.=

=C2=A0

The other nit is with the sente= nce that starts:

=C2=A0

Any attack that b= reaks the relevant security definition must require computational resources= =E2=80=A6

=C2=A0<= u>

That sort of statement always h= as an implicit assumption of the form =E2=80=9Cunless someone has a cryptog= raphical result against the SHA-3 permutation=E2=80=9D; while we are used t= o that sort of assumption, a causal reader might not be.=C2=A0 I don=E2=80=99t see what that sentence brings to the table; I=E2= =80=99d suggest dropping it.

=C2=A0<= /u>

From: Crypto-panel <crypto-panel-bounces@irtf.org<= /a>> On Behalf Of Stanislav V. Smyshlyaev
Sent: Thursday, June 11, 2020 1:57 PM
To: crypt= o-panel@irtf.org
Cc: cfrg-c= hairs@ietf.org
Subject: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8= 391 (6024)

=C2=A0

Dear Crypto Review Panel members,

=C2=A0

There is a need to validate the following errata:=

=C2=A0

Any volunteers?

=C2=A0

Regards,

CFRG chairs

=C2=A0

=C2=A0

=C2=A0

---------- =D0=9F=D0=B5=D1=80=D0=B5=D1=81=D1=8B=D0= =BB=D0=B0=D0=B5=D0=BC=D0=BE=D0=B5 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0= =BD=D0=B8=D0=B5 ---------
=D0=9E=D1=82: Colin = Perkins <csp@csperkins.org>
=D0=94=D0=B0=D1=82=D0=B0: =D1=81=D0=B1, 6 =D0=B8=D1=8E=D0=BD=D1=8F 2020 =D0= =B3. =D0=B2 16:03
=D0=A2=D0=B5=D0=BC=D0=B0: Fwd: [irsg] [Technical Errata Reported] RFC8391 (= 6024)
=D0=9A=D0=BE=D0=BC=D1=83: <cfrg-chairs@ietf.org>

=C2=A0

Hi CFRG chairs,

=C2=A0

Can you discuss, and review with the RG if necessary= , and let me know =C2=A0if the following errata should be marked as verifie= d.

=C2=A0

Thanks,

Colin

=C2=A0

=C2=A0



Begin forwarded message:

=C2=A0

From: RFC Errat= a System <rfc-editor@rfc-editor.org>

Subject: [irsg]= [Technical Errata Reported] RFC8391 (6024)

Date: 18 March = 2020 at 13:01:52 GMT

=C2=A0

The following errata report has been submitted for R= FC8391,
"XMSS: eXtended Merkle Signature Scheme".

--------------------------------------
You may review the report below and at:
htt= ps://www.rfc-editor.org/errata/eid6024

--------------------------------------
Type: Technical
Reported by: Andreas H=C3=BClsing <ietf@huelsing.net>

Section: 5

Original Text
-------------
This section provides basic parameter sets that are assumed to cover most r= elevant applications.=C2=A0 Parameter sets for two classical security level= s are defined.=C2=A0 Parameters with n =3D 32 provide a classical security = level of 256 bits.=C2=A0 Parameters with n =3D 64 provide a classical security level of 512 bits.=C2=A0 Considering quantum-computer= -aided attacks, these output sizes yield post-quantum security of 128 and 2= 56 bits, respectively.

Corrected Text
--------------
This section provides basic parameter sets that are assumed to cover most r= elevant applications. Parameter sets for two classical security levels are = defined using the cryptographic functions SHA2 and SHAKE.=C2=A0 Parameters = with SHA2 and n =3D 32 provide a classical security level of 256 bits. Parameters with SHA2 and n =3D 64 provide a cl= assical security level of 512 bits.=C2=A0 Considering quantum-computer-aide= d attacks, these parameters yield post-quantum security of 128 and 256 bits= , respectively. Parameters with SHAKE and n =3D 32 provide a classical security level of 128 bits.=C2=A0 Parameters = with SHAKE and n =3D 64 provide a classical security level of 256 bits.=C2= =A0 Considering quantum-computer-aided attacks, these parameters yield post= -quantum security of 86 and 170 bits, respectively.

Notes
-----
Traditionally, a hash function with n-bit outputs is assumed to have n-bit = security against classical preimage and second-preimage attacks, and n/2-bi= t security against classical collision attacks. For adversaries with access= to a quantum computer, these bounds change to n/2 and n/3 bits when only counting queries to the hash function= . This also applies to SHA2 and SHA3. In contrast, SHAKE follows a differen= t reasoning. SHAKE with an internal state of n bits and an output length of= n bits achieves n/2 bit security against classical preimage, second-preimage and collision attacks. For qua= ntum attacks security changes to n/3 bits. The reason is that SHAKE allows = for meet-in-the-middle preimage attacks that reduce to a collision search o= n the internal state. The same applies for SHA3 but for SHA3 a bigger internal state is used.

In consequence, SHAKE-128 cannot provide more security than NIST post-quant= um security level II (Any attack that breaks the relevant security definiti= on must require computational resources comparable to or greater than those= required for collision search on a 256-bit hash function (e.g. SHA256 / SHA3-256)).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party =C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8391 (draft-irtf-cfrg-xmss-hash-based-signatures-12)
--------------------------------------
Title =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0: XMSS: eXtended Merkle Signature Scheme
Publication Date =C2=A0=C2=A0=C2=A0: May 2018
Author(s) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: A. = Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A.. Mohaisen
Category =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= : INFORMATIONAL
Source =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0: Crypto Forum Research Group
Area =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0: N/A
Stream =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0: IRTF
Verifying Party =C2=A0=C2=A0=C2=A0=C2=A0: IRSG

=C2=A0

=C2=A0

--000000000000cc04a805a81ad55e-- From nobody Mon Jun 15 04:58:41 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AF8443A0CE0 for ; Mon, 15 Jun 2020 04:58:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -9.597 X-Spam-Level: X-Spam-Status: No, score=-9.597 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, HTML_MESSAGE=0.001, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com header.b=g4jgqPwI; dkim=pass (1024-bit key) header.d=cisco.onmicrosoft.com header.b=wumNhrjo Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Umt684nDX3bb for ; Mon, 15 Jun 2020 04:58:36 -0700 (PDT) Received: from rcdn-iport-3.cisco.com (rcdn-iport-3.cisco.com [173.37.86.74]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AB5443A0D18 for ; Mon, 15 Jun 2020 04:58:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=35196; q=dns/txt; s=iport; t=1592222316; x=1593431916; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=mUot0nVMksronVOfIIiImUA+bxA91ZYiZ8PRcOQjnm4=; b=g4jgqPwI0p7eNFuuOZ/Lx9UCaHTPJWZgmyVfmJ32Wju7capwHohCQ30o V4jeHB6DFVAyo/LouM0YPVnH2PobeGuYrTI4bc75+NwaEiWjKflS3dkMk k+jqhTFliD1ijHtGOtKZ6v/FvY5Ezut82NvRDLcnNV+NKMoltTZoSb4ar c=; IronPort-PHdr: =?us-ascii?q?9a23=3Aj+rCfRSgSFVv6RFikRDG0HapQdpsv++ubAcI9p?= =?us-ascii?q?oqja5Pea2//pPkeVbS/uhpkESQBNmJ5PdNiu6QuKflCiQM4peE5XYFdpEEFx?= =?us-ascii?q?oIkt4fkAFoBsmZQVb6I/jnY21ffoxCWVZp8mv9PR1TH8DzNFLXq3y2qzUVH0?= =?us-ascii?q?a3OQ98PO+gHInUgoy+3Pyz/JuGZQJOiXK9bLp+IQ/wox/Ws5wdgJBpLeA6zR?= =?us-ascii?q?6arw=3D=3D?= X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0CEAACOYede/4oNJK1mGQEBAQEBAQE?= =?us-ascii?q?BAQEBAQEBAQEBARIBAQEBAQEBAQEBAQGCCoEjLykoB29YLywKhBqDRgONPYl?= =?us-ascii?q?/jlOBQoEQA1ULAQEBDAEBIwoCBAEBgw6BNgIXghgCJDgTAgMBAQsBAQUBAQE?= =?us-ascii?q?CAQYEbYVbDIVyAQEBAQMSEQoTAQE3AQ8CAQYCEQMBAQEhBwMCAgIfERQJCAI?= =?us-ascii?q?EDgUIGoMFgX5NAy4BDpgBkGgCgTmIYXaBMoMBAQEFhSgNC4IOAwaBOAGCY4c?= =?us-ascii?q?bgQiBQxqBQT+BEUOCTT6BBIEWgWk8Hg0Jgl4zgi2PEyeCaYY3gweYFEwKglm?= =?us-ascii?q?UNIUHgnCJGoUajUOddJFQAgQCBAUCDgEBBYFqIoFWcBUagwpQFwINjh4LGIE?= =?us-ascii?q?CAQiCQ4UUhUJ0AjUCBgEHAQEDCXyNVC2BBgGBEAEB?= X-IronPort-AV: E=Sophos;i="5.73,514,1583193600"; d="scan'208,217";a="767477797" Received: from alln-core-5.cisco.com ([173.36.13.138]) by rcdn-iport-3.cisco.com with ESMTP/TLS/DHE-RSA-SEED-SHA; 15 Jun 2020 11:58:35 +0000 Received: from XCH-RCD-003.cisco.com (xch-rcd-003.cisco.com [173.37.102.13]) by alln-core-5.cisco.com (8.15.2/8.15.2) with ESMTPS id 05FBwZ4h029933 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=FAIL); Mon, 15 Jun 2020 11:58:35 GMT Received: from xhs-aln-002.cisco.com (173.37.135.119) by XCH-RCD-003.cisco.com (173.37.102.13) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Jun 2020 06:58:34 -0500 Received: from xhs-aln-003.cisco.com (173.37.135.120) by xhs-aln-002.cisco.com (173.37.135.119) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Mon, 15 Jun 2020 06:58:34 -0500 Received: from NAM11-DM6-obe.outbound.protection.outlook.com (173.37.151.57) by xhs-aln-003.cisco.com (173.37.135.120) with Microsoft SMTP Server (TLS) id 15.0.1497.2 via Frontend Transport; Mon, 15 Jun 2020 06:58:33 -0500 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=W1mz3T2N6UbZzoU3e5MQ+CdaLmMbg2CRplQQSza/b+0NYYoCOSYcln/62We/HtmWf5U7D7b1837/y1O87FIYMjBNV5nnTAwBTHML/DyqS1+F2VS7xpXr1Qc+PmA114EsVBPdt+IgZucXA0G9DzmgdaYAOR2DdmMxzcb7DtOuu9Nppg5ov3UB/dhejVK/in4/7fwngum20g3YelB2EhNzJ7NWuK+FTpieYi4bcYT2GLBWBdpK02H7XlyKElHuBSvGnlxI5kRXva7UNueWsqZ3HQ2/plGQ0tzGp17mZdEfl4qepYq/8aW4bhoBGcOk70AXPM25MRXpsrtSYmIcSk72JA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mUot0nVMksronVOfIIiImUA+bxA91ZYiZ8PRcOQjnm4=; b=ZRsPQyLkULYVwDNHDd/+nUUYFm9qkysLqzK0CcmyKNJ798tTrOCPCCs1kmyEYaGFmrOg2C4TCfVlsNMBGuLkDkGrGNHPhH6Vy4PVZkE4G15cGmmuh7M1oJgTSkDxAqHUl4fMrAzuftLGLxMGwbbQS6AVYlXD8HjLQ5rXqAt6gL8fTfEdnzbcFwNLwYvX4IUCMQzPrWjRNMuCZ2aNhtKGQvUMlEkY0zmpAE8eYwnAY8UYXZiWIuwJ7ONCphdAZFDm1UMd02w4/NFfKm1En8XvQl2hZzUbXxkwP4QB0r66qVBzRokFchmPYOVzy67R+sH8wsRDCLn3C5DFj79g3kftSg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=cisco.com; dmarc=pass action=none header.from=cisco.com; dkim=pass header.d=cisco.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cisco.onmicrosoft.com; s=selector2-cisco-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=mUot0nVMksronVOfIIiImUA+bxA91ZYiZ8PRcOQjnm4=; b=wumNhrjoEm1dblzB/4cimNrbhdcI64zsCyuTQk6APQOE+D+YOZiJ3PiuhAntT2z4TD2rK8Ovh4YwfUfVF8M/5YNknfVxgnVaEuI0iV5s6QEpAIZM94YfkXGhZXTlSu4BfGIeuFVO/l2JkHObl1CTQ0zAICd0eVR4PFhRrojZlSo= Received: from BN7PR11MB2641.namprd11.prod.outlook.com (2603:10b6:406:b1::25) by BN8PR11MB3652.namprd11.prod.outlook.com (2603:10b6:408:87::19) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3088.21; Mon, 15 Jun 2020 11:58:33 +0000 Received: from BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5]) by BN7PR11MB2641.namprd11.prod.outlook.com ([fe80::35bd:ecae:1e28:58f5%5]) with mapi id 15.20.3088.029; Mon, 15 Jun 2020 11:58:32 +0000 From: "Scott Fluhrer (sfluhrer)" To: "Stanislav V. Smyshlyaev" CC: "crypto-panel@irtf.org" , "cfrg-chairs@ietf.org" Thread-Topic: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024) Thread-Index: AQHWQBnJJGAZ+rJ0+0mRx3PaVn0UH6jTyyvggAWK8gCAAEFzQA== Date: Mon, 15 Jun 2020 11:58:32 +0000 Message-ID: References: <20200318130152.57FD7F4071D@rfc-editor.org> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: gmail.com; dkim=none (message not signed) header.d=none;gmail.com; dmarc=none action=none header.from=cisco.com; x-originating-ip: [173.38.117.76] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: c3b628e1-985f-4c32-0c02-08d811236d68 x-ms-traffictypediagnostic: BN8PR11MB3652: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 04359FAD81 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: +54SWCRslswCAhAo8r1jWMwbaSlHr3ge78bgQINyzA8pxfzziTW5No6zXtw9sz0WAKfw9mTo/wMQtSaUpkVoE5Sq6HNqWMSUfzuwV4PtzhrDremCZHbxTUXNMBkjeR9I2DQB3uU8YleTcPj4Vvoem5pdphXbkWPb8QQWqrMUw1CCKKmotpZ5ET/U7huzRCc6YZYJAxTDOqdEc3BSKUt1sL8QI8bOhJ+Dv+tTiedJrwXPN+q10DckCV7d97TOJMgH8lhtg5OLaey+qtve8/xX2y1dCqLPRYqYSP3MW8NNMmvjStuvopIHJJF1ZYWmRfkLUAwVC5eIkC/FXlYKA8d35j5jUm6tcOAprTAO+6kJWu25giCfKzylsPE7c6EKpiGJd0TDcn613yzFNmgVnG/NKQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:BN7PR11MB2641.namprd11.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(136003)(366004)(39860400002)(376002)(396003)(346002)(7696005)(53546011)(6506007)(33656002)(6916009)(316002)(54906003)(8936002)(8676002)(66574014)(83380400001)(66446008)(4326008)(64756008)(66556008)(66476007)(66946007)(478600001)(9686003)(76116006)(166002)(5660300002)(55016002)(52536014)(186003)(86362001)(26005)(966005)(71200400001)(2906002); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: N81MGRa+GKk0hyyhGv65oS3snNAdnKJee9BO6WQsxRG1goWnLbzDMT3Q5PT/DdtG1bFKCmqv72V3gm80Jbn5/+Y+zGD8njWm+KccTXz36Z7NnZslelbDn9Ye4Qr8/c90OBFu2W2Rca/yC1UwcMLn7QUodjvRqfyxImX5PlDZpU+Mcie/XAc7CTg0r4xjUQlmiTcomyVUcYcatsDMiEUCsRtVwPE6bVvYtQ9fLJjvf2kWTqL2rdwVceYCB4UEsTHVueznTIfIunGNl+I4M4Wj17L4gdm4vA9syHTxtjH6ltHSntQ07OqtM8WyFacgyl5k5qZH5fMN+KTh4yH3rBLaz+JDc8dxHfMd1uYAWVm6XQbiUwtM7ZrpUV+hLY3G3xKU1Nfpks7G4QSFAktwv5antQCTkDPjgMCvW8RRckOI9OiJSKlBYs0jbnIQHLQjp9Ff04pORgEB2v5iWXwC59g5n3bkb/0qH0pgPvpgM1FghhA= x-ms-exchange-transport-forked: True Content-Type: multipart/alternative; boundary="_000_BN7PR11MB2641D883BEAB8B248ABCF910C19C0BN7PR11MB2641namp_" MIME-Version: 1.0 X-MS-Exchange-CrossTenant-Network-Message-Id: c3b628e1-985f-4c32-0c02-08d811236d68 X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Jun 2020 11:58:32.8448 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5ae1af62-9505-4097-a69a-c1553ef7840e X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: WJBBTMF7wKObt1VsSsLm23l2wNX2BEiqRjS6zGDnaD+y5nz5ydOkPNYtqsbV2Zp+xLoaJU/wmgYHre9vrTwHJA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN8PR11MB3652 X-OriginatorOrg: cisco.com X-Outbound-SMTP-Client: 173.37.102.13, xch-rcd-003.cisco.com X-Outbound-Node: alln-core-5.cisco.com Archived-At: Subject: Re: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024) X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 11:58:41 -0000 --_000_BN7PR11MB2641D883BEAB8B248ABCF910C19C0BN7PR11MB2641namp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 QWN0dWFsbHksIEnigJlkIGJlIGhhcHB5IGVpdGhlciB3YXkgKGFzIHRoZXNlIGFyZSDigJhuaXRz 4oCZLCBub3QgcmVhbCBwcm9ibGVtcykuICBUaG9zZSBjaGFuZ2VzIHdvdWxkIGJlIG15IHN1Z2dl c3Rpb24uDQoNCkZyb206IFN0YW5pc2xhdiBWLiBTbXlzaGx5YWV2IDxzbXlzaHN2QGdtYWlsLmNv bT4NClNlbnQ6IE1vbmRheSwgSnVuZSAxNSwgMjAyMCA0OjAxIEFNDQpUbzogU2NvdHQgRmx1aHJl ciAoc2ZsdWhyZXIpIDxzZmx1aHJlckBjaXNjby5jb20+DQpDYzogY3J5cHRvLXBhbmVsQGlydGYu b3JnOyBjZnJnLWNoYWlyc0BpZXRmLm9yZw0KU3ViamVjdDogUmU6IFtDcnlwdG8tcGFuZWxdIEZ3 ZDogW2lyc2ddIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM4MzkxICg2MDI0KQ0KDQpN YW55IHRoYW5rcywgU2NvdHQhDQoNClRoZXJlZm9yZSwgeW91IHdpbGwgYmUgaGFwcHkgaWYgdGhl IHByb3Bvc2VkIGNoYW5nZSBpcyBhcHBsaWVkLCB3aXRoIHRoZSByZXZpc2VkIHZlcnNpb24gb2Yg bm90ZXMsIGRyb3BwaW5nIHRoZSBzZW50ZW5jZXMgIlRoZSBzYW1lIGFwcGxpZXMgZm9yIFNIQTMg Li4uICIgYW5kICIoQW55IGF0dGFjayB0aGF0IGJyZWFrcy4uLiIsIOKAkyByaWdodD8NCg0KUmVn YXJkcywNClN0YW5pc2xhdg0KDQoNCk9uIFRodSwgMTEgSnVuIDIwMjAgYXQgMjI6NDgsIFNjb3R0 IEZsdWhyZXIgKHNmbHVocmVyKSA8c2ZsdWhyZXJAY2lzY28uY29tPG1haWx0bzpzZmx1aHJlckBj aXNjby5jb20+PiB3cm90ZToNClRoZSB0ZXh0IGxvb2tzIGNvcnJlY3QsIGhvd2V2ZXIgSSBkbyBo YXZlIGEgZmV3IG5pdHMgYWJvdXQgdGhlIG5vdGVzLiAgT25lIGlzIHRoZSByZWZlcmVuY2UgdG8g U0hBMywgd2hpY2ggb24gYSBxdWljayByZWFkIG1pZ2h0IGJlIG1pc2xlYWRpbmc7IGhlcmUgaXMg c29tZSBhbHRlcmF0aXZlIHRleHQ6DQoNClRoZSByZWFzb24gaXMgdGhhdCBTSEFLRSBhbGxvd3Mg Zm9yIG1lZXQtaW4tdGhlLW1pZGRsZSBwcmVpbWFnZSBhdHRhY2tzIHRoYXQgcmVkdWNlIHRvIGEg Y29sbGlzaW9uIHNlYXJjaCBvbiB0aGUgaW50ZXJuYWwgc3RhdGUuIFRoZXNlIGludGVybmFsIGNv bGxpc2lvbiBhdHRhY2tzIGRvIG5vdCBhZmZlY3QgdGhlIHNlY3VyaXR5IG9mIFNIQTMsIGJlY2F1 c2Ugb2YgdGhlIGxhcmdlciBjYXBhY2l0eSB1c2VkLg0KDQpBbHRlcm5hdGl2ZWx5LCBqdXN0IGRy b3AgdGhlIHJlZmVyZW5jZSB0byBTSEEzLCB3aGljaCBpc27igJl0IHJlbGV2ZW50IHRvIFhNU1Mu DQoNClRoZSBvdGhlciBuaXQgaXMgd2l0aCB0aGUgc2VudGVuY2UgdGhhdCBzdGFydHM6DQoNCkFu eSBhdHRhY2sgdGhhdCBicmVha3MgdGhlIHJlbGV2YW50IHNlY3VyaXR5IGRlZmluaXRpb24gbXVz dCByZXF1aXJlIGNvbXB1dGF0aW9uYWwgcmVzb3VyY2Vz4oCmDQoNClRoYXQgc29ydCBvZiBzdGF0 ZW1lbnQgYWx3YXlzIGhhcyBhbiBpbXBsaWNpdCBhc3N1bXB0aW9uIG9mIHRoZSBmb3JtIOKAnHVu bGVzcyBzb21lb25lIGhhcyBhIGNyeXB0b2dyYXBoaWNhbCByZXN1bHQgYWdhaW5zdCB0aGUgU0hB LTMgcGVybXV0YXRpb27igJ07IHdoaWxlIHdlIGFyZSB1c2VkIHRvIHRoYXQgc29ydCBvZiBhc3N1 bXB0aW9uLCBhIGNhdXNhbCByZWFkZXIgbWlnaHQgbm90IGJlLiAgSSBkb27igJl0IHNlZSB3aGF0 IHRoYXQgc2VudGVuY2UgYnJpbmdzIHRvIHRoZSB0YWJsZTsgSeKAmWQgc3VnZ2VzdCBkcm9wcGlu ZyBpdC4NCg0KRnJvbTogQ3J5cHRvLXBhbmVsIDxjcnlwdG8tcGFuZWwtYm91bmNlc0BpcnRmLm9y ZzxtYWlsdG86Y3J5cHRvLXBhbmVsLWJvdW5jZXNAaXJ0Zi5vcmc+PiBPbiBCZWhhbGYgT2YgU3Rh bmlzbGF2IFYuIFNteXNobHlhZXYNClNlbnQ6IFRodXJzZGF5LCBKdW5lIDExLCAyMDIwIDE6NTcg UE0NClRvOiBjcnlwdG8tcGFuZWxAaXJ0Zi5vcmc8bWFpbHRvOmNyeXB0by1wYW5lbEBpcnRmLm9y Zz4NCkNjOiBjZnJnLWNoYWlyc0BpZXRmLm9yZzxtYWlsdG86Y2ZyZy1jaGFpcnNAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBbQ3J5cHRvLXBhbmVsXSBGd2Q6IFtpcnNnXSBbVGVjaG5pY2FsIEVycmF0YSBS ZXBvcnRlZF0gUkZDODM5MSAoNjAyNCkNCg0KRGVhciBDcnlwdG8gUmV2aWV3IFBhbmVsIG1lbWJl cnMsDQoNClRoZXJlIGlzIGEgbmVlZCB0byB2YWxpZGF0ZSB0aGUgZm9sbG93aW5nIGVycmF0YToN Cmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YS9laWQ2MDI0PGh0dHBzOi8vd3d3LnJm Yy1lZGl0b3IuLm9yZy9lcnJhdGEvZWlkNjAyND4NCg0KQW55IHZvbHVudGVlcnM/DQoNClJlZ2Fy ZHMsDQpDRlJHIGNoYWlycw0KDQoNCg0KLS0tLS0tLS0tLSDQn9C10YDQtdGB0YvQu9Cw0LXQvNC+ 0LUg0YHQvtC+0LHRidC10L3QuNC1IC0tLS0tLS0tLQ0K0J7RgjogQ29saW4gUGVya2lucyA8Y3Nw QGNzcGVya2lucy5vcmc8bWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnPj4NCtCU0LDRgtCwOiDRgdCx LCA2INC40Y7QvdGPIDIwMjAg0LMuINCyIDE2OjAzDQrQotC10LzQsDogRndkOiBbaXJzZ10gW1Rl Y2huaWNhbCBFcnJhdGEgUmVwb3J0ZWRdIFJGQzgzOTEgKDYwMjQpDQrQmtC+0LzRgzogPGNmcmct Y2hhaXJzQGlldGYub3JnPG1haWx0bzpjZnJnLWNoYWlyc0BpZXRmLm9yZz4+DQoNCkhpIENGUkcg Y2hhaXJzLA0KDQpDYW4geW91IGRpc2N1c3MsIGFuZCByZXZpZXcgd2l0aCB0aGUgUkcgaWYgbmVj ZXNzYXJ5LCBhbmQgbGV0IG1lIGtub3cgIGlmIHRoZSBmb2xsb3dpbmcgZXJyYXRhIHNob3VsZCBi ZSBtYXJrZWQgYXMgdmVyaWZpZWQuDQoNClRoYW5rcywNCkNvbGluDQoNCg0KDQpCZWdpbiBmb3J3 YXJkZWQgbWVzc2FnZToNCg0KRnJvbTogUkZDIEVycmF0YSBTeXN0ZW0gPHJmYy1lZGl0b3JAcmZj LWVkaXRvci5vcmc8bWFpbHRvOnJmYy1lZGl0b3JAcmZjLWVkaXRvci5vcmc+Pg0KU3ViamVjdDog W2lyc2ddIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM4MzkxICg2MDI0KQ0KRGF0ZTog MTggTWFyY2ggMjAyMCBhdCAxMzowMTo1MiBHTVQNClRvOiBpZXRmQGh1ZWxzaW5nLm5ldDxtYWls dG86aWV0ZkBodWVsc2luZy5uZXQ+LCBkYnV0aW5AY2RjLmluZm9ybWF0aWsudHUtZGFybXN0YWR0 LmRlPG1haWx0bzpkYnV0aW5AY2RjLmluZm9ybWF0aWsudHUtZGFybXN0YWR0LmRlPiwgaWV0ZkBn YXpkYWcuZGU8bWFpbHRvOmlldGZAZ2F6ZGFnLmRlPiwgaWV0ZkBqb29zdHJpam5ldmVsZC5ubDxt YWlsdG86aWV0ZkBqb29zdHJpam5ldmVsZC5ubD4sIG1vaGFpc2VuQGllZWUub3JnPG1haWx0bzpt b2hhaXNlbkBpZWVlLm9yZz4sIGlyc2dAaXJ0Zi5vcmc8bWFpbHRvOmlyc2dAaXJ0Zi5vcmc+DQpD YzogaWV0ZkBodWVsc2luZy5uZXQ8bWFpbHRvOmlldGZAaHVlbHNpbmcubmV0PiwgcmZjLWVkaXRv ckByZmMtZWRpdG9yLm9yZzxtYWlsdG86cmZjLWVkaXRvckByZmMtZWRpdG9yLm9yZz4NCg0KVGhl IGZvbGxvd2luZyBlcnJhdGEgcmVwb3J0IGhhcyBiZWVuIHN1Ym1pdHRlZCBmb3IgUkZDODM5MSwN CiJYTVNTOiBlWHRlbmRlZCBNZXJrbGUgU2lnbmF0dXJlIFNjaGVtZSIuDQoNCi0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpZb3UgbWF5IHJldmlldyB0aGUgcmVwb3J0IGJl bG93IGFuZCBhdDoNCmh0dHBzOi8vd3d3LnJmYy1lZGl0b3Iub3JnL2VycmF0YS9laWQ2MDI0DQoN Ci0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpUeXBlOiBUZWNobmljYWwN ClJlcG9ydGVkIGJ5OiBBbmRyZWFzIEjDvGxzaW5nIDxpZXRmQGh1ZWxzaW5nLm5ldDxtYWlsdG86 aWV0ZkBodWVsc2luZy5uZXQ+Pg0KDQpTZWN0aW9uOiA1DQoNCk9yaWdpbmFsIFRleHQNCi0tLS0t LS0tLS0tLS0NClRoaXMgc2VjdGlvbiBwcm92aWRlcyBiYXNpYyBwYXJhbWV0ZXIgc2V0cyB0aGF0 IGFyZSBhc3N1bWVkIHRvIGNvdmVyIG1vc3QgcmVsZXZhbnQgYXBwbGljYXRpb25zLiAgUGFyYW1l dGVyIHNldHMgZm9yIHR3byBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2ZWxzIGFyZSBkZWZpbmVkLiAg UGFyYW1ldGVycyB3aXRoIG4gPSAzMiBwcm92aWRlIGEgY2xhc3NpY2FsIHNlY3VyaXR5IGxldmVs IG9mIDI1NiBiaXRzLiAgUGFyYW1ldGVycyB3aXRoIG4gPSA2NCBwcm92aWRlIGEgY2xhc3NpY2Fs IHNlY3VyaXR5IGxldmVsIG9mIDUxMiBiaXRzLiAgQ29uc2lkZXJpbmcgcXVhbnR1bS1jb21wdXRl ci1haWRlZCBhdHRhY2tzLCB0aGVzZSBvdXRwdXQgc2l6ZXMgeWllbGQgcG9zdC1xdWFudHVtIHNl Y3VyaXR5IG9mIDEyOCBhbmQgMjU2IGJpdHMsIHJlc3BlY3RpdmVseS4NCg0KQ29ycmVjdGVkIFRl eHQNCi0tLS0tLS0tLS0tLS0tDQpUaGlzIHNlY3Rpb24gcHJvdmlkZXMgYmFzaWMgcGFyYW1ldGVy IHNldHMgdGhhdCBhcmUgYXNzdW1lZCB0byBjb3ZlciBtb3N0IHJlbGV2YW50IGFwcGxpY2F0aW9u cy4gUGFyYW1ldGVyIHNldHMgZm9yIHR3byBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2ZWxzIGFyZSBk ZWZpbmVkIHVzaW5nIHRoZSBjcnlwdG9ncmFwaGljIGZ1bmN0aW9ucyBTSEEyIGFuZCBTSEFLRS4g IFBhcmFtZXRlcnMgd2l0aCBTSEEyIGFuZCBuID0gMzIgcHJvdmlkZSBhIGNsYXNzaWNhbCBzZWN1 cml0eSBsZXZlbCBvZiAyNTYgYml0cy4gUGFyYW1ldGVycyB3aXRoIFNIQTIgYW5kIG4gPSA2NCBw cm92aWRlIGEgY2xhc3NpY2FsIHNlY3VyaXR5IGxldmVsIG9mIDUxMiBiaXRzLiAgQ29uc2lkZXJp bmcgcXVhbnR1bS1jb21wdXRlci1haWRlZCBhdHRhY2tzLCB0aGVzZSBwYXJhbWV0ZXJzIHlpZWxk IHBvc3QtcXVhbnR1bSBzZWN1cml0eSBvZiAxMjggYW5kIDI1NiBiaXRzLCByZXNwZWN0aXZlbHku IFBhcmFtZXRlcnMgd2l0aCBTSEFLRSBhbmQgbiA9IDMyIHByb3ZpZGUgYSBjbGFzc2ljYWwgc2Vj dXJpdHkgbGV2ZWwgb2YgMTI4IGJpdHMuICBQYXJhbWV0ZXJzIHdpdGggU0hBS0UgYW5kIG4gPSA2 NCBwcm92aWRlIGEgY2xhc3NpY2FsIHNlY3VyaXR5IGxldmVsIG9mIDI1NiBiaXRzLiAgQ29uc2lk ZXJpbmcgcXVhbnR1bS1jb21wdXRlci1haWRlZCBhdHRhY2tzLCB0aGVzZSBwYXJhbWV0ZXJzIHlp ZWxkIHBvc3QtcXVhbnR1bSBzZWN1cml0eSBvZiA4NiBhbmQgMTcwIGJpdHMsIHJlc3BlY3RpdmVs eS4NCg0KTm90ZXMNCi0tLS0tDQpUcmFkaXRpb25hbGx5LCBhIGhhc2ggZnVuY3Rpb24gd2l0aCBu LWJpdCBvdXRwdXRzIGlzIGFzc3VtZWQgdG8gaGF2ZSBuLWJpdCBzZWN1cml0eSBhZ2FpbnN0IGNs YXNzaWNhbCBwcmVpbWFnZSBhbmQgc2Vjb25kLXByZWltYWdlIGF0dGFja3MsIGFuZCBuLzItYml0 IHNlY3VyaXR5IGFnYWluc3QgY2xhc3NpY2FsIGNvbGxpc2lvbiBhdHRhY2tzLiBGb3IgYWR2ZXJz YXJpZXMgd2l0aCBhY2Nlc3MgdG8gYSBxdWFudHVtIGNvbXB1dGVyLCB0aGVzZSBib3VuZHMgY2hh bmdlIHRvIG4vMiBhbmQgbi8zIGJpdHMgd2hlbiBvbmx5IGNvdW50aW5nIHF1ZXJpZXMgdG8gdGhl IGhhc2ggZnVuY3Rpb24uIFRoaXMgYWxzbyBhcHBsaWVzIHRvIFNIQTIgYW5kIFNIQTMuIEluIGNv bnRyYXN0LCBTSEFLRSBmb2xsb3dzIGEgZGlmZmVyZW50IHJlYXNvbmluZy4gU0hBS0Ugd2l0aCBh biBpbnRlcm5hbCBzdGF0ZSBvZiBuIGJpdHMgYW5kIGFuIG91dHB1dCBsZW5ndGggb2YgbiBiaXRz IGFjaGlldmVzIG4vMiBiaXQgc2VjdXJpdHkgYWdhaW5zdCBjbGFzc2ljYWwgcHJlaW1hZ2UsIHNl Y29uZC1wcmVpbWFnZSBhbmQgY29sbGlzaW9uIGF0dGFja3MuIEZvciBxdWFudHVtIGF0dGFja3Mg c2VjdXJpdHkgY2hhbmdlcyB0byBuLzMgYml0cy4gVGhlIHJlYXNvbiBpcyB0aGF0IFNIQUtFIGFs bG93cyBmb3IgbWVldC1pbi10aGUtbWlkZGxlIHByZWltYWdlIGF0dGFja3MgdGhhdCByZWR1Y2Ug dG8gYSBjb2xsaXNpb24gc2VhcmNoIG9uIHRoZSBpbnRlcm5hbCBzdGF0ZS4gVGhlIHNhbWUgYXBw bGllcyBmb3IgU0hBMyBidXQgZm9yIFNIQTMgYSBiaWdnZXIgaW50ZXJuYWwgc3RhdGUgaXMgdXNl ZC4NCg0KSW4gY29uc2VxdWVuY2UsIFNIQUtFLTEyOCBjYW5ub3QgcHJvdmlkZSBtb3JlIHNlY3Vy aXR5IHRoYW4gTklTVCBwb3N0LXF1YW50dW0gc2VjdXJpdHkgbGV2ZWwgSUkgKEFueSBhdHRhY2sg dGhhdCBicmVha3MgdGhlIHJlbGV2YW50IHNlY3VyaXR5IGRlZmluaXRpb24gbXVzdCByZXF1aXJl IGNvbXB1dGF0aW9uYWwgcmVzb3VyY2VzIGNvbXBhcmFibGUgdG8gb3IgZ3JlYXRlciB0aGFuIHRo b3NlIHJlcXVpcmVkIGZvciBjb2xsaXNpb24gc2VhcmNoIG9uIGEgMjU2LWJpdCBoYXNoIGZ1bmN0 aW9uIChlLmcuIFNIQTI1NiAvIFNIQTMtMjU2KSkuDQoNCkluc3RydWN0aW9uczoNCi0tLS0tLS0t LS0tLS0NClRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9zdGVkIGFzICJSZXBvcnRlZCIuIElm IG5lY2Vzc2FyeSwgcGxlYXNlDQp1c2UgIlJlcGx5IEFsbCIgdG8gZGlzY3VzcyB3aGV0aGVyIGl0 IHNob3VsZCBiZSB2ZXJpZmllZCBvcg0KcmVqZWN0ZWQuIFdoZW4gYSBkZWNpc2lvbiBpcyByZWFj aGVkLCB0aGUgdmVyaWZ5aW5nIHBhcnR5DQpjYW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3RhdHVz IGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4NCg0KLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NClJGQzgzOTEgKGRyYWZ0LWlydGYtY2ZyZy14bXNzLWhhc2gt YmFzZWQtc2lnbmF0dXJlcy0xMikNCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tDQpUaXRsZSAgICAgICAgICAgICAgIDogWE1TUzogZVh0ZW5kZWQgTWVya2xlIFNpZ25hdHVy ZSBTY2hlbWUNClB1YmxpY2F0aW9uIERhdGUgICAgOiBNYXkgMjAxOA0KQXV0aG9yKHMpICAgICAg ICAgICA6IEEuIEh1ZWxzaW5nLCBELiBCdXRpbiwgUy4gR2F6ZGFnLCBKLiBSaWpuZXZlbGQsIEEu LiBNb2hhaXNlbg0KQ2F0ZWdvcnkgICAgICAgICAgICA6IElORk9STUFUSU9OQUwNClNvdXJjZSAg ICAgICAgICAgICAgOiBDcnlwdG8gRm9ydW0gUmVzZWFyY2ggR3JvdXANCkFyZWEgICAgICAgICAg ICAgICAgOiBOL0ENClN0cmVhbSAgICAgICAgICAgICAgOiBJUlRGDQpWZXJpZnlpbmcgUGFydHkg ICAgIDogSVJTRw0KDQoNCg== --_000_BN7PR11MB2641D883BEAB8B248ABCF910C19C0BN7PR11MB2641namp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KQGZvbnQtZmFjZQ0KCXtmb250LWZhbWlseToiSGVsdmV0aWNhIE5ldWUiO30NCi8qIFN0 eWxlIERlZmluaXRpb25zICovDQpwLk1zb05vcm1hbCwgbGkuTXNvTm9ybWFsLCBkaXYuTXNvTm9y bWFsDQoJe21hcmdpbjowaW47DQoJbWFyZ2luLWJvdHRvbTouMDAwMXB0Ow0KCWZvbnQtc2l6ZTox MS4wcHQ7DQoJZm9udC1mYW1pbHk6IkNhbGlicmkiLHNhbnMtc2VyaWY7fQ0KYTpsaW5rLCBzcGFu Lk1zb0h5cGVybGluaw0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6Ymx1ZTsNCgl0 ZXh0LWRlY29yYXRpb246dW5kZXJsaW5lO30NCmE6dmlzaXRlZCwgc3Bhbi5Nc29IeXBlcmxpbmtG b2xsb3dlZA0KCXttc28tc3R5bGUtcHJpb3JpdHk6OTk7DQoJY29sb3I6cHVycGxlOw0KCXRleHQt ZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0KcC5tc29ub3JtYWwwLCBsaS5tc29ub3JtYWwwLCBkaXYu bXNvbm9ybWFsMA0KCXttc28tc3R5bGUtbmFtZTptc29ub3JtYWw7DQoJbXNvLW1hcmdpbi10b3At YWx0OmF1dG87DQoJbWFyZ2luLXJpZ2h0OjBpbjsNCgltc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0 bzsNCgltYXJnaW4tbGVmdDowaW47DQoJZm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToi Q2FsaWJyaSIsc2Fucy1zZXJpZjt9DQpzcGFuLkVtYWlsU3R5bGUxOQ0KCXttc28tc3R5bGUtdHlw ZTpwZXJzb25hbC1yZXBseTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjsNCglj b2xvcjp3aW5kb3d0ZXh0O30NCi5Nc29DaHBEZWZhdWx0DQoJe21zby1zdHlsZS10eXBlOmV4cG9y dC1vbmx5Ow0KCWZvbnQtZmFtaWx5OiJDYWxpYnJpIixzYW5zLXNlcmlmO30NCkBwYWdlIFdvcmRT ZWN0aW9uMQ0KCXtzaXplOjguNWluIDExLjBpbjsNCgltYXJnaW46MS4waW4gMS4waW4gMS4waW4g MS4waW47fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJFTi1VUyIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2 IGNsYXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+QWN0dWFsbHksIEni gJlkIGJlIGhhcHB5IGVpdGhlciB3YXkgKGFzIHRoZXNlIGFyZSDigJhuaXRz4oCZLCBub3QgcmVh bCBwcm9ibGVtcykuJm5ic3A7IFRob3NlIGNoYW5nZXMgd291bGQgYmUgbXkgc3VnZ2VzdGlvbi48 c3BhbiBsYW5nPSJFTi1HQiI+PG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3Jk ZXItbGVmdDpzb2xpZCBibHVlIDEuNXB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNC4wcHQiPg0KPGRp dj4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci10b3A6c29saWQgI0UxRTFFMSAxLjBw dDtwYWRkaW5nOjMuMHB0IDBpbiAwaW4gMGluIj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxiPkZy b206PC9iPiBTdGFuaXNsYXYgVi4gU215c2hseWFldiAmbHQ7c215c2hzdkBnbWFpbC5jb20mZ3Q7 IDxicj4NCjxiPlNlbnQ6PC9iPiBNb25kYXksIEp1bmUgMTUsIDIwMjAgNDowMSBBTTxicj4NCjxi PlRvOjwvYj4gU2NvdHQgRmx1aHJlciAoc2ZsdWhyZXIpICZsdDtzZmx1aHJlckBjaXNjby5jb20m Z3Q7PGJyPg0KPGI+Q2M6PC9iPiBjcnlwdG8tcGFuZWxAaXJ0Zi5vcmc7IGNmcmctY2hhaXJzQGll dGYub3JnPGJyPg0KPGI+U3ViamVjdDo8L2I+IFJlOiBbQ3J5cHRvLXBhbmVsXSBGd2Q6IFtpcnNn XSBbVGVjaG5pY2FsIEVycmF0YSBSZXBvcnRlZF0gUkZDODM5MSAoNjAyNCk8bzpwPjwvbzpwPjwv cD4NCjwvZGl2Pg0KPC9kaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5NYW55IHRoYW5rcywgU2NvdHQhPG86 cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5UaGVyZWZvcmUsIHlv dSB3aWxsIGJlIGhhcHB5IGlmIHRoZSBwcm9wb3NlZCBjaGFuZ2UgaXMgYXBwbGllZCwgd2l0aCB0 aGUgcmV2aXNlZCB2ZXJzaW9uIG9mIG5vdGVzLCBkcm9wcGluZyB0aGUgc2VudGVuY2VzICZxdW90 O1RoZSBzYW1lIGFwcGxpZXMgZm9yIFNIQTMgLi4uICZxdW90OyBhbmQgJnF1b3Q7KEFueSBhdHRh Y2sgdGhhdCBicmVha3MuLi4mcXVvdDssIOKAkyByaWdodD88bzpwPjwvbzpwPjwvcD4NCjwvZGl2 Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+UmVnYXJkcyw8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPlN0YW5pc2xhdjxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8 L286cD48L3A+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk9uIFRodSwgMTEg SnVuIDIwMjAgYXQgMjI6NDgsIFNjb3R0IEZsdWhyZXIgKHNmbHVocmVyKSAmbHQ7PGEgaHJlZj0i bWFpbHRvOnNmbHVocmVyQGNpc2NvLmNvbSI+c2ZsdWhyZXJAY2lzY28uY29tPC9hPiZndDsgd3Jv dGU6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxibG9ja3F1b3RlIHN0eWxlPSJib3JkZXI6bm9u ZTtib3JkZXItbGVmdDpzb2xpZCAjQ0NDQ0NDIDEuMHB0O3BhZGRpbmc6MGluIDBpbiAwaW4gNi4w cHQ7bWFyZ2luLWxlZnQ6NC44cHQ7bWFyZ2luLXJpZ2h0OjBpbiI+DQo8ZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFy Z2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPlRoZSB0ZXh0IGxvb2tzIGNv cnJlY3QsIGhvd2V2ZXIgSSBkbyBoYXZlIGEgZmV3IG5pdHMgYWJvdXQgdGhlIG5vdGVzLiZuYnNw OyBPbmUgaXMgdGhlIHJlZmVyZW5jZSB0byBTSEEzLCB3aGljaCBvbiBhIHF1aWNrIHJlYWQgbWln aHQgYmUgbWlzbGVhZGluZzsgaGVyZSBpcyBzb21lIGFsdGVyYXRpdmUNCiB0ZXh0Ojwvc3Bhbj48 bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0Ii PiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNw YW4gc3R5bGU9ImZvbnQtc2l6ZToxMC41cHQ7Zm9udC1mYW1pbHk6JnF1b3Q7QXJpYWwmcXVvdDss c2Fucy1zZXJpZjtjb2xvcjojMkM0MzUzO2JhY2tncm91bmQ6I0UzRTNFMyI+VGhlIHJlYXNvbiBp cyB0aGF0IFNIQUtFIGFsbG93cyBmb3IgbWVldC1pbi10aGUtbWlkZGxlIHByZWltYWdlIGF0dGFj a3MgdGhhdCByZWR1Y2UNCiB0byBhIGNvbGxpc2lvbiBzZWFyY2ggb24gdGhlIGludGVybmFsIHN0 YXRlLiA8Yj5UaGVzZSBpbnRlcm5hbCBjb2xsaXNpb24gYXR0YWNrcyBkbyBub3QgYWZmZWN0IHRo ZSBzZWN1cml0eSBvZiBTSEEzLCBiZWNhdXNlIG9mIHRoZSBsYXJnZXIgY2FwYWNpdHkgdXNlZC48 L2I+PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90Oyxz YW5zLXNlcmlmO2NvbG9yOiMyQzQzNTM7YmFja2dyb3VuZDojRTNFM0UzIj4mbmJzcDs8L3NwYW4+ PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJF Ti1HQiI+QWx0ZXJuYXRpdmVseSwganVzdCBkcm9wIHRoZSByZWZlcmVuY2UgdG8gU0hBMywgd2hp Y2ggaXNu4oCZdCByZWxldmVudCB0byBYTVNTLjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPiZuYnNwOzwvc3Bhbj48bzpwPjwv bzpwPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6 YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+PHNwYW4gbGFuZz0iRU4tR0IiPlRoZSBv dGhlciBuaXQgaXMgd2l0aCB0aGUgc2VudGVuY2UgdGhhdCBzdGFydHM6PC9zcGFuPjxvOnA+PC9v OnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+Jm5ic3A7 PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTomcXVvdDtBcmlhbCZxdW90OyxzYW5zLXNl cmlmO2NvbG9yOiMyQzQzNTM7YmFja2dyb3VuZDojRTNFM0UzIj5BbnkgYXR0YWNrIHRoYXQgYnJl YWtzIHRoZSByZWxldmFudCBzZWN1cml0eSBkZWZpbml0aW9uIG11c3QgcmVxdWlyZSBjb21wdXRh dGlvbmFsDQogcmVzb3VyY2Vz4oCmPC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjEwLjVwdDtmb250LWZhbWlseTom cXVvdDtBcmlhbCZxdW90OyxzYW5zLXNlcmlmO2NvbG9yOiMyQzQzNTM7YmFja2dyb3VuZDojRTNF M0UzIj4mbmJzcDs8L3NwYW4+PC9iPjxvOnA+PC9vOnA+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj48c3BhbiBsYW5nPSJFTi1HQiI+VGhhdCBzb3J0IG9mIHN0YXRlbWVudCBhbHdheXMgaGFz IGFuIGltcGxpY2l0IGFzc3VtcHRpb24gb2YgdGhlIGZvcm0g4oCcdW5sZXNzIHNvbWVvbmUgaGFz IGEgY3J5cHRvZ3JhcGhpY2FsIHJlc3VsdCBhZ2FpbnN0IHRoZSBTSEEtMyBwZXJtdXRhdGlvbuKA nTsgd2hpbGUgd2UgYXJlDQogdXNlZCB0byB0aGF0IHNvcnQgb2YgYXNzdW1wdGlvbiwgYSBjYXVz YWwgcmVhZGVyIG1pZ2h0IG5vdCBiZS4mbmJzcDsgSSBkb27igJl0IHNlZSB3aGF0IHRoYXQgc2Vu dGVuY2UgYnJpbmdzIHRvIHRoZSB0YWJsZTsgSeKAmWQgc3VnZ2VzdCBkcm9wcGluZyBpdC48L3Nw YW4+PG86cD48L286cD48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdp bi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxzcGFuIHN0eWxlPSJm b250LXNpemU6MTAuNXB0O2ZvbnQtZmFtaWx5OiZxdW90O0FyaWFsJnF1b3Q7LHNhbnMtc2VyaWY7 Y29sb3I6IzJDNDM1MztiYWNrZ3JvdW5kOiNFM0UzRTMiPiZuYnNwOzwvc3Bhbj48bzpwPjwvbzpw PjwvcD4NCjxkaXYgc3R5bGU9ImJvcmRlcjpub25lO2JvcmRlci1sZWZ0OnNvbGlkIGJsdWUgMS41 cHQ7cGFkZGluZzowaW4gMGluIDBpbiA0LjBwdCI+DQo8ZGl2Pg0KPGRpdiBzdHlsZT0iYm9yZGVy Om5vbmU7Ym9yZGVyLXRvcDpzb2xpZCAjRTFFMUUxIDEuMHB0O3BhZGRpbmc6My4wcHQgMGluIDBp biAwaW4iPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDph dXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj5Gcm9tOjwvYj4gQ3J5cHRvLXBhbmVs ICZsdDs8YSBocmVmPSJtYWlsdG86Y3J5cHRvLXBhbmVsLWJvdW5jZXNAaXJ0Zi5vcmciIHRhcmdl dD0iX2JsYW5rIj5jcnlwdG8tcGFuZWwtYm91bmNlc0BpcnRmLm9yZzwvYT4mZ3Q7DQo8Yj5PbiBC ZWhhbGYgT2YgPC9iPlN0YW5pc2xhdiBWLiBTbXlzaGx5YWV2PGJyPg0KPGI+U2VudDo8L2I+IFRo dXJzZGF5LCBKdW5lIDExLCAyMDIwIDE6NTcgUE08YnI+DQo8Yj5Ubzo8L2I+IDxhIGhyZWY9Im1h aWx0bzpjcnlwdG8tcGFuZWxAaXJ0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jcnlwdG8tcGFuZWxA aXJ0Zi5vcmc8L2E+PGJyPg0KPGI+Q2M6PC9iPiA8YSBocmVmPSJtYWlsdG86Y2ZyZy1jaGFpcnNA aWV0Zi5vcmciIHRhcmdldD0iX2JsYW5rIj5jZnJnLWNoYWlyc0BpZXRmLm9yZzwvYT48YnI+DQo8 Yj5TdWJqZWN0OjwvYj4gW0NyeXB0by1wYW5lbF0gRndkOiBbaXJzZ10gW1RlY2huaWNhbCBFcnJh dGEgUmVwb3J0ZWRdIFJGQzgzOTEgKDYwMjQpPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2 Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21z by1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8 ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRv O21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5EZWFyIENyeXB0byBSZXZpZXcgUGFuZWwgbWVt YmVycyw8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNz PSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJv dHRvbS1hbHQ6YXV0byI+VGhlcmUgaXMgYSBuZWVkIHRvIHZhbGlkYXRlIHRoZSBmb2xsb3dpbmcg ZXJyYXRhOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJN c29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRv bS1hbHQ6YXV0byI+PGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci4ub3JnL2VycmF0YS9l aWQ2MDI0IiB0YXJnZXQ9Il9ibGFuayI+aHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRh L2VpZDYwMjQ8L2E+PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNv Tm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20t YWx0OmF1dG8iPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5Bbnkgdm9sdW50ZWVycz88bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRp dj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bztt c28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4N CjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1 dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPlJlZ2FyZHMsPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3At YWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPkNGUkcgY2hhaXJzPG86cD48L286 cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBz dHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8i PiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1h bCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDph dXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05v cm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFs dDphdXRvIj4tLS0tLS0tLS0tINCf0LXRgNC10YHRi9C70LDQtdC80L7QtSDRgdC+0L7QsdGJ0LXQ vdC40LUgLS0tLS0tLS0tPGJyPg0K0J7RgjogPHN0cm9uZz48c3BhbiBzdHlsZT0iZm9udC1mYW1p bHk6JnF1b3Q7Q2FsaWJyaSZxdW90OyxzYW5zLXNlcmlmIj5Db2xpbiBQZXJraW5zPC9zcGFuPjwv c3Ryb25nPiAmbHQ7PGEgaHJlZj0ibWFpbHRvOmNzcEBjc3BlcmtpbnMub3JnIiB0YXJnZXQ9Il9i bGFuayI+Y3NwQGNzcGVya2lucy5vcmc8L2E+Jmd0Ozxicj4NCtCU0LDRgtCwOiDRgdCxLCA2INC4 0Y7QvdGPIDIwMjAg0LMuINCyIDE2OjAzPGJyPg0K0KLQtdC80LA6IEZ3ZDogW2lyc2ddIFtUZWNo bmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM4MzkxICg2MDI0KTxicj4NCtCa0L7QvNGDOiAmbHQ7 PGEgaHJlZj0ibWFpbHRvOmNmcmctY2hhaXJzQGlldGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+Y2Zy Zy1jaGFpcnNAaWV0Zi5vcmc8L2E+Jmd0OzxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bWFyZ2luLWJvdHRv bToxMi4wcHQiPiZuYnNwOzxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0 b20tYWx0OmF1dG8iPkhpIENGUkcgY2hhaXJzLDxvOnA+PC9vOnA+PC9wPg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2lu LWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHlsZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1h cmdpbi1ib3R0b20tYWx0OmF1dG8iPkNhbiB5b3UgZGlzY3VzcywgYW5kIHJldmlldyB3aXRoIHRo ZSBSRyBpZiBuZWNlc3NhcnksIGFuZCBsZXQgbWUga25vdyAmbmJzcDtpZiB0aGUgZm9sbG93aW5n IGVycmF0YSBzaG91bGQgYmUgbWFya2VkIGFzIHZlcmlmaWVkLjxvOnA+PC9vOnA+PC9wPg0KPC9k aXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFs dDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+VGhhbmtzLDxvOnA+PC9vOnA+ PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJn aW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj5Db2xpbjxvOnA+PC9v OnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJt c28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5ic3A7 PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1t YXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij48bzpwPiZuYnNwOzwvbzpw PjwvcD4NCjxibG9ja3F1b3RlIHN0eWxlPSJtYXJnaW4tdG9wOjUuMHB0O21hcmdpbi1ib3R0b206 NS4wcHQiPg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxlPSJtc28tbWFyZ2luLXRv cC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+QmVnaW4gZm9yd2FyZGVkIG1l c3NhZ2U6PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0eWxl PSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+Jm5i c3A7PG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3Bh biBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6Ymxh Y2siPkZyb206DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2 ZXRpY2EgTmV1ZSZxdW90OyI+UkZDIEVycmF0YSBTeXN0ZW0gJmx0OzxhIGhyZWY9Im1haWx0bzpy ZmMtZWRpdG9yQHJmYy1lZGl0b3Iub3JnIiB0YXJnZXQ9Il9ibGFuayI+cmZjLWVkaXRvckByZmMt ZWRpdG9yLm9yZzwvYT4mZ3Q7PC9zcGFuPjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0K PHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1t YXJnaW4tYm90dG9tLWFsdDphdXRvIj48Yj48c3BhbiBzdHlsZT0iZm9udC1mYW1pbHk6JnF1b3Q7 SGVsdmV0aWNhIE5ldWUmcXVvdDs7Y29sb3I6YmxhY2siPlN1YmplY3Q6DQo8L3NwYW4+PC9iPjxi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90OyI+W2ly c2ddIFtUZWNobmljYWwgRXJyYXRhIFJlcG9ydGVkXSBSRkM4MzkxICg2MDI0KTwvc3Bhbj48L2I+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xv cjpibGFjayI+RGF0ZToNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij4xOCBNYXJjaCAyMDIwIGF0IDEzOjAxOjUyIEdNVDwvc3Bh bj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiIHN0 eWxlPSJtc28tbWFyZ2luLXRvcC1hbHQ6YXV0bzttc28tbWFyZ2luLWJvdHRvbS1hbHQ6YXV0byI+ PGI+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90O0hlbHZldGljYSBOZXVlJnF1b3Q7O2Nv bG9yOmJsYWNrIj5UbzoNCjwvc3Bhbj48L2I+PHNwYW4gc3R5bGU9ImZvbnQtZmFtaWx5OiZxdW90 O0hlbHZldGljYSBOZXVlJnF1b3Q7Ij48YSBocmVmPSJtYWlsdG86aWV0ZkBodWVsc2luZy5uZXQi IHRhcmdldD0iX2JsYW5rIj5pZXRmQGh1ZWxzaW5nLm5ldDwvYT4sDQo8YSBocmVmPSJtYWlsdG86 ZGJ1dGluQGNkYy5pbmZvcm1hdGlrLnR1LWRhcm1zdGFkdC5kZSIgdGFyZ2V0PSJfYmxhbmsiPmRi dXRpbkBjZGMuaW5mb3JtYXRpay50dS1kYXJtc3RhZHQuZGU8L2E+LA0KPGEgaHJlZj0ibWFpbHRv OmlldGZAZ2F6ZGFnLmRlIiB0YXJnZXQ9Il9ibGFuayI+aWV0ZkBnYXpkYWcuZGU8L2E+LCA8YSBo cmVmPSJtYWlsdG86aWV0ZkBqb29zdHJpam5ldmVsZC5ubCIgdGFyZ2V0PSJfYmxhbmsiPg0KaWV0 ZkBqb29zdHJpam5ldmVsZC5ubDwvYT4sIDxhIGhyZWY9Im1haWx0bzptb2hhaXNlbkBpZWVlLm9y ZyIgdGFyZ2V0PSJfYmxhbmsiPm1vaGFpc2VuQGllZWUub3JnPC9hPiwNCjxhIGhyZWY9Im1haWx0 bzppcnNnQGlydGYub3JnIiB0YXJnZXQ9Il9ibGFuayI+aXJzZ0BpcnRmLm9yZzwvYT48L3NwYW4+ PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIiBzdHls ZT0ibXNvLW1hcmdpbi10b3AtYWx0OmF1dG87bXNvLW1hcmdpbi1ib3R0b20tYWx0OmF1dG8iPjxi PjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtIZWx2ZXRpY2EgTmV1ZSZxdW90Oztjb2xv cjpibGFjayI+Q2M6DQo8L3NwYW4+PC9iPjxzcGFuIHN0eWxlPSJmb250LWZhbWlseTomcXVvdDtI ZWx2ZXRpY2EgTmV1ZSZxdW90OyI+PGEgaHJlZj0ibWFpbHRvOmlldGZAaHVlbHNpbmcubmV0IiB0 YXJnZXQ9Il9ibGFuayI+aWV0ZkBodWVsc2luZy5uZXQ8L2E+LA0KPGEgaHJlZj0ibWFpbHRvOnJm Yy1lZGl0b3JAcmZjLWVkaXRvci5vcmciIHRhcmdldD0iX2JsYW5rIj5yZmMtZWRpdG9yQHJmYy1l ZGl0b3Iub3JnPC9hPjwvc3Bhbj48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9t LWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpwPjwvcD4NCjxkaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4tdG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90 dG9tLWFsdDphdXRvIj5UaGUgZm9sbG93aW5nIGVycmF0YSByZXBvcnQgaGFzIGJlZW4gc3VibWl0 dGVkIGZvciBSRkM4MzkxLDxicj4NCiZxdW90O1hNU1M6IGVYdGVuZGVkIE1lcmtsZSBTaWduYXR1 cmUgU2NoZW1lJnF1b3Q7Ljxicj4NCjxicj4NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tPGJyPg0KWW91IG1heSByZXZpZXcgdGhlIHJlcG9ydCBiZWxvdyBhbmQgYXQ6PGJy Pg0KPGEgaHJlZj0iaHR0cHM6Ly93d3cucmZjLWVkaXRvci5vcmcvZXJyYXRhL2VpZDYwMjQiIHRh cmdldD0iX2JsYW5rIj5odHRwczovL3d3dy5yZmMtZWRpdG9yLm9yZy9lcnJhdGEvZWlkNjAyNDwv YT48YnI+DQo8YnI+DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLTxicj4N ClR5cGU6IFRlY2huaWNhbDxicj4NClJlcG9ydGVkIGJ5OiBBbmRyZWFzIEjDvGxzaW5nICZsdDs8 YSBocmVmPSJtYWlsdG86aWV0ZkBodWVsc2luZy5uZXQiIHRhcmdldD0iX2JsYW5rIj5pZXRmQGh1 ZWxzaW5nLm5ldDwvYT4mZ3Q7PGJyPg0KPGJyPg0KU2VjdGlvbjogNTxicj4NCjxicj4NCk9yaWdp bmFsIFRleHQ8YnI+DQotLS0tLS0tLS0tLS0tPGJyPg0KVGhpcyBzZWN0aW9uIHByb3ZpZGVzIGJh c2ljIHBhcmFtZXRlciBzZXRzIHRoYXQgYXJlIGFzc3VtZWQgdG8gY292ZXIgbW9zdCByZWxldmFu dCBhcHBsaWNhdGlvbnMuJm5ic3A7IFBhcmFtZXRlciBzZXRzIGZvciB0d28gY2xhc3NpY2FsIHNl Y3VyaXR5IGxldmVscyBhcmUgZGVmaW5lZC4mbmJzcDsgUGFyYW1ldGVycyB3aXRoIG4gPSAzMiBw cm92aWRlIGEgY2xhc3NpY2FsIHNlY3VyaXR5IGxldmVsIG9mIDI1NiBiaXRzLiZuYnNwOyBQYXJh bWV0ZXJzIHdpdGggbiA9IDY0IHByb3ZpZGUNCiBhIGNsYXNzaWNhbCBzZWN1cml0eSBsZXZlbCBv ZiA1MTIgYml0cy4mbmJzcDsgQ29uc2lkZXJpbmcgcXVhbnR1bS1jb21wdXRlci1haWRlZCBhdHRh Y2tzLCB0aGVzZSBvdXRwdXQgc2l6ZXMgeWllbGQgcG9zdC1xdWFudHVtIHNlY3VyaXR5IG9mIDEy OCBhbmQgMjU2IGJpdHMsIHJlc3BlY3RpdmVseS48YnI+DQo8YnI+DQpDb3JyZWN0ZWQgVGV4dDxi cj4NCi0tLS0tLS0tLS0tLS0tPGJyPg0KVGhpcyBzZWN0aW9uIHByb3ZpZGVzIGJhc2ljIHBhcmFt ZXRlciBzZXRzIHRoYXQgYXJlIGFzc3VtZWQgdG8gY292ZXIgbW9zdCByZWxldmFudCBhcHBsaWNh dGlvbnMuIFBhcmFtZXRlciBzZXRzIGZvciB0d28gY2xhc3NpY2FsIHNlY3VyaXR5IGxldmVscyBh cmUgZGVmaW5lZCB1c2luZyB0aGUgY3J5cHRvZ3JhcGhpYyBmdW5jdGlvbnMgU0hBMiBhbmQgU0hB S0UuJm5ic3A7IFBhcmFtZXRlcnMgd2l0aCBTSEEyIGFuZCBuID0gMzIgcHJvdmlkZSBhIGNsYXNz aWNhbA0KIHNlY3VyaXR5IGxldmVsIG9mIDI1NiBiaXRzLiBQYXJhbWV0ZXJzIHdpdGggU0hBMiBh bmQgbiA9IDY0IHByb3ZpZGUgYSBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2ZWwgb2YgNTEyIGJpdHMu Jm5ic3A7IENvbnNpZGVyaW5nIHF1YW50dW0tY29tcHV0ZXItYWlkZWQgYXR0YWNrcywgdGhlc2Ug cGFyYW1ldGVycyB5aWVsZCBwb3N0LXF1YW50dW0gc2VjdXJpdHkgb2YgMTI4IGFuZCAyNTYgYml0 cywgcmVzcGVjdGl2ZWx5LiBQYXJhbWV0ZXJzIHdpdGggU0hBS0UgYW5kDQogbiA9IDMyIHByb3Zp ZGUgYSBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2ZWwgb2YgMTI4IGJpdHMuJm5ic3A7IFBhcmFtZXRl cnMgd2l0aCBTSEFLRSBhbmQgbiA9IDY0IHByb3ZpZGUgYSBjbGFzc2ljYWwgc2VjdXJpdHkgbGV2 ZWwgb2YgMjU2IGJpdHMuJm5ic3A7IENvbnNpZGVyaW5nIHF1YW50dW0tY29tcHV0ZXItYWlkZWQg YXR0YWNrcywgdGhlc2UgcGFyYW1ldGVycyB5aWVsZCBwb3N0LXF1YW50dW0gc2VjdXJpdHkgb2Yg ODYgYW5kIDE3MCBiaXRzLCByZXNwZWN0aXZlbHkuDQo8YnI+DQo8YnI+DQpOb3Rlczxicj4NCi0t LS0tPGJyPg0KVHJhZGl0aW9uYWxseSwgYSBoYXNoIGZ1bmN0aW9uIHdpdGggbi1iaXQgb3V0cHV0 cyBpcyBhc3N1bWVkIHRvIGhhdmUgbi1iaXQgc2VjdXJpdHkgYWdhaW5zdCBjbGFzc2ljYWwgcHJl aW1hZ2UgYW5kIHNlY29uZC1wcmVpbWFnZSBhdHRhY2tzLCBhbmQgbi8yLWJpdCBzZWN1cml0eSBh Z2FpbnN0IGNsYXNzaWNhbCBjb2xsaXNpb24gYXR0YWNrcy4gRm9yIGFkdmVyc2FyaWVzIHdpdGgg YWNjZXNzIHRvIGEgcXVhbnR1bSBjb21wdXRlciwgdGhlc2UgYm91bmRzDQogY2hhbmdlIHRvIG4v MiBhbmQgbi8zIGJpdHMgd2hlbiBvbmx5IGNvdW50aW5nIHF1ZXJpZXMgdG8gdGhlIGhhc2ggZnVu Y3Rpb24uIFRoaXMgYWxzbyBhcHBsaWVzIHRvIFNIQTIgYW5kIFNIQTMuIEluIGNvbnRyYXN0LCBT SEFLRSBmb2xsb3dzIGEgZGlmZmVyZW50IHJlYXNvbmluZy4gU0hBS0Ugd2l0aCBhbiBpbnRlcm5h bCBzdGF0ZSBvZiBuIGJpdHMgYW5kIGFuIG91dHB1dCBsZW5ndGggb2YgbiBiaXRzIGFjaGlldmVz IG4vMiBiaXQgc2VjdXJpdHkNCiBhZ2FpbnN0IGNsYXNzaWNhbCBwcmVpbWFnZSwgc2Vjb25kLXBy ZWltYWdlIGFuZCBjb2xsaXNpb24gYXR0YWNrcy4gRm9yIHF1YW50dW0gYXR0YWNrcyBzZWN1cml0 eSBjaGFuZ2VzIHRvIG4vMyBiaXRzLiBUaGUgcmVhc29uIGlzIHRoYXQgU0hBS0UgYWxsb3dzIGZv ciBtZWV0LWluLXRoZS1taWRkbGUgcHJlaW1hZ2UgYXR0YWNrcyB0aGF0IHJlZHVjZSB0byBhIGNv bGxpc2lvbiBzZWFyY2ggb24gdGhlIGludGVybmFsIHN0YXRlLiBUaGUgc2FtZSBhcHBsaWVzDQog Zm9yIFNIQTMgYnV0IGZvciBTSEEzIGEgYmlnZ2VyIGludGVybmFsIHN0YXRlIGlzIHVzZWQuPGJy Pg0KPGJyPg0KSW4gY29uc2VxdWVuY2UsIFNIQUtFLTEyOCBjYW5ub3QgcHJvdmlkZSBtb3JlIHNl Y3VyaXR5IHRoYW4gTklTVCBwb3N0LXF1YW50dW0gc2VjdXJpdHkgbGV2ZWwgSUkgKEFueSBhdHRh Y2sgdGhhdCBicmVha3MgdGhlIHJlbGV2YW50IHNlY3VyaXR5IGRlZmluaXRpb24gbXVzdCByZXF1 aXJlIGNvbXB1dGF0aW9uYWwgcmVzb3VyY2VzIGNvbXBhcmFibGUgdG8gb3IgZ3JlYXRlciB0aGFu IHRob3NlIHJlcXVpcmVkIGZvciBjb2xsaXNpb24gc2VhcmNoIG9uDQogYSAyNTYtYml0IGhhc2gg ZnVuY3Rpb24gKGUuZy4gU0hBMjU2IC8gU0hBMy0yNTYpKS48YnI+DQo8YnI+DQpJbnN0cnVjdGlv bnM6PGJyPg0KLS0tLS0tLS0tLS0tLTxicj4NClRoaXMgZXJyYXR1bSBpcyBjdXJyZW50bHkgcG9z dGVkIGFzICZxdW90O1JlcG9ydGVkJnF1b3Q7LiBJZiBuZWNlc3NhcnksIHBsZWFzZTxicj4NCnVz ZSAmcXVvdDtSZXBseSBBbGwmcXVvdDsgdG8gZGlzY3VzcyB3aGV0aGVyIGl0IHNob3VsZCBiZSB2 ZXJpZmllZCBvcjxicj4NCnJlamVjdGVkLiBXaGVuIGEgZGVjaXNpb24gaXMgcmVhY2hlZCwgdGhl IHZlcmlmeWluZyBwYXJ0eSAmbmJzcDs8YnI+DQpjYW4gbG9nIGluIHRvIGNoYW5nZSB0aGUgc3Rh dHVzIGFuZCBlZGl0IHRoZSByZXBvcnQsIGlmIG5lY2Vzc2FyeS4gPGJyPg0KPGJyPg0KLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpSRkM4MzkxIChkcmFmdC1pcnRm LWNmcmcteG1zcy1oYXNoLWJhc2VkLXNpZ25hdHVyZXMtMTIpPGJyPg0KLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS08YnI+DQpUaXRsZSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsm bmJzcDs6IFhNU1M6IGVYdGVuZGVkIE1lcmtsZSBTaWduYXR1cmUgU2NoZW1lPGJyPg0KUHVibGlj YXRpb24gRGF0ZSAmbmJzcDsmbmJzcDsmbmJzcDs6IE1heSAyMDE4PGJyPg0KQXV0aG9yKHMpICZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNw OzogQS4gSHVlbHNpbmcsIEQuIEJ1dGluLCBTLiBHYXpkYWcsIEouIFJpam5ldmVsZCwgQS4uIE1v aGFpc2VuPGJyPg0KQ2F0ZWdvcnkgJm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7 Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7Jm5ic3A7OiBJTkZPUk1BVElPTkFMPGJyPg0KU291cmNl ICZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOyZu YnNwOyZuYnNwOyZuYnNwOyZuYnNwOzogQ3J5cHRvIEZvcnVtIFJlc2VhcmNoIEdyb3VwPGJyPg0K QXJlYSAmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDs6IE4vQTxicj4NClN0cmVhbSAm bmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJzcDsmbmJz cDsmbmJzcDsmbmJzcDsmbmJzcDs6IElSVEY8YnI+DQpWZXJpZnlpbmcgUGFydHkgJm5ic3A7Jm5i c3A7Jm5ic3A7Jm5ic3A7OiBJUlNHPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9i bG9ja3F1b3RlPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1z by1tYXJnaW4tdG9wLWFsdDphdXRvO21hcmdpbi1ib3R0b206MTIuMHB0Ij4mbmJzcDs8bzpwPjwv bzpwPjwvcD4NCjwvZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCIgc3R5bGU9Im1zby1tYXJnaW4t dG9wLWFsdDphdXRvO21zby1tYXJnaW4tYm90dG9tLWFsdDphdXRvIj4mbmJzcDs8bzpwPjwvbzpw PjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwv ZGl2Pg0KPC9kaXY+DQo8L2Jsb2NrcXVvdGU+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Jv ZHk+DQo8L2h0bWw+DQo= --_000_BN7PR11MB2641D883BEAB8B248ABCF910C19C0BN7PR11MB2641namp_-- From nobody Mon Jun 15 04:59:28 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AA6553A0CE0 for ; Mon, 15 Jun 2020 04:59:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Mfb4ssPhJ05K for ; Mon, 15 Jun 2020 04:59:19 -0700 (PDT) Received: from mail-lj1-x22e.google.com (mail-lj1-x22e.google.com [IPv6:2a00:1450:4864:20::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 512193A0CD5 for ; Mon, 15 Jun 2020 04:59:19 -0700 (PDT) Received: by mail-lj1-x22e.google.com with SMTP id n24so18765806lji.10 for ; Mon, 15 Jun 2020 04:59:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=E8l7GAwc61Y+t+UzPnWk4hacMbvAE5TNQs/C5VUdXU4=; b=efZV4EiwWn7f5RessOrjcaLC6mFOoeHFRIvLoapJQjxZ2dLX/NGyg5XYtBV5XUfGFK VhuGYHy/zOgbavPMMuI5V5tbySjobf2L5C+Z8Oi1uQ7j51N0HXicr0DYolPdBycUj8Hg ckwKHNCap/ylKFKNBNXePAkZK6gZkHWQ64Z7rLEPnFJKKNSlz+5J+cAQZF5lgr0nhK1e JaK8Z/X1qH2fTZK79ffLdgVNe/AvdJrg1bmCFlZ1/YQginwWqHL/IiMML8RpAKOMjL8C EQZid+PwqICSEGhW9/h1IN9x3y1Px28OI2mIAOFFcqlJIJkaMNgDqBjU9KVY67xNiMiO uJHg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=E8l7GAwc61Y+t+UzPnWk4hacMbvAE5TNQs/C5VUdXU4=; b=hFrB34rx6JGroPX9c1x713dUdxfuOwlo7w+0ayh9N5CueYBY6yMMVTnFucwtENhr4o vJTHYCt+PZxzF8KPwmWhUvqTE8Bk60OuIdTI0XgkLwmbKyXCKTc/NIcjDs9H6aBnZCXM 13cjTI1r+GN+UaKQ3yc7yxHkTeNpy0dfIYUfRfRQDljQCUyT5fxJgqtOy8KvCeKzvlYh +mgBceqtZSQcR36qUMmip5py+ixZ9kicAuFksZZmtTihFE7e18ZQ1hywKW/CgZ0BjgiV QMo1vbsZL7x73c4nXwNtFwGdGn4V1aMQw1KJ6ws9eEYVuuyyulb3DXnhPXFvNQxzevWW ITcA== X-Gm-Message-State: AOAM533mwDx51Ne0Z/axUOhXlnhiyXj2OCSNF3LAmEkN4SLCO+k4m111 NYGuibg/7PdxfQAMhhqVcVUNaHlkKptdBMsunic= X-Google-Smtp-Source: ABdhPJwHhXbIAGoVl6/ochv1T4LWOg8GYbVwPBMC62of9074/cQJ//24MeFMKQEnyEYQg0DJ26b94BFfOobGnTsjCW4= X-Received: by 2002:a2e:7006:: with SMTP id l6mr13939440ljc.453.1592222357305; Mon, 15 Jun 2020 04:59:17 -0700 (PDT) MIME-Version: 1.0 References: <20200318130152.57FD7F4071D@rfc-editor.org> In-Reply-To: From: "Stanislav V. Smyshlyaev" Date: Mon, 15 Jun 2020 14:59:06 +0300 Message-ID: To: "Scott Fluhrer (sfluhrer)" Cc: "crypto-panel@irtf.org" , "cfrg-chairs@ietf.org" Content-Type: multipart/alternative; boundary="00000000000002be6605a81e28fe" Archived-At: Subject: Re: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 (6024) X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 11:59:23 -0000 --00000000000002be6605a81e28fe Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Agreed, thanks! Regards, Stanislav On Mon, 15 Jun 2020 at 14:58, Scott Fluhrer (sfluhrer) wrote: > Actually, I=E2=80=99d be happy either way (as these are =E2=80=98nits=E2= =80=99, not real > problems). Those changes would be my suggestion. > > > > *From:* Stanislav V. Smyshlyaev > *Sent:* Monday, June 15, 2020 4:01 AM > *To:* Scott Fluhrer (sfluhrer) > *Cc:* crypto-panel@irtf.org; cfrg-chairs@ietf.org > *Subject:* Re: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] > RFC8391 (6024) > > > > Many thanks, Scott! > > > > Therefore, you will be happy if the proposed change is applied, with the > revised version of notes, dropping the sentences "The same applies for SH= A3 > ... " and "(Any attack that breaks...", =E2=80=93 right? > > > > Regards, > > Stanislav > > > > > > On Thu, 11 Jun 2020 at 22:48, Scott Fluhrer (sfluhrer) > wrote: > > The text looks correct, however I do have a few nits about the notes. On= e > is the reference to SHA3, which on a quick read might be misleading; here > is some alterative text: > > > > The reason is that SHAKE allows for meet-in-the-middle preimage attacks > that reduce to a collision search on the internal state. *These internal > collision attacks do not affect the security of SHA3, because of the larg= er > capacity used.* > > > > Alternatively, just drop the reference to SHA3, which isn=E2=80=99t relev= ent to > XMSS. > > > > The other nit is with the sentence that starts: > > > > Any attack that breaks the relevant security definition must require > computational resources=E2=80=A6 > > > > That sort of statement always has an implicit assumption of the form > =E2=80=9Cunless someone has a cryptographical result against the SHA-3 > permutation=E2=80=9D; while we are used to that sort of assumption, a cau= sal reader > might not be. I don=E2=80=99t see what that sentence brings to the table= ; I=E2=80=99d > suggest dropping it. > > > > *From:* Crypto-panel *On Behalf Of *Stani= slav > V. Smyshlyaev > *Sent:* Thursday, June 11, 2020 1:57 PM > *To:* crypto-panel@irtf.org > *Cc:* cfrg-chairs@ietf.org > *Subject:* [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8391 > (6024) > > > > Dear Crypto Review Panel members, > > > > There is a need to validate the following errata: > > https://www.rfc-editor.org/errata/eid6024 > > > > > Any volunteers? > > > > Regards, > > CFRG chairs > > > > > > > > ---------- =D0=9F=D0=B5=D1=80=D0=B5=D1=81=D1=8B=D0=BB=D0=B0=D0=B5=D0=BC= =D0=BE=D0=B5 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B5 -------= -- > =D0=9E=D1=82: *Colin Perkins* > =D0=94=D0=B0=D1=82=D0=B0: =D1=81=D0=B1, 6 =D0=B8=D1=8E=D0=BD=D1=8F 2020 = =D0=B3. =D0=B2 16:03 > =D0=A2=D0=B5=D0=BC=D0=B0: Fwd: [irsg] [Technical Errata Reported] RFC8391= (6024) > =D0=9A=D0=BE=D0=BC=D1=83: > > > > Hi CFRG chairs, > > > > Can you discuss, and review with the RG if necessary, and let me know if > the following errata should be marked as verified. > > > > Thanks, > > Colin > > > > > > > > Begin forwarded message: > > > > *From: *RFC Errata System > > *Subject: **[irsg] [Technical Errata Reported] RFC8391 (6024)* > > *Date: *18 March 2020 at 13:01:52 GMT > > *To: *ietf@huelsing.net, dbutin@cdc.informatik.tu-darmstadt.de, > ietf@gazdag.de, ietf@joostrijneveld.nl, mohaisen@ieee.org, irsg@irtf.org > > *Cc: *ietf@huelsing.net, rfc-editor@rfc-editor.org > > > > The following errata report has been submitted for RFC8391, > "XMSS: eXtended Merkle Signature Scheme". > > -------------------------------------- > You may review the report below and at: > https://www.rfc-editor.org/errata/eid6024 > > -------------------------------------- > Type: Technical > Reported by: Andreas H=C3=BClsing > > Section: 5 > > Original Text > ------------- > This section provides basic parameter sets that are assumed to cover most > relevant applications. Parameter sets for two classical security levels > are defined. Parameters with n =3D 32 provide a classical security level= of > 256 bits. Parameters with n =3D 64 provide a classical security level of= 512 > bits. Considering quantum-computer-aided attacks, these output sizes yie= ld > post-quantum security of 128 and 256 bits, respectively. > > Corrected Text > -------------- > This section provides basic parameter sets that are assumed to cover most > relevant applications. Parameter sets for two classical security levels a= re > defined using the cryptographic functions SHA2 and SHAKE. Parameters wit= h > SHA2 and n =3D 32 provide a classical security level of 256 bits. Paramet= ers > with SHA2 and n =3D 64 provide a classical security level of 512 bits. > Considering quantum-computer-aided attacks, these parameters yield > post-quantum security of 128 and 256 bits, respectively. Parameters with > SHAKE and n =3D 32 provide a classical security level of 128 bits. > Parameters with SHAKE and n =3D 64 provide a classical security level of = 256 > bits. Considering quantum-computer-aided attacks, these parameters yield > post-quantum security of 86 and 170 bits, respectively. > > Notes > ----- > Traditionally, a hash function with n-bit outputs is assumed to have n-bi= t > security against classical preimage and second-preimage attacks, and > n/2-bit security against classical collision attacks. For adversaries wit= h > access to a quantum computer, these bounds change to n/2 and n/3 bits whe= n > only counting queries to the hash function. This also applies to SHA2 and > SHA3. In contrast, SHAKE follows a different reasoning. SHAKE with an > internal state of n bits and an output length of n bits achieves n/2 bit > security against classical preimage, second-preimage and collision attack= s. > For quantum attacks security changes to n/3 bits. The reason is that SHAK= E > allows for meet-in-the-middle preimage attacks that reduce to a collision > search on the internal state. The same applies for SHA3 but for SHA3 a > bigger internal state is used. > > In consequence, SHAKE-128 cannot provide more security than NIST > post-quantum security level II (Any attack that breaks the relevant > security definition must require computational resources comparable to or > greater than those required for collision search on a 256-bit hash functi= on > (e.g. SHA256 / SHA3-256)). > > Instructions: > ------------- > This erratum is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC8391 (draft-irtf-cfrg-xmss-hash-based-signatures-12) > -------------------------------------- > Title : XMSS: eXtended Merkle Signature Scheme > Publication Date : May 2018 > Author(s) : A. Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A.. > Mohaisen > Category : INFORMATIONAL > Source : Crypto Forum Research Group > Area : N/A > Stream : IRTF > Verifying Party : IRSG > > > > > > --00000000000002be6605a81e28fe Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Agreed, thanks!

Regards,
Stanislav

On Mon, 15 Jun 2020 at 14:58, Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com> wrote:

Actually, I=E2=80=99d be happy either way (as these = are =E2=80=98nits=E2=80=99, not real problems).=C2=A0 Those changes would b= e my suggestion.

=C2=A0

From: Stanislav V. Smyshlyaev <smyshsv@gmail.com>
Sent: Monday, June 15, 2020 4:01 AM
To: Scott Fluhrer (sfluhrer) <sfluhrer@cisco.com>
Cc: crypt= o-panel@irtf.org; cfrg-chairs@ietf.org
Subject: Re: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] = RFC8391 (6024)

=C2=A0

Many thanks, Scott!

=C2=A0

Therefore, you will be happy if the proposed change = is applied, with the revised version of notes, dropping the sentences "= ;The same applies for SHA3 ... " and "(Any attack that breaks...&= quot;, =E2=80=93 right?

=C2=A0

Regards,

Stanislav

=C2=A0

=C2=A0

On Thu, 11 Jun 2020 at 22:48, Scott Fluhrer (sfluhre= r) <sfluhrer@cis= co.com> wrote:

The text looks correct, however= I do have a few nits about the notes.=C2=A0 One is the reference to SHA3, = which on a quick read might be misleading; here is some alterative text:

=C2=A0

The reason is tha= t SHAKE allows for meet-in-the-middle preimage attacks that reduce to a collision search on the internal state. These internal collision a= ttacks do not affect the security of SHA3, because of the larger capacity u= sed.

=C2=A0<= /b>

Alternatively, just drop the re= ference to SHA3, which isn=E2=80=99t relevent to XMSS.=

=C2=A0

The other nit is with the sente= nce that starts:

=C2=A0

Any attack that b= reaks the relevant security definition must require computational resources=E2=80=A6

=C2=A0<= /b>

That sort of statement always h= as an implicit assumption of the form =E2=80=9Cunless someone has a cryptog= raphical result against the SHA-3 permutation=E2=80=9D; while we are used to that sort of assumption, a causal reader might not be.=C2=A0 I don= =E2=80=99t see what that sentence brings to the table; I=E2=80=99d suggest = dropping it.

=C2=A0<= /u>

From: Crypto-panel <crypto-panel-bounces@irtf.org<= /a>> On Behalf Of Stanislav V. Smyshlyaev
Sent: Thursday, June 11, 2020 1:57 PM
To: crypt= o-panel@irtf.org
Cc: cfrg-c= hairs@ietf.org
Subject: [Crypto-panel] Fwd: [irsg] [Technical Errata Reported] RFC8= 391 (6024)

=C2=A0

Dear Crypto Review Panel members,

=C2=A0

There is a need to validate the following errata:=

=C2=A0

Any volunteers?

=C2=A0

Regards,

CFRG chairs

=C2=A0

=C2=A0

=C2=A0

---------- =D0=9F=D0=B5=D1=80=D0=B5=D1=81=D1=8B=D0= =BB=D0=B0=D0=B5=D0=BC=D0=BE=D0=B5 =D1=81=D0=BE=D0=BE=D0=B1=D1=89=D0=B5=D0= =BD=D0=B8=D0=B5 ---------
=D0=9E=D1=82: Colin = Perkins <csp@csperkins.org>
=D0=94=D0=B0=D1=82=D0=B0: =D1=81=D0=B1, 6 =D0=B8=D1=8E=D0=BD=D1=8F 2020 =D0= =B3. =D0=B2 16:03
=D0=A2=D0=B5=D0=BC=D0=B0: Fwd: [irsg] [Technical Errata Reported] RFC8391 (= 6024)
=D0=9A=D0=BE=D0=BC=D1=83: <cfrg-chairs@ietf.org>

=C2=A0

Hi CFRG chairs,

=C2=A0

Can you discuss, and review with the RG if necessary= , and let me know =C2=A0if the following errata should be marked as verifie= d.

=C2=A0

Thanks,

Colin

=C2=A0

=C2=A0

=C2=A0

Begin forwarded message:

=C2=A0

From: RFC Errat= a System <rfc-editor@rfc-editor.org>

Subject: [irsg]= [Technical Errata Reported] RFC8391 (6024)

Date: 18 March = 2020 at 13:01:52 GMT

=C2=A0

The following errata report has been submitted for R= FC8391,
"XMSS: eXtended Merkle Signature Scheme".

--------------------------------------
You may review the report below and at:
htt= ps://www.rfc-editor.org/errata/eid6024

--------------------------------------
Type: Technical
Reported by: Andreas H=C3=BClsing <ietf@huelsing.net>

Section: 5

Original Text
-------------
This section provides basic parameter sets that are assumed to cover most r= elevant applications.=C2=A0 Parameter sets for two classical security level= s are defined.=C2=A0 Parameters with n =3D 32 provide a classical security = level of 256 bits.=C2=A0 Parameters with n =3D 64 provide a classical security level of 512 bits.=C2=A0 Considering quantum-computer= -aided attacks, these output sizes yield post-quantum security of 128 and 2= 56 bits, respectively.

Corrected Text
--------------
This section provides basic parameter sets that are assumed to cover most r= elevant applications. Parameter sets for two classical security levels are = defined using the cryptographic functions SHA2 and SHAKE.=C2=A0 Parameters = with SHA2 and n =3D 32 provide a classical security level of 256 bits. Parameters with SHA2 and n =3D 64 provide a cl= assical security level of 512 bits.=C2=A0 Considering quantum-computer-aide= d attacks, these parameters yield post-quantum security of 128 and 256 bits= , respectively. Parameters with SHAKE and n =3D 32 provide a classical security level of 128 bits.=C2=A0 Parameters = with SHAKE and n =3D 64 provide a classical security level of 256 bits.=C2= =A0 Considering quantum-computer-aided attacks, these parameters yield post= -quantum security of 86 and 170 bits, respectively.

Notes
-----
Traditionally, a hash function with n-bit outputs is assumed to have n-bit = security against classical preimage and second-preimage attacks, and n/2-bi= t security against classical collision attacks. For adversaries with access= to a quantum computer, these bounds change to n/2 and n/3 bits when only counting queries to the hash function= . This also applies to SHA2 and SHA3. In contrast, SHAKE follows a differen= t reasoning. SHAKE with an internal state of n bits and an output length of= n bits achieves n/2 bit security against classical preimage, second-preimage and collision attacks. For qua= ntum attacks security changes to n/3 bits. The reason is that SHAKE allows = for meet-in-the-middle preimage attacks that reduce to a collision search o= n the internal state. The same applies for SHA3 but for SHA3 a bigger internal state is used.

In consequence, SHAKE-128 cannot provide more security than NIST post-quant= um security level II (Any attack that breaks the relevant security definiti= on must require computational resources comparable to or greater than those= required for collision search on a 256-bit hash function (e.g. SHA256 / SHA3-256)).

Instructions:
-------------
This erratum is currently posted as "Reported". If necessary, ple= ase
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party =C2=A0
can log in to change the status and edit the report, if necessary.

--------------------------------------
RFC8391 (draft-irtf-cfrg-xmss-hash-based-signatures-12)
--------------------------------------
Title =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0: XMSS: eXtended Merkle Signature Scheme
Publication Date =C2=A0=C2=A0=C2=A0: May 2018
Author(s) =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0: A. = Huelsing, D. Butin, S. Gazdag, J. Rijneveld, A.. Mohaisen
Category =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= : INFORMATIONAL
Source =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0: Crypto Forum Research Group
Area =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0: N/A
Stream =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0: IRTF
Verifying Party =C2=A0=C2=A0=C2=A0=C2=A0: IRSG

=C2=A0

=C2=A0

--00000000000002be6605a81e28fe-- From nobody Mon Jun 15 09:28:51 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C3E003A0EEE for ; Mon, 15 Jun 2020 09:28:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.597 X-Spam-Level: X-Spam-Status: No, score=-1.597 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, FREEMAIL_FROM=0.001, GB_ABOUTYOU=0.5, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id qWExIXuzDR6y for ; Mon, 15 Jun 2020 09:28:46 -0700 (PDT) Received: from mail-oo1-xc32.google.com (mail-oo1-xc32.google.com [IPv6:2607:f8b0:4864:20::c32]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0D1AA3A0EDB for ; Mon, 15 Jun 2020 09:28:46 -0700 (PDT) Received: by mail-oo1-xc32.google.com with SMTP id y45so3468612ooi.8 for ; Mon, 15 Jun 2020 09:28:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5bHOsiZYsH4zcgkalDwK0EtZ3Ci3hNsXxIvz7cphfe8=; b=PEm7zItKgZXtzCX7wYw5J9QxIfSO93zK/cDCi/LVcGYP++BjODLyVIRs4HUGtaSvgV QankJErnS+yag3daCO7stzqX1HnM8xGbwzJ4ofDjs+dk3dacUT2vKkxKtg5VXb+vXXeq yw7I2/4o8I5EnhQ59V8/Z5t34nUlCTe/PSz3h0rjp3PksEr0yii5eAkQ1AzABgNzMHno yKGEx+Use2Yv8EJF124Hf1E53atHMpVfOnCMXpdLTYp42uqDbVC7JlAwI9JHxt8Sx1CE CGoAaPwjD2SJchuskKOzluTnNBzklW4dUqKWYbANbpjDoW8DGO4U7cSPfHgp9TZoodqm q1Lw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5bHOsiZYsH4zcgkalDwK0EtZ3Ci3hNsXxIvz7cphfe8=; b=oKLj04oL2G6zD/DebYVMz+a54L5ERJkUHIhXud1jOkH2UVsJsKlCXKQE9pMyxAnb/l gz/aeevJENPowFDOxSLgMt/YKGh4mG5NwsI0CeulJEu7mfnGR6Fc39VfwvWhD3P1OJRk 1OUDmr/qBIy3Aeq+ROLkoljvrQ9/l/oGdPR9P3wSJCngoTvb/geI2r139MLAkwascYAH QZS+jJW5sKach2TMKL4iBQGbQK+yfKfub7wqb+gmoDBIFBqFEePdZHkWMOf7VDRHy4/7 TpgFynrE2qd7DaRdWK1ucOYQZ0t9lbXoME/W3K0xVyI/UZHzQRgpBw5xjbo4Ym1u1Uhd Ugtg== X-Gm-Message-State: AOAM531TdUGzDam69qq+7zl1dTdCYcZDumTqL+5Mmkx3gPBPkMgiow/4 cejViTAp/l1KKxvWUbWObLHj+eIkEhA+ZNp1k10= X-Google-Smtp-Source: ABdhPJzIdgx1gb6QjRYYVkChVs6j5OBoIumeMrHpI6mK1OVZG1fxjH5aAGYW63/w91pKBGKyDOCHPISElp/PLmr/kcc= X-Received: by 2002:a4a:e89a:: with SMTP id g26mr21751427ooe.14.1592238524946; Mon, 15 Jun 2020 09:28:44 -0700 (PDT) MIME-Version: 1.0 References: <002201d61c30$4f561da0$ee0258e0$@hco.ntt.co.jp_1> In-Reply-To: From: Chloe Martindale Date: Mon, 15 Jun 2020 17:28:33 +0100 Message-ID: To: Yumi Sakemi Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org, Tetsutaro Kobayashi , SAITO Tsunekazu Content-Type: multipart/alternative; boundary="000000000000ad5e4d05a821ebe3" Archived-At: Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-pairing-friendly-curves-03 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jun 2020 16:28:49 -0000 --000000000000ad5e4d05a821ebe3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Dear Yumi, dear all, thank you for carefully taking my comments into consideration. I am much happier with the draft now! There are a few typos left, see below, and I just had a couple of comments on the security discussion but these are easily fixed. If you fix these small things in my opinion it's ready for RG Last Call. Abstract: Pairing is a special map -> Pairings are special maps OR A pairing is a special map 1.1 'Pairing is a special map' -> 'Pairings are special maps OR A pairing is a special map' 'importance of pairing' -> 'importance of pairings' 'pairing is efficiently computable' -> 'pairings are efficiently computable'. 1.2 pairins -> pairings 1.3 (NSF) -> (NFS) Barbulescu et. al. -> Barbulescu and Duquesne. (Authors are alphabetical). 2.2 -'The optimal Ate pairing is considered to be the most efficient to compute is the one that is most commonly used for practical implementation.' -> 'The optimal Ate pairing is considered to be the most efficient to compute and is the one that is most commonly used for practical implementation.' -Choose G_2 or G2 (probably G_2 is easier since there are many instances also of G_1 and G_T) -'There also exists cyclic subgroup' -> 'There also exists a cyclic subgroup' 2.3 -'b is an element of multiplicative group of order p' -> 'b is a nonzero element of F_p' OR 'b is an element of a multiplicative group (F_p)^* of order p-1' OR 'b is an element of the multiplicative group of F_p' -'embedded degree' -> 'embeddiing degree' 2.4 -'r-torsions' -> 'r-torsion' 2.5 -(paragraph 2): of degree d' -> of degree d 4.2 -This sentence has slightly weird grammar so I don't fully understand what you want to say: 'Therefore, the curve of the 128-bit security level is often used at current, so this memo recommends both BLS12-381 and BN462 in consideration of the future use and the safety side.' Do you mean: 'As curves of 128-bit security level are currently the most widely used, we recommend both BLS12-381 and BN462 in this memo in order to have a more efficient and a more prudent option respectively.' 4.2.1 -This comment is maybe a bit misleading: 'We have to note that, according to [BD18], the bit length of p for BLS12 to achieve 128-bit security is calculated as 461 bits and more, which BLS12_381 does not satisfy.' The 461-bit figure in [BD18] is based on a rough estimate which varies a lot between different examples (as is necessary when giving a broad overview). The exact complexity of [BD18]'s attack depends on the specific polynomial used to construct the family and can change the complexity of the attack by up to about 12 bits. The proposed construction of BLS12_381 you refer to here has been specially chosen to minimize the impact of the exTNFS attack. It would in my opinion be more precise to say: 'We have to note that the security level of this pairing is expected to be 126 rather than 128 bits [GMT19]'. 4.2.2 -This comment could be more clearly worded: 'We have to note that the BN462 becomes slower compared to BLS12_381, although the BN462 is suitable for the parameters of the 128-bit security level for the use of the future internet.' How about instead: 'We have to note that BN462 is significantly slower than BLS12_381, but has 134-bit security level [GMT19], so may be more resistant to future small improvements to the exTNFS attack.' This would be a good place to also add a remark along the lines of: 'We note also that CP8_544 is more efficient than BN462, has 131-bit security level, and that due to its construction will not be affected by future small improvements to the exTNFS attack. However, as this curve is not widely used (it is only implemented in one library), we instead chose BN462 for our 'safe' option.' 5. -'BLS curves of embedding degree 12 require' -> 'BLS curves of embedding degree typically require' (cf. my comment on 4.2.1) All the best, Chloe On Wed, 10 Jun 2020 at 05:06, Yumi Sakemi wrote= : > Dear Alexey, Nick, Stanislav, and Chloe > > We have submitted the latest version 05 of the draft "Pairing-Friendly > Curves". > https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves/ > > We have categorized a lot of comments received in the Expert Review > into more than 40 issues, and reflected the results which we > considered all of issues to the latest version. > While we revised the draft, we received comments from other CFRG > members and the authors of the draft "BLS Signatures", and reflected > them to the latest version. > > If you want to know the details of how to revise, you can check them > by closed issues on the official CFRG GitHub page. > > > https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/issues?q= =3Dis%3Aissue+is%3Aclosed > > Thanks to valuable and constructive comments from Chloe and CFRG > members, our draft became readable and higher quality. > We strongly believe that the draft is ready for RG Last Call. > If there are other necessary procedures for RGLC, could you tell us? > > Best regards, > Yumi > > 2020=E5=B9=B46=E6=9C=889=E6=97=A5(=E7=81=AB) 20:02 Yumi Sakemi : > > > > Dear Chloe > > > > Thank you for your e-mail. > > > > We are very glad to reach a rough consensus with you. > > We believe that our draft became very readable and higher quality by > > reflecting your comments. > > We appreciate your valuable and constructive comments. > > > > We'd like to express our gratitude and include your name in > Acknowledgement. > > The version 05 that is reflected your comments will be submitted today > > or tomorrow, then we will contact you again. > > > > Best regards, > > Yumi > > > > 2020=E5=B9=B46=E6=9C=881=E6=97=A5(=E6=9C=88) 18:53 Chloe Martindale : > > > > > > Dear Yumi, dear all, > > > > > > thank you for the update and for involving me in your thought process > regarding the curve choices. I understand and agree with your reasoning > (and approach) regarding including both BLS12-381 and BN462, however I > think I would make a different 'safer choice'. > > > > > > My reason is this: if the attack is improved further (which you are > completely right, it may), it is very likely to have a bigger impact on > curves constructed via polynomial methods with embedding degree 8 (such a= s > BN462) than on any other curves for this security level, so it's not > unlikely that the security of BN462 would be pushed below 128 bits. A saf= er > choice in my view would be to take the Cocks-Pinch curve (not constructed > using polynomial methods) defined using a 544-bit prime implemented in > RELIC, from [GMT19]*. The TNFS attacks cannot be applied to Cocks-Pinch > curves (at least not without a fundamental new attack idea, since they re= ly > on the polynomial construction), so small improvements will not decrease > the security level at all, and this curve is actually still more efficien= t > than BN462 so there's nothing to lose there. I appreciate that such a > choice would mean also including some background on Cocks-Pinch and a > reference/short explanation of the fact that TNFS attacks don't apply to > these, which would be a major change to the original document, so I > appreciate it if you'd rather not do this, but just thought I'd suggest i= t > as I think it would increase the lifetime of your document. > > > > > > *In your draft this is [GME19], but it should be [GMT19], and can now > be updated to the peer-reviewed version of course (this is the paper I > pointed out in my review). > > > > > > All the best, > > > Chloe > > > > > > On Fri, 29 May 2020 at 16:21, Yumi Sakemi > wrote: > > >> > > >> Dear Chloe > > >> > > >> We appreciate a lot of constructive comments received at Expert > Review. > > >> > > >> We are currently working on updating our draft. > > >> Last week, Nick created a repository for pairing-friendly curves on > > >> CFRG's official GitHub, so we plan to update our draft using the iss= ue > > >> tracker. > > >> The updating for your comments will be made available to you on the > > >> following issue page. > > >> > > >> > https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/issues > > >> > > >> We will contact you again when all the comments have been updated. > > >> In that case, we would be glad if you could check them. > > >> > > >> In addition, before updating, there is a comment that we would like = to > > >> inform you about the policy of update. > > >> The comment is about the recommended curve for 128-bit security leve= l. > > >> > > >> First of all, thank you for teaching us a peer-reviewed paper for > BLS12-381. > > >> The comment is about the recommended curve for 128-bit security leve= l. > > >> Due to our lack of investigation, we made the wrong decision that > > >> BLS12-381 was not matched in our selection policy. > > >> > > >> Your comment pointed out that BLS12-381 is moved to the recommended > > >> curve and BN462 is moved to the Appendix. > > >> We understood the disadvantages of BN462 that you were concerned > > >> about, but we would like to recommend both BLS12-381 and BN462. > > >> The reason is as follows. > > >> > > >> CFRG aims to standardize cryptographic technology for future Interne= t > use. > > >> We agree that BLS12-381 with a 126-bit security level is the best > > >> match as a curve of 128-bit security level "at this time" from the > > >> viewpoint of security and efficiency. > > >> On the other hand, the security of BLS12-381 is already less than > > >> 128bit, so from the viewpoint of future use, if the attack is improv= ed > > >> even a little, it will not be suitable for a curve of 128-bit securi= ty > > >> level. > > >> Considering that the curve of 128-bit security level is often used a= t > current. > > >> So, we would like to recommend both BLS12-381 and BN462 considering > > >> the future use and the safety side. > > >> > > >> However, as you pointed out, BN462 has the disadvantage of being too > > >> slow compared to BLS12-381. > > >> Then, the reader will be confused if there are two parameters of > > >> 128-bit security level, so we will add the basis for selection by > > >> adding the explanation of merits and demerits for each parameter. > > >> And, we will also add a description about the disadvantages of BN462 > > >> regarding efficiency. > > >> > > >> If you have any problems with the updating policy, we would like you > to comment. > > >> > > >> Best regards, > > >> Yumi > > >> > > >> > > >> > > >> > > >> > > >> > > >> 2020=E5=B9=B44=E6=9C=8827=E6=97=A5(=E6=9C=88) 21:58 Yumi Sakemi : > > >> > > > >> > Dear Chloe > > >> > > > >> > I appreciate your review. > > >> > I'm very glad to receive many constructive comments! > > >> > I will discuss about your comments with co-authors and revise our > > >> > draft to reflect your comments in our draft. > > >> > I think it will be a better draft by reflecting your comments. > > >> > > > >> > As co-author Tsunekazu e-mailed, we're planning to submit version > 04, > > >> > because we were independently working on updating of abstract, > > >> > introduction (sec. 1.3) and proofreading of English in parallel wi= th > > >> > the expert review. > > >> > (Version 04 will not be reflected your comments.) > > >> > > > >> > Comments from Chloe will be reflected in the version 05. > > >> > We will submit version 05 in mid-May and we will report you when w= e > > >> > submit version 05. > > >> > > > >> > Dear Stanislav > > >> > > > >> > Thank you very much for proceeding to the Expert review. > > >> > We received a lot of constructive comments from Chloe, so I think = it > > >> > is difficult to manage comments by email. > > >> > (Because there are over 100 comments from Chloe.) > > >> > > > >> > Therefore, I would like to use the issue management function of > GitHub > > >> > so that it is easy to check the reflecting status of Chloe's > comments. > > >> > So, I'd like to use the repository of pairing-friendly curves draf= t > on > > >> > CFRG's GitHub > > >> > because BLS signature which is similar in terms of IRTF stream is > also > > >> > registered on the GitHub. > > >> > Could you register the repository for the draft of pairing-friendl= y > > >> > curves on the following CFRG's GitHub? > > >> > > > >> > https://github.com/cfrg > > >> > > > >> > Best regards, > > >> > Yumi > > >> > > > >> > 2020=E5=B9=B44=E6=9C=8827=E6=97=A5(=E6=9C=88) 10:09 SAITO Tsunekaz= u < > tsunekazu.saito.hg@hco.ntt.co.jp>: > > >> > > > > >> > > Dear Chloe, Stanislav, > > >> > > > > >> > > > > >> > > > > >> > > This is Tsunekazu. > > >> > > > > >> > > > > >> > > > > >> > > We plan to update the draft to version 04 soon. > > >> > > > > >> > > As the contents of the update, we changed the wording of Section > 1.3 and security consideration. > > >> > > > > >> > > Yumi will submit the 4th edition, so please wait a moment. > > >> > > > > >> > > > > >> > > > > >> > > Best regards, > > >> > > > > >> > > Tsunekazu > > >> > > > > >> > > > > >> > > > > >> > > From: Stanislav V. Smyshlyaev > > >> > > Sent: Sunday, April 26, 2020 2:30 PM > > >> > > To: Chloe Martindale ; SAITO > Tsunekazu ; Tetsutaro Kobayashi < > tetsutaro.kobayashi.dr@hco.ntt.co.jp>; Yumi Sakemi < > yumi.sakemi@lepidum.co.jp> > > >> > > Cc: cfrg-chairs@ietf.org; crypto-panel@irtf.org > > >> > > Subject: Re: [Crypto-panel] Request for review: > draft-irtf-cfrg-pairing-friendly-curves-03 > > >> > > > > >> > > > > >> > > > > >> > > Dear Chloe, > > >> > > > > >> > > Many thanks for your review (such a great and a prompt one!). > > >> > > > > >> > > > > >> > > > > >> > > Dear Yumi, Saito, Tetsutaro, do you plan to update your draft > taking into account Chloe=E2=80=99s review? > > >> > > > > >> > > > > >> > > > > >> > > Best regards, > > >> > > > > >> > > Stanislav > > >> > > > > >> > > > > >> > > > > >> > > =D0=BF=D1=82, 24 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 19:49, = Chloe Martindale < > chloemartindale@gmail.com>: > > >> > > > > >> > > Hi all, > > >> > > > > >> > > > > >> > > > > >> > > review is attached. > > >> > > > > >> > > > > >> > > > > >> > > All the best, > > >> > > > > >> > > Chloe > > >> > > > > >> > > > > >> > > > > >> > > On Tue, 21 Apr 2020 at 18:05, Stanislav V. Smyshlyaev < > smyshsv@gmail.com> wrote: > > >> > > > > >> > > Sure - it is > > >> > > > > >> > > > https://tools.ietf.org/html/draft-irtf-cfrg-pairing-friendly-curves-03 > > >> > > > > >> > > > > >> > > > > >> > > Thank you again! > > >> > > > > >> > > > > >> > > > > >> > > Regards, > > >> > > > > >> > > Stanislav > > >> > > > > >> > > > > >> > > > > >> > > =D0=B2=D1=82, 21 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 19:10, = Chloe Martindale < > chloemartindale@gmail.com>: > > >> > > > > >> > > Just to be sure, can you point me towards the most recent versio= n > of the draft please? > > >> > > > > >> > > > > >> > > > > >> > > Thanks, > > >> > > > > >> > > Chloe > > >> > > > > >> > > > > >> > > > > >> > > On Tue, 21 Apr 2020 at 13:17, Stanislav V. Smyshlyaev < > smyshsv@gmail.com> wrote: > > >> > > > > >> > > Great, many thanks, Chloe! > > >> > > > > >> > > > > >> > > > > >> > > Kind regards, > > >> > > > > >> > > Nick, Alexey, Stanislav > > >> > > > > >> > > > > >> > > > > >> > > On Tue, 21 Apr 2020 at 15:16, Chloe Martindale < > chloemartindale@gmail.com> wrote: > > >> > > > > >> > > I'll take a look this week. > > >> > > > > >> > > > > >> > > > > >> > > All the best, > > >> > > > > >> > > Chloe > > >> > > > > >> > > > > >> > > > > >> > > On Tue, 21 Apr 2020, 13:10 Stanislav V. Smyshlyaev, < > smyshsv@gmail.com> wrote: > > >> > > > > >> > > Dear Crypto Panel members, > > >> > > > > >> > > > > >> > > > > >> > > The authors of the Pairing-Friendly Curves draft have addressed > the concerns raised during the discussion and are ready to move to the ne= xt > stage with the draft. > > >> > > > > >> > > > > >> > > > > >> > > Alexey, Nick and I would like to ask Crypto Review Panel members > about the review(s) of draft-irtf-cfrg-pairing-friendly-curves-03. > > >> > > > > >> > > > > >> > > > > >> > > This memo introduces pairing-friendly curves used for > constructing pairing-based cryptography. It describes recommended > parameters for each security level and recent implementations of > pairing-friendly curves. > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > Can we have any volunteers, please?.. > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > > > >> > > Best regards, > > >> > > > > >> > > Stanislav (on behalf of chairs) > > >> > > > > >> > > _______________________________________________ > > >> > > Crypto-panel mailing list > > >> > > Crypto-panel@irtf.org > > >> > > https://www.irtf.org/mailman/listinfo/crypto-panel > > >> > > > >> > > > >> > > > >> > -- > > >> > Yumi Sakemi, Ph. D. > > >> > Lepidum Co. Ltd. > > >> > E-Mail: yumi.sakemi@lepidum.co.jp > > >> > > >> > > >> > > >> -- > > >> Yumi Sakemi, Ph. D. > > >> Lepidum Co. Ltd. > > >> > > >> E-Mail: yumi.sakemi@lepidum.co.jp > > > > > > > > -- > > Yumi Sakemi > > Lepidum Co. Ltd. > > > > E-Mail: yumi.sakemi@lepidum.co.jp > > > > -- > Yumi Sakemi, Ph. D. > Lepidum Co. Ltd. > > E-Mail: yumi.sakemi@lepidum.co.jp > --000000000000ad5e4d05a821ebe3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Dear Yumi, dear all,

thank y= ou for carefully taking my comments into consideration. I am much happier w= ith the draft now! There are a few typos left, see below, and I just had a = couple of comments on the security discussion but these are easily fixed. I= f you fix these small things in my opinion it's ready for RG Last Call.=



Abstract:
Pairing is a special map -&g= t; Pairings are special maps OR A pairing is a special map

1.1
&#= 39;Pairing is a special map' -> 'Pairings are special maps OR A = pairing is a special map'
'importance of pairing' -> '= ;importance of pairings'
'pairing is efficiently computable'= -> 'pairings are efficiently computable'.

1.2
pairin= s -> pairings

1.3
(NSF) -> (NFS)
Barbulescu et. al. ->= ; Barbulescu and Duquesne. (Authors are alphabetical).

2.2
-'= The optimal Ate pairing is considered to be the most efficient to compute i= s the one that is most commonly used for practical implementation.' -&g= t; 'The optimal Ate pairing is considered to be the most efficient to c= ompute and is the one that is most commonly used for practical implementati= on.'
-Choose G_2 or G2 (probably G_2 is easier since there are many = instances also of G_1 and G_T)
-'There also exists cyclic subgroup&#= 39; -> 'There also exists a cyclic subgroup'

2.3
-'= ;b is an element of multiplicative group of order p' -> 'b is a = nonzero element of F_p' OR 'b is an element of a multiplicative gro= up (F_p)^* of order p-1' OR 'b is an element of the multiplicative = group of F_p'
-'embedded degree' -> 'embeddiing degre= e'

2.4
-'r-torsions' -> 'r-torsion'
2.5
-(paragraph 2): of degree d' -> of degree d

4.2
-= This sentence has slightly weird grammar so I don't fully understand wh= at you want to say: 'Therefore, the curve of the 128-bit security level=
=C2=A0 =C2=A0is often used at current, so this memo recommends both BLS= 12-381 and
=C2=A0 =C2=A0BN462 in consideration of the future use and the= safety side.'
Do you mean:
'As curves of 128-bit security le= vel are currently the most widely used, we recommend both BLS12-381 and BN4= 62 in this memo in order to have a more efficient and a more prudent option= respectively.'

4.2.1
-This comment is maybe a bit misleading= :
'We have to note that, according to [BD18], the bit length of p fo= r
=C2=A0 =C2=A0BLS12 to achieve 128-bit security is calculated as 461 bi= ts and more,
=C2=A0 =C2=A0which BLS12_381 does not satisfy.'
The = 461-bit figure in [BD18] is based on a rough estimate which varies a lot be= tween different examples (as is necessary when giving a broad overview). Th= e exact complexity of [BD18]'s attack depends on the specific polynomia= l used to construct the family and can change the complexity of the attack = by up to about 12 bits. The proposed construction of BLS12_381 you refer to= here has been specially chosen to minimize the impact of the exTNFS attack= . It would in my opinion be more precise to say:
'We have= to note that the security level of this pairing is expected to be 126 rath= er than 128 bits [GMT19]'.

4.2.2
-This comment could be more = clearly worded:
'We have to note that the BN462 becomes slower compa= red to BLS12_381,
=C2=A0 =C2=A0although the BN462 is suitable for the pa= rameters of the 128-bit
=C2=A0 =C2=A0security level for the use of the f= uture internet.'
How about instead:
'We have to note that BN4= 62 is significantly slower than BLS12_381,
=C2=A0 =C2=A0but has 134-bit = security level [GMT19],
=C2=A0 =C2=A0so may be more resistant to future= small improvements to the exTNFS attack.'

This would be a good = place to also add a remark along the lines of:
'We note also that CP= 8_544 is more efficient than BN462, has 131-bit security level,
and that= due to its construction will not be affected by future small improvements = to the exTNFS attack. However, as this curve is not widely used (it is only= implemented in one library), we instead chose BN462 for our 'safe'= option.'

5.
-'BLS curves of embedding degree 12 require&= #39; -> 'BLS curves of embedding degree typically require' (cf. = my comment on 4.2.1)

All the best,
Chloe=


On Wed, 10 Jun 2020 at 05:06, Yumi Sakemi <yumi.sakemi@lepidum.co.jp> = wrote:
Dear Alex= ey, Nick, Stanislav, and Chloe

We have submitted the latest version 05 of the draft "Pairing-Friendly= Curves".
https://datatracker.ietf.or= g/doc/draft-irtf-cfrg-pairing-friendly-curves/

We have categorized a lot of comments received in the Expert Review
into more than 40 issues, and reflected the results which we
considered all of issues to the latest version.
While we revised the draft, we received comments from other CFRG
members and the authors of the draft "BLS Signatures", and reflec= ted
them to the latest version.

If you want to know the details of how to revise, you can check them
by closed issues on the official CFRG GitHub page.

htt= ps://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/issues?q=3Dis%= 3Aissue+is%3Aclosed

Thanks to valuable and constructive comments from Chloe and CFRG
members, our draft became readable and higher quality.
We strongly believe that the draft is ready for RG Last Call.
If there are other necessary procedures for RGLC, could you tell us?

Best regards,
Yumi

2020=E5=B9=B46=E6=9C=889=E6=97=A5(=E7=81=AB) 20:02 Yumi Sakemi <yumi.sakemi@lepidum= .co.jp>:
>
> Dear Chloe
>
> Thank you for your e-mail.
>
> We are very glad to reach a rough consensus with you.
> We believe that our draft became very readable and higher quality by > reflecting your comments.
> We appreciate your valuable and constructive comments.
>
> We'd like to express our gratitude and include your name in Acknow= ledgement.
> The version 05 that is reflected your comments will be submitted today=
> or tomorrow, then we will contact you again.
>
> Best regards,
> Yumi
>
> 2020=E5=B9=B46=E6=9C=881=E6=97=A5(=E6=9C=88) 18:53 Chloe Martindale &l= t;chloemarti= ndale@gmail.com>:
> >
> > Dear Yumi, dear all,
> >
> > thank you for the update and for involving me in your thought pro= cess regarding the curve choices. I understand and agree with your reasonin= g (and approach) regarding including both BLS12-381 and BN462, however I th= ink I would make a different 'safer choice'.
> >
> > My reason is this: if the attack is improved further (which you a= re completely right, it may), it is very likely to have a bigger impact on = curves constructed via polynomial methods with embedding degree 8 (such as = BN462) than on any other curves for this security level, so it's not un= likely that the security of BN462 would be pushed below 128 bits. A safer c= hoice in my view would be to take the Cocks-Pinch curve (not constructed us= ing polynomial methods) defined using a 544-bit prime implemented in RELIC,= from [GMT19]*. The TNFS attacks cannot be applied to Cocks-Pinch curves (a= t least not without a fundamental new attack idea, since they rely on the p= olynomial construction), so small improvements will not decrease the securi= ty level at all, and this curve is actually still more efficient than BN462= so there's nothing to lose there. I appreciate that such a choice woul= d mean also including some background on Cocks-Pinch and a reference/short = explanation of the fact that TNFS attacks don't apply to these, which w= ould be a major change to the original document, so I appreciate it if you&= #39;d rather not do this, but just thought I'd suggest it as I think it= would increase the lifetime of your document.
> >
> > *In your draft this is [GME19], but it should be [GMT19], and can= now be updated to the peer-reviewed version of course (this is the paper I= pointed out in my review).
> >
> > All the best,
> > Chloe
> >
> > On Fri, 29 May 2020 at 16:21, Yumi Sakemi <yumi.sakemi@lepidum.co.jp&g= t; wrote:
> >>
> >> Dear Chloe
> >>
> >> We appreciate a lot of constructive comments received at Expe= rt Review.
> >>
> >> We are currently working on updating our draft.
> >> Last week, Nick created a repository for pairing-friendly cur= ves on
> >> CFRG's official GitHub, so we plan to update our draft us= ing the issue
> >> tracker.
> >> The updating for your comments will be made available to you = on the
> >> following issue page.
> >>
> >> https://github.c= om/cfrg/draft-irtf-cfrg-pairing-friendly-curves/issues
> >>
> >> We will contact you again when all the comments have been upd= ated.
> >> In that case, we would be glad if you could check them.
> >>
> >> In addition, before updating, there is a comment that we woul= d like to
> >> inform you about the policy of update.
> >> The comment is about the recommended curve for 128-bit securi= ty level.
> >>
> >> First of all, thank you for teaching us a peer-reviewed paper= for BLS12-381.
> >> The comment is about the recommended curve for 128-bit securi= ty level.
> >> Due to our lack of investigation, we made the wrong decision = that
> >> BLS12-381 was not matched in our selection policy.
> >>
> >> Your comment pointed out that BLS12-381 is moved to the recom= mended
> >> curve and BN462 is moved to the Appendix.
> >> We understood the disadvantages of BN462 that you were concer= ned
> >> about, but we would like to recommend both BLS12-381 and BN46= 2.
> >> The reason is as follows.
> >>
> >> CFRG aims to standardize cryptographic technology for future = Internet use.
> >> We agree that BLS12-381 with a 126-bit security level is the = best
> >> match as a curve of 128-bit security level "at this time= " from the
> >> viewpoint of security and efficiency.
> >> On the other hand, the security of BLS12-381 is already less = than
> >> 128bit, so from the viewpoint of future use, if the attack is= improved
> >> even a little, it will not be suitable for a curve of 128-bit= security
> >> level.
> >> Considering that the curve of 128-bit security level is often= used at current.
> >> So, we would like to recommend both BLS12-381 and BN462 consi= dering
> >> the future use and the safety side.
> >>
> >> However, as you pointed out, BN462 has the disadvantage of be= ing too
> >> slow compared to BLS12-381.
> >> Then, the reader will be confused if there are two parameters= of
> >> 128-bit security level, so we will add the basis for selectio= n by
> >> adding the explanation of merits and demerits for each parame= ter.
> >> And, we will also add a description about the disadvantages o= f BN462
> >> regarding efficiency.
> >>
> >> If you have any problems with the updating policy, we would l= ike you to comment.
> >>
> >> Best regards,
> >> Yumi
> >>
> >>
> >>
> >>
> >>
> >>
> >> 2020=E5=B9=B44=E6=9C=8827=E6=97=A5(=E6=9C=88) 21:58 Yumi Sake= mi <yumi.= sakemi@lepidum.co.jp>:
> >> >
> >> > Dear Chloe
> >> >
> >> > I appreciate your review.
> >> > I'm very glad to receive many constructive comments!=
> >> > I will discuss about your comments with co-authors and r= evise our
> >> > draft to reflect your comments in our draft.
> >> > I think it will be a better draft by reflecting your com= ments.
> >> >
> >> > As co-author Tsunekazu e-mailed, we're=C2=A0 plannin= g to submit version 04,
> >> > because we were independently working on updating of abs= tract,
> >> > introduction (sec. 1.3) and proofreading of English in p= arallel with
> >> > the expert review.
> >> > (Version 04 will not be reflected your comments.)
> >> >
> >> > Comments from Chloe will be reflected in the version 05.=
> >> > We will submit version 05 in mid-May and we will report = you when we
> >> > submit version 05.
> >> >
> >> > Dear Stanislav
> >> >
> >> > Thank you very much for proceeding to the Expert review.=
> >> > We received a lot of constructive comments from Chloe, s= o I think it
> >> > is difficult to manage comments by email.
> >> > (Because there are over 100 comments from Chloe.)
> >> >
> >> > Therefore, I would like to use the issue management func= tion of GitHub
> >> > so that it is easy to check the reflecting status of Chl= oe's comments.
> >> > So, I'd like to use the repository of pairing-friend= ly curves draft on
> >> > CFRG's GitHub
> >> > because BLS signature which is similar in terms of IRTF = stream is also
> >> > registered on the GitHub.
> >> > Could you register the repository for the draft of pairi= ng-friendly
> >> > curves on the following CFRG's GitHub?
> >> >
> >> > https://github.com/cfrg
> >> >
> >> > Best regards,
> >> > Yumi
> >> >
> >> > 2020=E5=B9=B44=E6=9C=8827=E6=97=A5(=E6=9C=88) 10:09 SAIT= O Tsunekazu <tsunekazu.saito.hg@hco.ntt.co.jp>:
> >> > >
> >> > > Dear Chloe, Stanislav,
> >> > >
> >> > >
> >> > >
> >> > > This is Tsunekazu.
> >> > >
> >> > >
> >> > >
> >> > > We plan to update the draft to version 04 soon.
> >> > >
> >> > > As the contents of the update, we changed the wordi= ng of Section 1.3 and security consideration.
> >> > >
> >> > > Yumi will submit the 4th edition, so please wait a = moment.
> >> > >
> >> > >
> >> > >
> >> > > Best regards,
> >> > >
> >> > > Tsunekazu
> >> > >
> >> > >
> >> > >
> >> > > From: Stanislav V. Smyshlyaev <smyshsv@gmail.com>
> >> > > Sent: Sunday, April 26, 2020 2:30 PM
> >> > > To: Chloe Martindale <chloemartindale@gmail.com>; SAI= TO Tsunekazu <tsunekazu.saito.hg@hco.ntt.co.jp>; Tetsutaro Kobayashi &= lt;tetsutaro.kobayashi.dr@hco.ntt.co.jp>; Yumi Sakemi <yumi.sakemi@lepidum.co.= jp>
> >> > > Cc: cfrg-chairs@ietf.org; crypto-panel@irtf.org
> >> > > Subject: Re: [Crypto-panel] Request for review: dra= ft-irtf-cfrg-pairing-friendly-curves-03
> >> > >
> >> > >
> >> > >
> >> > > Dear Chloe,
> >> > >
> >> > > Many thanks for your review (such a great and a pro= mpt one!).
> >> > >
> >> > >
> >> > >
> >> > > Dear Yumi, Saito, Tetsutaro, do you plan to update = your draft taking into account Chloe=E2=80=99s review?
> >> > >
> >> > >
> >> > >
> >> > > Best regards,
> >> > >
> >> > > Stanislav
> >> > >
> >> > >
> >> > >
> >> > > =D0=BF=D1=82, 24 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. = =D0=B2 19:49, Chloe Martindale <chloemartindale@gmail.com>:
> >> > >
> >> > > Hi all,
> >> > >
> >> > >
> >> > >
> >> > > review is attached.
> >> > >
> >> > >
> >> > >
> >> > > All the best,
> >> > >
> >> > > Chloe
> >> > >
> >> > >
> >> > >
> >> > > On Tue, 21 Apr 2020 at 18:05, Stanislav V. Smyshlya= ev <smyshsv@gmail= .com> wrote:
> >> > >
> >> > > Sure - it is
> >> > >
> >> > > https:= //tools.ietf.org/html/draft-irtf-cfrg-pairing-friendly-curves-03
> >> > >
> >> > >
> >> > >
> >> > > Thank you again!
> >> > >
> >> > >
> >> > >
> >> > > Regards,
> >> > >
> >> > > Stanislav
> >> > >
> >> > >
> >> > >
> >> > > =D0=B2=D1=82, 21 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. = =D0=B2 19:10, Chloe Martindale <chloemartindale@gmail.com>:
> >> > >
> >> > > Just to be sure, can you point me towards the most = recent version of the draft please?
> >> > >
> >> > >
> >> > >
> >> > > Thanks,
> >> > >
> >> > > Chloe
> >> > >
> >> > >
> >> > >
> >> > > On Tue, 21 Apr 2020 at 13:17, Stanislav V. Smyshlya= ev <smyshsv@gmail= .com> wrote:
> >> > >
> >> > > Great, many thanks, Chloe!
> >> > >
> >> > >
> >> > >
> >> > > Kind regards,
> >> > >
> >> > > Nick, Alexey, Stanislav
> >> > >
> >> > >
> >> > >
> >> > > On Tue, 21 Apr 2020 at 15:16, Chloe Martindale <= chloemartind= ale@gmail.com> wrote:
> >> > >
> >> > > I'll take a look this week.
> >> > >
> >> > >
> >> > >
> >> > > All the best,
> >> > >
> >> > > Chloe
> >> > >
> >> > >
> >> > >
> >> > > On Tue, 21 Apr 2020, 13:10 Stanislav V. Smyshlyaev,= <smyshsv@gmail.c= om> wrote:
> >> > >
> >> > > Dear Crypto Panel members,
> >> > >
> >> > >
> >> > >
> >> > > The authors of the Pairing-Friendly Curves draft ha= ve addressed the concerns raised during the discussion and are ready to mov= e to the next stage with the draft.
> >> > >
> >> > >
> >> > >
> >> > > Alexey, Nick and I would like to ask Crypto Review = Panel members about the review(s) of draft-irtf-cfrg-pairing-friendly-curve= s-03.
> >> > >
> >> > >
> >> > >
> >> > > This memo introduces pairing-friendly curves used f= or constructing pairing-based cryptography. It describes recommended parame= ters for each security level and recent implementations of pairing-friendly= curves.
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > Can we have any volunteers, please?..
> >> > >
> >> > >
> >> > >
> >> > >
> >> > >
> >> > > Best regards,
> >> > >
> >> > > Stanislav (on behalf of chairs)
> >> > >
> >> > > _______________________________________________
> >> > > Crypto-panel mailing list
> >> > > Crypto-panel@irtf.org
> >> > > https://www.irtf.org/mailm= an/listinfo/crypto-panel
> >> >
> >> >
> >> >
> >> > --
> >> > Yumi Sakemi, Ph. D.
> >> > Lepidum Co. Ltd.
> >> > E-Mail: yumi.sakemi@lepidum.co.jp
> >>
> >>
> >>
> >> --
> >> Yumi Sakemi, Ph. D.
> >> Lepidum Co. Ltd.
> >>
> >> E-Mail: yumi.sakemi@lepidum.co.jp
>
>
>
> --
> Yumi Sakemi
> Lepidum Co. Ltd.
>
> E-Mail: yumi.sakemi@lepidum.co.jp



--
Yumi Sakemi, Ph. D.
Lepidum Co. Ltd.

E-Mail: yumi= .sakemi@lepidum.co.jp
--000000000000ad5e4d05a821ebe3-- From nobody Tue Jun 16 00:09:48 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFD143A097C for ; Tue, 16 Jun 2020 00:09:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.399 X-Spam-Level: X-Spam-Status: No, score=-1.399 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, GB_ABOUTYOU=0.5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=lepidum-co-jp.20150623.gappssmtp.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id wfubg0uDOjb3 for ; Tue, 16 Jun 2020 00:09:44 -0700 (PDT) Received: from mail-lf1-x136.google.com (mail-lf1-x136.google.com [IPv6:2a00:1450:4864:20::136]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 132723A0A02 for ; Tue, 16 Jun 2020 00:09:44 -0700 (PDT) Received: by mail-lf1-x136.google.com with SMTP id c11so727798lfh.8 for ; Tue, 16 Jun 2020 00:09:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=lepidum-co-jp.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=gS7mz+bz9RpI72mh58RWYQ+maqn0Dy5cslcwaNM+aXQ=; b=m0LvM+lupAWlXyG3e2y0OZ0pGWlw+ZfE6a1tWI3+Nrbj0yPkSEK6WI2G+220Rr+xjy aK8++0Kh83xMk+/sN0+DkZcdZQkjKdtUlzn5ImICBxAyBglkEzWOjqOMY5H1m6noYojG Ar8yNxZ4d7eQgAJjKoAL4oKMMMhUJw/+R3KS9lFyqlJvhGXqrsc5n3VTxYELTkvAK0V3 UygHmAnB18ry3bp1ONyQQzOHqpQp9+bZJoLuPDBmI+TCW376cVgiiHK5GrNeojexUree biEvMPJsjBW37uotTj0L8xBqHIGz7ViDVna7q+vtu3cEklq8k1iKsipzDfYRi9MzlxMu dvlQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=gS7mz+bz9RpI72mh58RWYQ+maqn0Dy5cslcwaNM+aXQ=; b=cWxgoMp29Lz8fm5nC+CjdmMu9exbj9wU41eelwuVgjAqRKpDwrMz9bBNSpAOJxyT95 ccW6D2gPVZK1LVGAU9j7ZIGMsPz1wrAB9w4w6gQR84RW+nF/73R1MRYOO/MXAANYdupO vYSNj1XudyifSszI/k4cozLfH5QBlOUcqOp/1RGxChvvV+pDe7dc56rwOi648+yrrRri gnMYEvZFsib+r5sunjH/+9zn3OHYbAkoEQ8BwgSfXQ3MJEngbq3Nfs0n7nYzE4oV5Yai fskJYDm71lzoGaX5lUgw8qyQGFid8cTbwT/FpdnSIk5TfRy1defKp/kTD/t2UhmNx58+ EbEA== X-Gm-Message-State: AOAM531WMHJgvyjx8ax357K7wfVrZfvI5CdGsAxL8Jm0817HqTrhvuO3 WX6GRSaIFzCpZQzLPMYio5bmMqfbvV/afzXsVOP3VW66IM4= X-Google-Smtp-Source: ABdhPJyqQGOS+BzF6Ybfp7v2Xc218s5NHQUJ1AjBtw02CS2el5CB149dyoeSXSIIjI2Si0HzFsz2zXv/sb1TjgVSY54= X-Received: by 2002:ac2:46cc:: with SMTP id p12mr956055lfo.211.1592291381834; Tue, 16 Jun 2020 00:09:41 -0700 (PDT) MIME-Version: 1.0 References: <002201d61c30$4f561da0$ee0258e0$@hco.ntt.co.jp_1> In-Reply-To: From: Yumi Sakemi Date: Tue, 16 Jun 2020 16:09:30 +0900 Message-ID: To: Chloe Martindale Cc: crypto-panel@irtf.org, cfrg-chairs@ietf.org, Tetsutaro Kobayashi , SAITO Tsunekazu Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Archived-At: Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-pairing-friendly-curves-03 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 07:09:47 -0000 Dear Chloe, Alexey, Nick, and Stanislav We are very grateful to you for your useful comments. We submitted the version 06 of the draft "Pairing-Friendly Curves". We have categorized your comments into 7 issues and reflected the content of all issues in the version 06. These correspond to issues #49 to #55. You can check how to modify on the following GitHub page. https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/issues?q=3D= is%3Aissue+is%3Aclosed Dear CFRG chairs We believe that we were able to complete the remaining issues up to RG Last Call, which we received from Chloe. Could you please consider starting RG Last Call? Best regards, Yumi 2020=E5=B9=B46=E6=9C=8816=E6=97=A5(=E7=81=AB) 1:28 Chloe Martindale : > > Dear Yumi, dear all, > > thank you for carefully taking my comments into consideration. I am much = happier with the draft now! There are a few typos left, see below, and I ju= st had a couple of comments on the security discussion but these are easily= fixed. If you fix these small things in my opinion it's ready for RG Last = Call. > > > > Abstract: > Pairing is a special map -> Pairings are special maps OR A pairing is a s= pecial map > > 1.1 > 'Pairing is a special map' -> 'Pairings are special maps OR A pairing is = a special map' > 'importance of pairing' -> 'importance of pairings' > 'pairing is efficiently computable' -> 'pairings are efficiently computab= le'. > > 1.2 > pairins -> pairings > > 1.3 > (NSF) -> (NFS) > Barbulescu et. al. -> Barbulescu and Duquesne. (Authors are alphabetical)= . > > 2.2 > -'The optimal Ate pairing is considered to be the most efficient to compu= te is the one that is most commonly used for practical implementation.' -> = 'The optimal Ate pairing is considered to be the most efficient to compute = and is the one that is most commonly used for practical implementation.' > -Choose G_2 or G2 (probably G_2 is easier since there are many instances = also of G_1 and G_T) > -'There also exists cyclic subgroup' -> 'There also exists a cyclic subgr= oup' > > 2.3 > -'b is an element of multiplicative group of order p' -> 'b is a nonzero = element of F_p' OR 'b is an element of a multiplicative group (F_p)^* of or= der p-1' OR 'b is an element of the multiplicative group of F_p' > -'embedded degree' -> 'embeddiing degree' > > 2.4 > -'r-torsions' -> 'r-torsion' > > 2.5 > -(paragraph 2): of degree d' -> of degree d > > 4.2 > -This sentence has slightly weird grammar so I don't fully understand wha= t you want to say: 'Therefore, the curve of the 128-bit security level > is often used at current, so this memo recommends both BLS12-381 and > BN462 in consideration of the future use and the safety side.' > Do you mean: > 'As curves of 128-bit security level are currently the most widely used, = we recommend both BLS12-381 and BN462 in this memo in order to have a more = efficient and a more prudent option respectively.' > > 4.2.1 > -This comment is maybe a bit misleading: > 'We have to note that, according to [BD18], the bit length of p for > BLS12 to achieve 128-bit security is calculated as 461 bits and more, > which BLS12_381 does not satisfy.' > The 461-bit figure in [BD18] is based on a rough estimate which varies a = lot between different examples (as is necessary when giving a broad overvie= w). The exact complexity of [BD18]'s attack depends on the specific polynom= ial used to construct the family and can change the complexity of the attac= k by up to about 12 bits. The proposed construction of BLS12_381 you refer = to here has been specially chosen to minimize the impact of the exTNFS atta= ck. It would in my opinion be more precise to say: > 'We have to note that the security level of this pairing is expected to b= e 126 rather than 128 bits [GMT19]'. > > 4.2.2 > -This comment could be more clearly worded: > 'We have to note that the BN462 becomes slower compared to BLS12_381, > although the BN462 is suitable for the parameters of the 128-bit > security level for the use of the future internet.' > How about instead: > 'We have to note that BN462 is significantly slower than BLS12_381, > but has 134-bit security level [GMT19], > so may be more resistant to future small improvements to the exTNFS at= tack.' > > This would be a good place to also add a remark along the lines of: > 'We note also that CP8_544 is more efficient than BN462, has 131-bit secu= rity level, > and that due to its construction will not be affected by future small imp= rovements to the exTNFS attack. However, as this curve is not widely used (= it is only implemented in one library), we instead chose BN462 for our 'saf= e' option.' > > 5. > -'BLS curves of embedding degree 12 require' -> 'BLS curves of embedding = degree typically require' (cf. my comment on 4.2.1) > > All the best, > Chloe > > > On Wed, 10 Jun 2020 at 05:06, Yumi Sakemi wro= te: >> >> Dear Alexey, Nick, Stanislav, and Chloe >> >> We have submitted the latest version 05 of the draft "Pairing-Friendly C= urves". >> https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves= / >> >> We have categorized a lot of comments received in the Expert Review >> into more than 40 issues, and reflected the results which we >> considered all of issues to the latest version. >> While we revised the draft, we received comments from other CFRG >> members and the authors of the draft "BLS Signatures", and reflected >> them to the latest version. >> >> If you want to know the details of how to revise, you can check them >> by closed issues on the official CFRG GitHub page. >> >> https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/issues?q= =3Dis%3Aissue+is%3Aclosed >> >> Thanks to valuable and constructive comments from Chloe and CFRG >> members, our draft became readable and higher quality. >> We strongly believe that the draft is ready for RG Last Call. >> If there are other necessary procedures for RGLC, could you tell us? >> >> Best regards, >> Yumi >> >> 2020=E5=B9=B46=E6=9C=889=E6=97=A5(=E7=81=AB) 20:02 Yumi Sakemi : >> > >> > Dear Chloe >> > >> > Thank you for your e-mail. >> > >> > We are very glad to reach a rough consensus with you. >> > We believe that our draft became very readable and higher quality by >> > reflecting your comments. >> > We appreciate your valuable and constructive comments. >> > >> > We'd like to express our gratitude and include your name in Acknowledg= ement. >> > The version 05 that is reflected your comments will be submitted today >> > or tomorrow, then we will contact you again. >> > >> > Best regards, >> > Yumi >> > >> > 2020=E5=B9=B46=E6=9C=881=E6=97=A5(=E6=9C=88) 18:53 Chloe Martindale : >> > > >> > > Dear Yumi, dear all, >> > > >> > > thank you for the update and for involving me in your thought proces= s regarding the curve choices. I understand and agree with your reasoning (= and approach) regarding including both BLS12-381 and BN462, however I think= I would make a different 'safer choice'. >> > > >> > > My reason is this: if the attack is improved further (which you are = completely right, it may), it is very likely to have a bigger impact on cur= ves constructed via polynomial methods with embedding degree 8 (such as BN4= 62) than on any other curves for this security level, so it's not unlikely = that the security of BN462 would be pushed below 128 bits. A safer choice i= n my view would be to take the Cocks-Pinch curve (not constructed using pol= ynomial methods) defined using a 544-bit prime implemented in RELIC, from [= GMT19]*. The TNFS attacks cannot be applied to Cocks-Pinch curves (at least= not without a fundamental new attack idea, since they rely on the polynomi= al construction), so small improvements will not decrease the security leve= l at all, and this curve is actually still more efficient than BN462 so the= re's nothing to lose there. I appreciate that such a choice would mean also= including some background on Cocks-Pinch and a reference/short explanation= of the fact that TNFS attacks don't apply to these, which would be a major= change to the original document, so I appreciate it if you'd rather not do= this, but just thought I'd suggest it as I think it would increase the lif= etime of your document. >> > > >> > > *In your draft this is [GME19], but it should be [GMT19], and can no= w be updated to the peer-reviewed version of course (this is the paper I po= inted out in my review). >> > > >> > > All the best, >> > > Chloe >> > > >> > > On Fri, 29 May 2020 at 16:21, Yumi Sakemi wrote: >> > >> >> > >> Dear Chloe >> > >> >> > >> We appreciate a lot of constructive comments received at Expert Rev= iew. >> > >> >> > >> We are currently working on updating our draft. >> > >> Last week, Nick created a repository for pairing-friendly curves on >> > >> CFRG's official GitHub, so we plan to update our draft using the is= sue >> > >> tracker. >> > >> The updating for your comments will be made available to you on the >> > >> following issue page. >> > >> >> > >> https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/iss= ues >> > >> >> > >> We will contact you again when all the comments have been updated. >> > >> In that case, we would be glad if you could check them. >> > >> >> > >> In addition, before updating, there is a comment that we would like= to >> > >> inform you about the policy of update. >> > >> The comment is about the recommended curve for 128-bit security lev= el. >> > >> >> > >> First of all, thank you for teaching us a peer-reviewed paper for B= LS12-381. >> > >> The comment is about the recommended curve for 128-bit security lev= el. >> > >> Due to our lack of investigation, we made the wrong decision that >> > >> BLS12-381 was not matched in our selection policy. >> > >> >> > >> Your comment pointed out that BLS12-381 is moved to the recommended >> > >> curve and BN462 is moved to the Appendix. >> > >> We understood the disadvantages of BN462 that you were concerned >> > >> about, but we would like to recommend both BLS12-381 and BN462. >> > >> The reason is as follows. >> > >> >> > >> CFRG aims to standardize cryptographic technology for future Intern= et use. >> > >> We agree that BLS12-381 with a 126-bit security level is the best >> > >> match as a curve of 128-bit security level "at this time" from the >> > >> viewpoint of security and efficiency. >> > >> On the other hand, the security of BLS12-381 is already less than >> > >> 128bit, so from the viewpoint of future use, if the attack is impro= ved >> > >> even a little, it will not be suitable for a curve of 128-bit secur= ity >> > >> level. >> > >> Considering that the curve of 128-bit security level is often used = at current. >> > >> So, we would like to recommend both BLS12-381 and BN462 considering >> > >> the future use and the safety side. >> > >> >> > >> However, as you pointed out, BN462 has the disadvantage of being to= o >> > >> slow compared to BLS12-381. >> > >> Then, the reader will be confused if there are two parameters of >> > >> 128-bit security level, so we will add the basis for selection by >> > >> adding the explanation of merits and demerits for each parameter. >> > >> And, we will also add a description about the disadvantages of BN46= 2 >> > >> regarding efficiency. >> > >> >> > >> If you have any problems with the updating policy, we would like yo= u to comment. >> > >> >> > >> Best regards, >> > >> Yumi >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> >> > >> 2020=E5=B9=B44=E6=9C=8827=E6=97=A5(=E6=9C=88) 21:58 Yumi Sakemi : >> > >> > >> > >> > Dear Chloe >> > >> > >> > >> > I appreciate your review. >> > >> > I'm very glad to receive many constructive comments! >> > >> > I will discuss about your comments with co-authors and revise our >> > >> > draft to reflect your comments in our draft. >> > >> > I think it will be a better draft by reflecting your comments. >> > >> > >> > >> > As co-author Tsunekazu e-mailed, we're planning to submit versio= n 04, >> > >> > because we were independently working on updating of abstract, >> > >> > introduction (sec. 1.3) and proofreading of English in parallel w= ith >> > >> > the expert review. >> > >> > (Version 04 will not be reflected your comments.) >> > >> > >> > >> > Comments from Chloe will be reflected in the version 05. >> > >> > We will submit version 05 in mid-May and we will report you when = we >> > >> > submit version 05. >> > >> > >> > >> > Dear Stanislav >> > >> > >> > >> > Thank you very much for proceeding to the Expert review. >> > >> > We received a lot of constructive comments from Chloe, so I think= it >> > >> > is difficult to manage comments by email. >> > >> > (Because there are over 100 comments from Chloe.) >> > >> > >> > >> > Therefore, I would like to use the issue management function of G= itHub >> > >> > so that it is easy to check the reflecting status of Chloe's comm= ents. >> > >> > So, I'd like to use the repository of pairing-friendly curves dra= ft on >> > >> > CFRG's GitHub >> > >> > because BLS signature which is similar in terms of IRTF stream is= also >> > >> > registered on the GitHub. >> > >> > Could you register the repository for the draft of pairing-friend= ly >> > >> > curves on the following CFRG's GitHub? >> > >> > >> > >> > https://github.com/cfrg >> > >> > >> > >> > Best regards, >> > >> > Yumi >> > >> > >> > >> > 2020=E5=B9=B44=E6=9C=8827=E6=97=A5(=E6=9C=88) 10:09 SAITO Tsuneka= zu : >> > >> > > >> > >> > > Dear Chloe, Stanislav, >> > >> > > >> > >> > > >> > >> > > >> > >> > > This is Tsunekazu. >> > >> > > >> > >> > > >> > >> > > >> > >> > > We plan to update the draft to version 04 soon. >> > >> > > >> > >> > > As the contents of the update, we changed the wording of Sectio= n 1.3 and security consideration. >> > >> > > >> > >> > > Yumi will submit the 4th edition, so please wait a moment. >> > >> > > >> > >> > > >> > >> > > >> > >> > > Best regards, >> > >> > > >> > >> > > Tsunekazu >> > >> > > >> > >> > > >> > >> > > >> > >> > > From: Stanislav V. Smyshlyaev >> > >> > > Sent: Sunday, April 26, 2020 2:30 PM >> > >> > > To: Chloe Martindale ; SAITO Tsuneka= zu ; Tetsutaro Kobayashi ; Yumi Sakemi >> > >> > > Cc: cfrg-chairs@ietf.org; crypto-panel@irtf.org >> > >> > > Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg= -pairing-friendly-curves-03 >> > >> > > >> > >> > > >> > >> > > >> > >> > > Dear Chloe, >> > >> > > >> > >> > > Many thanks for your review (such a great and a prompt one!). >> > >> > > >> > >> > > >> > >> > > >> > >> > > Dear Yumi, Saito, Tetsutaro, do you plan to update your draft t= aking into account Chloe=E2=80=99s review? >> > >> > > >> > >> > > >> > >> > > >> > >> > > Best regards, >> > >> > > >> > >> > > Stanislav >> > >> > > >> > >> > > >> > >> > > >> > >> > > =D0=BF=D1=82, 24 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 19:49,= Chloe Martindale : >> > >> > > >> > >> > > Hi all, >> > >> > > >> > >> > > >> > >> > > >> > >> > > review is attached. >> > >> > > >> > >> > > >> > >> > > >> > >> > > All the best, >> > >> > > >> > >> > > Chloe >> > >> > > >> > >> > > >> > >> > > >> > >> > > On Tue, 21 Apr 2020 at 18:05, Stanislav V. Smyshlyaev wrote: >> > >> > > >> > >> > > Sure - it is >> > >> > > >> > >> > > https://tools.ietf.org/html/draft-irtf-cfrg-pairing-friendly-cu= rves-03 >> > >> > > >> > >> > > >> > >> > > >> > >> > > Thank you again! >> > >> > > >> > >> > > >> > >> > > >> > >> > > Regards, >> > >> > > >> > >> > > Stanislav >> > >> > > >> > >> > > >> > >> > > >> > >> > > =D0=B2=D1=82, 21 =D0=B0=D0=BF=D1=80. 2020 =D0=B3. =D0=B2 19:10,= Chloe Martindale : >> > >> > > >> > >> > > Just to be sure, can you point me towards the most recent versi= on of the draft please? >> > >> > > >> > >> > > >> > >> > > >> > >> > > Thanks, >> > >> > > >> > >> > > Chloe >> > >> > > >> > >> > > >> > >> > > >> > >> > > On Tue, 21 Apr 2020 at 13:17, Stanislav V. Smyshlyaev wrote: >> > >> > > >> > >> > > Great, many thanks, Chloe! >> > >> > > >> > >> > > >> > >> > > >> > >> > > Kind regards, >> > >> > > >> > >> > > Nick, Alexey, Stanislav >> > >> > > >> > >> > > >> > >> > > >> > >> > > On Tue, 21 Apr 2020 at 15:16, Chloe Martindale wrote: >> > >> > > >> > >> > > I'll take a look this week. >> > >> > > >> > >> > > >> > >> > > >> > >> > > All the best, >> > >> > > >> > >> > > Chloe >> > >> > > >> > >> > > >> > >> > > >> > >> > > On Tue, 21 Apr 2020, 13:10 Stanislav V. Smyshlyaev, wrote: >> > >> > > >> > >> > > Dear Crypto Panel members, >> > >> > > >> > >> > > >> > >> > > >> > >> > > The authors of the Pairing-Friendly Curves draft have addressed= the concerns raised during the discussion and are ready to move to the nex= t stage with the draft. >> > >> > > >> > >> > > >> > >> > > >> > >> > > Alexey, Nick and I would like to ask Crypto Review Panel member= s about the review(s) of draft-irtf-cfrg-pairing-friendly-curves-03. >> > >> > > >> > >> > > >> > >> > > >> > >> > > This memo introduces pairing-friendly curves used for construct= ing pairing-based cryptography. It describes recommended parameters for eac= h security level and recent implementations of pairing-friendly curves. >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > Can we have any volunteers, please?.. >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > >> > >> > > Best regards, >> > >> > > >> > >> > > Stanislav (on behalf of chairs) >> > >> > > >> > >> > > _______________________________________________ >> > >> > > Crypto-panel mailing list >> > >> > > Crypto-panel@irtf.org >> > >> > > https://www.irtf.org/mailman/listinfo/crypto-panel >> > >> > >> > >> > >> > >> > >> > >> > -- >> > >> > Yumi Sakemi, Ph. D. >> > >> > Lepidum Co. Ltd. >> > >> > E-Mail: yumi.sakemi@lepidum.co.jp >> > >> >> > >> >> > >> >> > >> -- >> > >> Yumi Sakemi, Ph. D. >> > >> Lepidum Co. Ltd. >> > >> >> > >> E-Mail: yumi.sakemi@lepidum.co.jp >> > >> > >> > >> > -- >> > Yumi Sakemi >> > Lepidum Co. Ltd. >> > >> > E-Mail: yumi.sakemi@lepidum.co.jp >> >> >> >> -- >> Yumi Sakemi, Ph. D. >> Lepidum Co. Ltd. >> >> E-Mail: yumi.sakemi@lepidum.co.jp --=20 Yumi Sakemi, Ph. D. Lepidum Co. Ltd. E-Mail: yumi.sakemi@lepidum.co.jp From nobody Tue Jun 16 15:57:14 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E25523A0A01 for ; Tue, 16 Jun 2020 15:57:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cloudflare.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P40wxG1YOvY7 for ; Tue, 16 Jun 2020 15:57:11 -0700 (PDT) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C1563A0A03 for ; Tue, 16 Jun 2020 15:57:11 -0700 (PDT) Received: by mail-ua1-x934.google.com with SMTP id a10so122389uan.8 for ; Tue, 16 Jun 2020 15:57:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cloudflare.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=y1PJR4g6WuCyNM6KVdw0syFdeyFHI72Zegtu7c4op8Y=; b=xDTmFhMK2AA8w5IKafdO3suEFRcqSpBIifOSL1oMDkKcjea4/HzuEtrJmsdJzNLXpf HvuwxQBPNeX5gVV/a0bZgZkyWoLhGcXnLKFdqBtc3qEi35p0lAVmySloX6+WNkmhUkzG 9j0LWloqoaf9emqCiNb6zM2aw/Gq/S7FC2G1Q= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=y1PJR4g6WuCyNM6KVdw0syFdeyFHI72Zegtu7c4op8Y=; b=q+mBBOroPgU2BcadXmYoH63zDSVXGgtB6NZLYkePyJtahNwzgInqWcpI7ZoEyj2ohc xvW81w4D3lzoABdQsgRl+Q6cTzfTPXeSq8//FvhQTRBGQwzhro0Ucgxu2WF+pD20RjO6 dEVKPkkcICouNo2zonaYjRDKR7Hx7Xu0Kn45/DSUBzxQ95MotNlt/ioQdTXEWLJ5Acvb GyVz4i5N1TW073rssdIv5AtUn6OI/bW3w2EM4R34PqlbiXPyPmGlVtbBnlhFQxeGfqIA 0N3i2BfsAjknQrWfBdxXm3ogHQsYQuZc4J2ougogq6iq9NScZKusuVI8uifxk3vnhp2C ZzSg== X-Gm-Message-State: AOAM533LKHi5xCeBrpj/7Zvc4wofAXam+1F5ahJUGfXEm8cs0r9XaraR svMp0Sao/zqT5Cm6FUCTXykSO84gR0N8KCvj8NvkYw== X-Google-Smtp-Source: ABdhPJyt/kebkCWwnhk2nOKNsxawhHxBnw4iUuGDb4iMPo/4UjoCvbOapWa6yBLceyiYvuqIQSLfkd2qShVI/wG9jDo= X-Received: by 2002:ab0:b13:: with SMTP id b19mr3665671uak.55.1592348230086; Tue, 16 Jun 2020 15:57:10 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Nick Sullivan Date: Tue, 16 Jun 2020 15:56:53 -0700 Message-ID: To: Stephen Farrell Cc: Nick Sullivan , crypto-panel@irtf.org, draft-irtf-cfrg-hpke@ietf.org, cfrg-chairs@ietf.org Content-Type: multipart/alternative; boundary="0000000000009d215805a83b764b" Archived-At: Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-hpke-04 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 22:57:13 -0000 --0000000000009d215805a83b764b Content-Type: text/plain; charset="UTF-8" Hi Stephen, This works for us. We look forward to your review. Nick (on behalf of the chairs) On Mon, Jun 8, 2020 at 2:57 PM Stephen Farrell wrote: > > I've implemented an earlier version [1] and will be > coding up the final one. Happy to do it, or for that > to be considered disqualifying:-) > > Cheers, > S. > > [1] https://github.com/sftcd/happykey > > On 08/06/2020 22:53, Nick Sullivan wrote: > > Dear Crypto Panel members, > > > > Alexey, Stanislav and I would like to ask Crypto Review Panel members > for a > > review of https://www.ietf.org/id/draft-irtf-cfrg-hpke-04.html. The > > document specifies a set of mechanisms to do hybrid public key > encryption. > > It can be thought of as a generalization of ECIES for any KEM. > > > > This document went through last call and didn't receive many comments, > so a > > thorough review from a crypto panel member would be helpful to move this > > document forward. > > > > Who would like to volunteer? > > > > Best regards, > > Nick (on behalf of chairs) > > > > > > _______________________________________________ > > Crypto-panel mailing list > > Crypto-panel@irtf.org > > https://www.irtf.org/mailman/listinfo/crypto-panel > > > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > --0000000000009d215805a83b764b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Stephen,

This works for us. We look = forward to your review.

Nick (on behalf of the cha= irs)

On Mon, Jun 8, 2020 at 2:57 PM Stephen Farrell <stephen.farrell@cs.tcd.ie> wrote:
=

I've implemented an earlier version [1] and will be
coding up the final one. Happy to do it, or for that
to be considered disqualifying:-)

Cheers,
S.

[1] https://github.com/sftcd/happykey

On 08/06/2020 22:53, Nick Sullivan wrote:
> Dear Crypto Panel members,
>
> Alexey, Stanislav and I would like to ask Crypto Review Panel members = for a
> review of https://www.ietf.org/id/draft-irt= f-cfrg-hpke-04.html. The
> document specifies a set of mechanisms to do hybrid public key encrypt= ion.
> It can be thought of as a generalization of ECIES for any KEM.
>
> This document went through last call and didn't receive many comme= nts, so a
> thorough review from a crypto panel member would be helpful to move th= is
> document forward.
>
> Who would like to volunteer?
>
> Best regards,
> Nick (on behalf of chairs)
>
>
> _______________________________________________
> Crypto-panel mailing list
> Crypto-pane= l@irtf.org
> https://www.irtf.org/mailman/listinfo/crypto-= panel
>
_______________________________________________
Crypto-panel mailing list
Crypto-panel@irt= f.org
https://www.irtf.org/mailman/listinfo/crypto-panel=
--0000000000009d215805a83b764b-- From nobody Tue Jun 16 23:16:55 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D758F3A0F00 for ; Tue, 16 Jun 2020 23:16:52 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ypLXMfiPQWW0 for ; Tue, 16 Jun 2020 23:16:51 -0700 (PDT) Received: from mail-wm1-x343.google.com (mail-wm1-x343.google.com [IPv6:2a00:1450:4864:20::343]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3D01C3A0F03 for ; Tue, 16 Jun 2020 23:16:51 -0700 (PDT) Received: by mail-wm1-x343.google.com with SMTP id f185so672403wmf.3 for ; Tue, 16 Jun 2020 23:16:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ye5IwnFmlxlNfwHSAy4vTziYBYU5leQc3Tqh8pKviQ8=; b=aB4bHW0QBee5VTJxFr+yHGoBEuSuqJK40kRLCzy7arZsIKb0YyeBypt3GROYYVekko jQJvjiP91sluvMxiw6L5K5ZARlSMdOWbgLLPka3iBarbDrRYEKlCgVIMqnBPSAdVmFMj zlS4mUjNyPWpAKvFPPWIJas8MCfHfSx3bFrFuADSEfxJBd6SVh3QnlWaAg+ThPx23rCV qwf68Wi1kBv9fuh+YUSOFRhGANQcNBOk6stKTTvNGcGniAMlSHvMjEfT9BRG4gsVbE27 ZiPgLjTgWx62J8b5trQ/Qfh3i5HNnazkBTAEstwwxUygZVuidvjOMuupkMBPXfep5TcM pxxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ye5IwnFmlxlNfwHSAy4vTziYBYU5leQc3Tqh8pKviQ8=; b=ghkPhv7YeYrL9zSAXdMYDC9iuCgj5m1BzODfuGnu6D3yswvkZ0oS7TU9GJIaSc5MFu zmKter1aV3bCzmCmlf9gUXuT03hz/AaouQ0a5F1KOWt4UXFmbECnd5kqIKkkUy2ekxqv OiTA8YQMmIZyXKaBrHxldbEauo4XbTSChFmM3KEZn+tgdQn4sQtJgGfTIjP78UNn3Pg8 U3nrMIjSN2NK8gXlgm5p7c59KWR8JixgGUSvdjSoTI7f+xZT9s///zrAaV+kglso58gV 4L+qrvGhPopulRoFcDlGovS9zarnCvf7JpyM6dbGc6ezRMEtAZmAeKMUtpHN2IObjQVD NV9g== X-Gm-Message-State: AOAM532owLO3y5xFnNbxiQg1YWjWxoBbl8sIznrgAS+qVi1s0cShnoVU 8SelXJLC8TMk71RgOLWgmc7P9cE+Kl4GFoykWYc= X-Google-Smtp-Source: ABdhPJzJV7RIJcjhwl9hoRLIyB6JnmwR05928vX5goZ1nR9fYnLm68GaQ/Ej6oOBfebvJTl1OJDuwsLelOxrlrU7hBY= X-Received: by 2002:a1c:3c1:: with SMTP id 184mr6560267wmd.40.1592374609527; Tue, 16 Jun 2020 23:16:49 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Jean-Philippe Aumasson Date: Wed, 17 Jun 2020 08:16:38 +0200 Message-ID: To: Nick Sullivan Cc: Stephen Farrell , crypto-panel@irtf.org, draft-irtf-cfrg-hpke@ietf.org, cfrg-chairs@ietf.org, christopherwood07@gmail.com, Frederic Jacobs Content-Type: multipart/alternative; boundary="000000000000f3491105a8419a4b" Archived-At: Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-hpke-04 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Jun 2020 06:16:53 -0000 --000000000000f3491105a8419a4b Content-Type: text/plain; charset="UTF-8" Hi, I wrote this review a few days ago after Chris and Fred contacted me: https://gist.github.com/veorq/76196fde31390a8696eac7e062c7b2ea Cheers,, JP On Wed, Jun 17, 2020 at 12:57 AM Nick Sullivan wrote: > Hi Stephen, > > This works for us. We look forward to your review. > > Nick (on behalf of the chairs) > > On Mon, Jun 8, 2020 at 2:57 PM Stephen Farrell > wrote: > >> >> I've implemented an earlier version [1] and will be >> coding up the final one. Happy to do it, or for that >> to be considered disqualifying:-) >> >> Cheers, >> S. >> >> [1] https://github.com/sftcd/happykey >> >> On 08/06/2020 22:53, Nick Sullivan wrote: >> > Dear Crypto Panel members, >> > >> > Alexey, Stanislav and I would like to ask Crypto Review Panel members >> for a >> > review of https://www.ietf.org/id/draft-irtf-cfrg-hpke-04.html. The >> > document specifies a set of mechanisms to do hybrid public key >> encryption. >> > It can be thought of as a generalization of ECIES for any KEM. >> > >> > This document went through last call and didn't receive many comments, >> so a >> > thorough review from a crypto panel member would be helpful to move this >> > document forward. >> > >> > Who would like to volunteer? >> > >> > Best regards, >> > Nick (on behalf of chairs) >> > >> > >> > _______________________________________________ >> > Crypto-panel mailing list >> > Crypto-panel@irtf.org >> > https://www.irtf.org/mailman/listinfo/crypto-panel >> > >> _______________________________________________ >> Crypto-panel mailing list >> Crypto-panel@irtf.org >> https://www.irtf.org/mailman/listinfo/crypto-panel >> > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > --000000000000f3491105a8419a4b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi,

I wrote this review a few days ago after = Chris and Fred contacted me:


=
Cheers,,

JP

<= /div>

On Wed, Jun 17, 2020 at 12:57 AM Nick Sullivan <nick=3D40cloudflare.com@dmarc.ietf.org&= gt; wrote:
Hi Stephen,

This works for us. We look forwa= rd to your review.

Nick (on behalf of the chairs)<= /div>

On Mon, Jun 8, 2020 at 2:57 PM Stephen Farrell <stephen.farrell@cs.tcd.ie&g= t; wrote:

I've implemented an earlier version [1] and will be
coding up the final one. Happy to do it, or for that
to be considered disqualifying:-)

Cheers,
S.

[1] https://github.com/sftcd/happykey

On 08/06/2020 22:53, Nick Sullivan wrote:
> Dear Crypto Panel members,
>
> Alexey, Stanislav and I would like to ask Crypto Review Panel members = for a
> review of https://www.ietf.org/id/draft-irt= f-cfrg-hpke-04.html. The
> document specifies a set of mechanisms to do hybrid public key encrypt= ion.
> It can be thought of as a generalization of ECIES for any KEM.
>
> This document went through last call and didn't receive many comme= nts, so a
> thorough review from a crypto panel member would be helpful to move th= is
> document forward.
>
> Who would like to volunteer?
>
> Best regards,
> Nick (on behalf of chairs)
>
>
> _______________________________________________
> Crypto-panel mailing list
> Crypto-pane= l@irtf.org
> https://www.irtf.org/mailman/listinfo/crypto-= panel
>
_______________________________________________
Crypto-panel mailing list
Crypto-panel@irt= f.org
https://www.irtf.org/mailman/listinfo/crypto-panel=
_______________________________________________
Crypto-panel mailing list
Crypto-panel@irt= f.org
https://www.irtf.org/mailman/listinfo/crypto-panel=
--000000000000f3491105a8419a4b-- From nobody Fri Jun 19 08:42:27 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 956E03A0AF4 for ; Fri, 19 Jun 2020 08:42:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fJLKAFbKtbWL for ; Fri, 19 Jun 2020 08:42:25 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 6CF5D3A0AF3 for ; Fri, 19 Jun 2020 08:42:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1592581344; d=isode.com; s=june2016; i=@isode.com; bh=vl4mhF5khwqUv5JQVTyifaFOvarRQdMnc2ZC9V5dl/U=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=HshQ9bt5NN6UbV8wfU7/+1hAJMy4FQBIeG6VGVWaSX6oReWse1fYvQ8M3X0I/OKZlshb7Z 21KPIRh+eHpt1NHbdxmw/5emDrVXfphLpbo0Zb/RW70OUZBwWEd7jnQIiGR7TVJ98raFor zQYnn8A+rMHiZbVVqXfC+eoykHdFg2g=; Received: from [172.27.251.35] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 19 Jun 2020 16:42:24 +0100 From: Alexey Melnikov To: crypto-panel@irtf.org Cc: draft-irtf-cfrg-vrf@ietf.org References: Message-ID: <02b7d60b-6f57-4773-c362-ab01bdb0a06a@isode.com> Date: Fri, 19 Jun 2020 16:41:55 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [Crypto-panel] Request for review: draft-irtf-cfrg-vrf-07 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 15:42:27 -0000 Dear Crypto Panel members, Nick, Stanislav and I would like to ask Crypto Review Panel members for a review of ("Verifiable Random Functions"). Chairs are about to start RGLC on the document, so we would like to solicit some reviews before that. One or two reviews would be appreciated. Thank you, Alexey (on behalf of chairs) From nobody Fri Jun 19 10:01:52 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B3CCD3A0C75 for ; Fri, 19 Jun 2020 10:01:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=isode.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id SQo3mNeYys3q for ; Fri, 19 Jun 2020 10:01:49 -0700 (PDT) Received: from waldorf.isode.com (waldorf.isode.com [62.232.206.188]) by ietfa.amsl.com (Postfix) with ESMTP id 8316F3A0B68 for ; Fri, 19 Jun 2020 10:01:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1592586108; d=isode.com; s=june2016; i=@isode.com; bh=0P0CaGpAjPMn+bhTlcuwkNSCF7FeSQx3QUKolU893zE=; h=From:Sender:Reply-To:Subject:Date:Message-ID:To:Cc:MIME-Version: In-Reply-To:References:Content-Type:Content-Transfer-Encoding: Content-ID:Content-Description; b=Zs354BFlCX+SK6adTy13YMUemTsDBF+j/3hzHP5uCWA4KxGDSETiHRqeE6Fdgmwkk447QM aiS7xnE5XB17ObekyMk83RTDg8QGtUf/jwy1K8yyOsWyuXxPCxmtn9mhYvase1SvQNKQBy pzlA7Rk89Hh5a9HplXHgMldy2i0Gmao=; Received: from [172.27.251.35] (connect.isode.net [172.20.0.72]) by waldorf.isode.com (submission channel) via TCP with ESMTPSA id ; Fri, 19 Jun 2020 18:01:48 +0100 From: Alexey Melnikov To: crypto-panel@irtf.org, Jean-Philippe Aumasson Cc: draft-irtf-cfrg-kangarootwelve@ietf.org References: Message-ID: <4bdcc833-a65b-45d0-9636-cd0224f41f75@isode.com> Date: Fri, 19 Jun 2020 18:01:19 +0100 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-GB Archived-At: Subject: [Crypto-panel] Request for review: draft-irtf-cfrg-kangarootwelve-02 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 17:01:51 -0000 Dear Crypto Panel members, Nick, Stanislav and I would like to ask Crypto Review Panel members for an extra review of ("KangarooTwelve"). Jean-Philippe Aumasson has made an excellent review of -01. Jean-Philippe, can I ask you to double check that your comments were addressed in -02? Thank you, Alexey (on behalf of chairs) From nobody Fri Jun 19 10:04:23 2020 Return-Path: X-Original-To: crypto-panel@ietfa.amsl.com Delivered-To: crypto-panel@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A6CC33A0C79 for ; Fri, 19 Jun 2020 10:04:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.097 X-Spam-Level: X-Spam-Status: No, score=-2.097 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=unavailable autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id B4SswrA-4Nfj for ; Fri, 19 Jun 2020 10:04:21 -0700 (PDT) Received: from mail-ot1-x336.google.com (mail-ot1-x336.google.com [IPv6:2607:f8b0:4864:20::336]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5D4253A0C75 for ; Fri, 19 Jun 2020 10:04:21 -0700 (PDT) Received: by mail-ot1-x336.google.com with SMTP id g5so7811167otg.6 for ; Fri, 19 Jun 2020 10:04:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=j4sDs/mU9yiS+oeoZUX4FLO3CIMVKSAIw+RQIQ+zG+I=; b=oDd8+zuzIcdAkEY0n8ufLgZz2q2/3fDf20DlaAV+2sCRDTHMkt6kgyc2YblFPA5C+I k8AwOf76JVtTnP4/fO97BYxbdjZBsgiEJsZp+tNNByuuU7KshI23W3RcAZ8333X85sDH ar3EVB1vMW+YXjBRG3pgID9aKsY8tR0ucFXwX7Rup9px3PVvyOu4nXyIVK2arHs4gPf1 8riThPHA+1800O52ObmMCFYMm2b85TZ2tDbsaYrEGU292D8cn+EXAKWnAq5wmIoVHMfi bpNuwCcC6IPedvoOT4OaZxmuGkFwvfo7dlJQhYR3souNABJ/5FoOEanD5En5ENpCZpFz ENHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=j4sDs/mU9yiS+oeoZUX4FLO3CIMVKSAIw+RQIQ+zG+I=; b=WWRAhfvgTreMRNXMFwRw6VrViyvGrfCW9GNito+5M7DkV1QsccMdT0de04b3PvTA9T Hx23olIYLEADmGsJMJy0ON3b6rnqILftoTyXFPtIVcsQPAXYJ2X7sKcrVJfqZxd9sW6k dlFBFnwGIAy2f7yl6MU65Zk6hoqEtNogRrx93KBCX7OJ+MeCS+vv1QfIDiXs28lFS9vY U3mwKzJ1JE88rWvrLkudwyaxuR9FRYngulyPXSbDn4g5TRimop7kCSiRtFwZg16lnOdw Hqfgudhfm1iV9qByVqXGrwwTGQv76X5YJqbnRYmSb+Undvk1cn02qB5c3FSjnWXbrQ8i tq+g== X-Gm-Message-State: AOAM5305HLjZxT3nZe9PdzBbbqI2h++Hc4ilBhxdcp9y412y/oj8iy1o Y2oBUvpY03TMbbS4zJijS5oC9QoIufb3mC+A0XY= X-Google-Smtp-Source: ABdhPJzxQIJ4aylCv0CAW+b2IwhlP64RbwYj+xMNqeNuLs22Ahh1pUpZfqRMDy2az3NEmHu8YPwbLv0WlV6cA+P/xz0= X-Received: by 2002:a05:6830:1e9c:: with SMTP id n28mr3718093otr.200.1592586260510; Fri, 19 Jun 2020 10:04:20 -0700 (PDT) MIME-Version: 1.0 References: <02b7d60b-6f57-4773-c362-ab01bdb0a06a@isode.com> In-Reply-To: <02b7d60b-6f57-4773-c362-ab01bdb0a06a@isode.com> From: Chloe Martindale Date: Fri, 19 Jun 2020 18:04:10 +0100 Message-ID: To: Alexey Melnikov Cc: crypto-panel@irtf.org, draft-irtf-cfrg-vrf@ietf.org Content-Type: multipart/alternative; boundary="00000000000055010305a872e2d5" Archived-At: Subject: Re: [Crypto-panel] Request for review: draft-irtf-cfrg-vrf-07 X-BeenThere: crypto-panel@irtf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Jun 2020 17:04:23 -0000 --00000000000055010305a872e2d5 Content-Type: text/plain; charset="UTF-8" I can do it, but I won't be able to look at it until 2 weeks from now because of deadlines - I hope that's not too late? All the best, Chloe On Fri, 19 Jun 2020, 16:42 Alexey Melnikov, wrote: > Dear Crypto Panel members, > > Nick, Stanislav and I would like to ask Crypto Review Panel members for > a review of > > ("Verifiable Random Functions"). > > Chairs are about to start RGLC on the document, so we would like to > solicit some reviews before that. > > > One or two reviews would be appreciated. > > > Thank you, > > Alexey (on behalf of chairs) > > _______________________________________________ > Crypto-panel mailing list > Crypto-panel@irtf.org > https://www.irtf.org/mailman/listinfo/crypto-panel > --00000000000055010305a872e2d5 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I can do it, but I won't be able to look at it until = 2 weeks from now because of deadlines - I hope that's not too late?
All=C2=A0the best,
Chloe

On Fri, 19 Jun 2020, 16:42 Alexey Melnikov, <alexey.melnikov@isode.com> wr= ote:
Dear Crypto Panel members,

Nick, Stanislav and I would like to ask Crypto Review Panel members for a review of
<https://datatra= cker.ietf.org/doc/draft-irtf-cfrg-vrf/?include_text=3D1>
("Verifiable Random Functions").

Chairs are about to start RGLC on the document, so we would like to
solicit some reviews before that.


One or two reviews would be appreciated.


Thank you,

Alexey (on behalf of chairs)

_______________________________________________
Crypto-panel mailing list
Crypto-panel@irtf.org
https://www.irtf.org/mailman/listinfo/c= rypto-panel
--00000000000055010305a872e2d5--