From nobody Fri Apr 30 14:18:41 2021
Return-Path:
X-Original-To: cfrg@ietfa.amsl.com
Delivered-To: cfrg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 18E6F3A2740
for ; Fri, 30 Apr 2021 14:18:41 -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, FREEMAIL_FROM=0.001,
NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 9jWILnRvj6Tz for ;
Fri, 30 Apr 2021 14:18:35 -0700 (PDT)
Received: from mail-qt1-x831.google.com (mail-qt1-x831.google.com
[IPv6:2607:f8b0:4864:20::831])
(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 C41773A2741
for ; Fri, 30 Apr 2021 14:18:34 -0700 (PDT)
Received: by mail-qt1-x831.google.com with SMTP id y12so52658349qtx.11
for ; Fri, 30 Apr 2021 14:18:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=to:cc:references:from:subject:message-id:date:user-agent
:mime-version:in-reply-to:content-transfer-encoding:content-language;
bh=LjrEIxriUOdi641z3bRkb35ixvMAY4CxerdgUmwRixg=;
b=lDTyaG2jRjWfJp2wx1RuP4oKCnuKyHZtbG7KRmoqQZ40jFDrEu9V9s2of9YbK82fQn
ti6onq3/l6/6H77zSp12z1R4e6m0/BoeytgRZdKh+VtD4fLbuzmTIFhQF+ZJCnbQkEXG
YtHfO7moATB7rd/1drXf1Iap3nmLaeadBykDYkfSaPVeDqVnE7vGHQJQRBh2cc21lrW8
OcTod86WCAKzKWakvuF+T+kzrnjxrS7SM3eCPi4qGAHz18vpgCy9OcV1sIUWdtKbxiOC
gMcyriXoVIFw70LNGNLxcVHkGSDPY+6aBh5k6aZ8LiSQDKwbHGd17fvKLaHcEArdiAD5
fgTg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:to:cc:references:from:subject:message-id:date
:user-agent:mime-version:in-reply-to:content-transfer-encoding
:content-language;
bh=LjrEIxriUOdi641z3bRkb35ixvMAY4CxerdgUmwRixg=;
b=Bx2M1ipYl+jnnsfIbR2i/bOPMTneOu9iMn3+SLqtVrEiMCXE5mAZY55UuAnyBVaG4m
gEJUKQjG75l2yFSC8+DQZLP8i8o1WQKfBlONNFcBav1cX1BcmkM/wU+1BQCMoXuCRRvC
oPmJt/R0T/w12OoDwrHf5bnSmeC3LXKkm48J7DmGcxN9VpDRK56Kao0JUrSmNFyOuh4P
EF4f6jaFHGPu9t2TDbrv0YfecQHO9HhAHnWW+mFhr9nxapEP1ubTMpgapUBp3iuaVB9p
klxVz82rnzXRa506OpUpJc3iXRLm4ARL0NQpjbs+iqRAseU/9CVH3U/93OB9OgK63tU/
6rRQ==
X-Gm-Message-State: AOAM531tFCaVqvKCqKL/0ytJ3NzvKCUBtuO6u4NyhdFKJMCAV8O+kJ2N
81rxVCBnR0VcANz5yYt5Jiw=
X-Google-Smtp-Source: ABdhPJzIZs5l8o9d574+oPrxmUpCmLEdPvS00psQ3A+b/GS24khUEmA2qb9Nb44KBbLfVsrq589YEw==
X-Received: by 2002:ac8:4e24:: with SMTP id d4mr6264611qtw.213.1619817511653;
Fri, 30 Apr 2021 14:18:31 -0700 (PDT)
Received: from ?IPv6:2607:fea8:8a0:1397:d402:2eb3:bf29:5fa3?
([2607:fea8:8a0:1397:d402:2eb3:bf29:5fa3])
by smtp.gmail.com with ESMTPSA id q28sm2370183qkm.15.2021.04.30.14.18.30
(version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128);
Fri, 30 Apr 2021 14:18:31 -0700 (PDT)
To: Yumi Sakemi
Cc: CFRG , SAITO Tsunekazu ,
Tetsutaro Kobayashi ,
cfrg-chairs@ietf.org
References:
<2a2ea245-79e3-dcea-3176-7b5c5742b941@gmail.com>
From: Rene Struik
Message-ID:
Date: Fri, 30 Apr 2021 17:18:29 -0400
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101
Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To:
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Content-Language: en-US
Archived-At:
Subject: Re: [CFRG] Second RGLC on draft-irtf-cfrg-pairing-friendly-curves
X-BeenThere: cfrg@irtf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Crypto Forum Research Group
List-Unsubscribe: ,
List-Archive:
List-Post:
List-Help:
List-Subscribe: ,
X-List-Received-Date: Fri, 30 Apr 2021 21:18:41 -0000
Hi Yumi:
Thanks for your note.
I may have missed something, but the weblink which you provided below=20
and which supposedly already answered my 2nd WGLC comments does *not*=20
seem to already have answered my review comments, contrary to what you=20
suggested. If it did (and I somehow missed this), why did not you not=20
simply indicate so on=C2=A0 March 18th, rather than only doing his now, 6=20
weeks later?
I will try and go through the details of your note later (it is hard to=20
keep interested with such extremely long cycles [we all have time to=20
manage]).
One general comment and piece of advice (based on a quick scan of your=20
email): you seem to take the position that one does not need to=20
elaborate on topics that are already known to "people in the know" in=20
pairing. I do think the purpose of CFRG docs is to introduce "new"=20
(whatever that means) crypto and make these accessible to a community=20
that is wider than those already in the know. I do think (my=20
interpretation of) your position is not very helpful to garner wider=20
appreciation of a topic area. It again makes me wonder why you're even=20
bothering. I think one can do much better and serve the community at=20
large by not tasking readers to go elsewhere to look up details.
Rene
Your ref: [1]=20
https://mailarchive.ietf.org/arch/msg/cfrg/2i183zl28y4fK54oIwqEfEVVu0U/
On 2021-04-30 4:47 p.m., Yumi Sakemi wrote:
> Dear Rene
>
> Thank you for your e-mail.
> I am very sorry for the delay in responding to your email at the start
> of the 2nd RGLC.
>
> I had already responded to the main part of your comment in November
> 2020 in the following email I sent in December 2020, and we were
> waiting for your response to that communication.
> https://mailarchive.ietf.org/arch/msg/cfrg/2i183zl28y4fK54oIwqEfEVVu0U/=
>
>
> I was relieved to hear from you, as I had been worried that I had not
> heard from you for a long time.
>
> Since there is a possibility that you may not have read my e-mail in
> December, I will reply to each of your comments again in this e-mail.
> I apologize for the length of this message in advance.
>
>
> ----------
>> 1) It seems that at least half of my main technical comments (apart fr=
om
>> editorials) with my review of the rev-07 draft have not been addressed=
=2E
>> Moreover, it is somewhat hard to get back to the authors on the mailin=
g
>> list, since they buried their comment resolutions in a somewhat nebulo=
us
>> github structure. This makes it a little bit hard to get enthusiastic
>> about doing yet another review.
> Thank you for your comments.
> As you may know, many of the drafts registered on CFRG use GitHub's
> issue feature to track revisions and changes of drafts.
> You can refer to the following URL.
> https://github.com/cfrg
>
> So, let me add that this is not our original management method.
> In addition, for comments that were not reflected as a result of
> discussions among the authors, the reasons for not reflecting them are
> also listed.
> Could you please check again our reply comments for your comments if
> you have any additional concerns?
>
>
>> 2) It seems that the authors have not done any effort to disentangle
>> technical specification, availability of libraries, and actual
>> deployment (see my comment #01 of my rev07 review), where there still =
is
>> a somewhat misleading tilt due to equating all these disparate things
>> and where there is still an unusual prominence of company names, etc.
>> Perhaps, some of this can be taken care of by including a section with=
>> "implementation status" (which disappears once this becomes an RFC), a=
s
>> other IETF drafts have done. Nevertheless, this would fly in the face =
of
>> selection policies for pairing-based curves which are based on conflat=
ed
>> notions. This begs the question what the purpose of this draft is.
> I'm sorry that the purpose of our draft was difficult to understand.
> Let me explain the target of standardization again.
> Our goal is to standardize secure parameters for pairing-based
> cryptographic applications.
> Since the 2016 Kim's attack made widely used standard parameters no
> longer secure enough, we are organizing existing parameters and, among
> others, showing which parameters should be used for each bit security.
>
> As reference information, the calculation method of pairing is
> described, but it is out of the scope of standardization
> And also, an educational purpose for pairing is out of the scope of our=20
draft.
>
> On the other hand, in response to your comment, the authors have
> discussed why this misunderstanding has occurred and thought that the
> current title may be too generic and inappropriate.
>
> The current title is "Pairing-Friendly Curves", which may have given
> the impression of a broad standardization of information about
> pairing.
> We thought it would be a better idea to change the title to something
> more specific to secure parameters of pairing, such as "Secure
> Parameters of Pairing-Friendly Curves".
> Would this address the misconceptions and concerns underlying your comm=
ent?
>
> Also, the reason why we are describing the implementation status is
> that in standardizing the parameters it is because this information is
> essential to show how the parameters were selected.
> There is no purpose to advertise the company or implementer.
>
>
>> 3) The draft, as it stands, still contains lots of material that is in=20
a
>> state with much to be desired for. As an example, Appendix A contains
>> quite a few errors (Ate pairing) and lacks sufficient explanatory
>> context and Appendix C is such an adhoc hack that (I feel) this should=
>> never be endorsed by CFRG. For details, see some of my comments on rev=
08
>> (where I did focus on the appendices).
> I think this comment is corresponds to Detailed Comments, so I'll
> provide detailed answers there.
> As you know because you commented in detail, our target is a specific
> pairing calculation called "Optimal Ate pairing", not Ate pairing.
> Optimal Ate pairing is an improved version of Ate pairing proposed by
> F. Vercauteren in 2008.
>
> F. Vercauteren, "Optimal Pairings",
> available at https://eprint.iacr.org/2008/096.pdf, 2008.
>
>
>> 4) It may be best if CFRG ditches this document, since it still seems
>> far off from being a useful document, written clearly so as to educate=
>> the CFRG and the wider IETF community. (Given the lack of feedback on
>> this document over time, perhaps nobody would care.). Should CFRG stil=
l
>> wish to give this draft a chance to become a CFRG-issued RFC, I believ=
e
>> it needs a major rewrite to get rid of nontechnical spin material. I
>> also think it would be beneficial not to have yet more specifications
>> come up with their own representations and procedures where there is n=
o
>> real technical justification for this. Should the authors wish to push=
>> this "as is", they could always pursue the "independent stream" for th=
is
>> (where one could argue that nothing can be changed). If this should be=
>> pushed furthr, I can imagine a slim draft, without umpteen tables and
>> zillions of references, where one simply provides domain parameters an=
d
>> explains how mappings work without all the ads for libraries and
>> start-up companies with non-empty github pages.
>> For some detailed technical and editorial comments, see below. (I have=
>> more comments, but I think the below suffices to show this is far from=
>> ready.)
>> I know this is not what authors want to hear and does not make me
>> popular, but so be it.
> Thank you for your comments.
> We believe that there is no problem to proceed with standardization in
> CFRG because we are following the IETF manner.
> In light of the situation in our draft, we recognize that there is no
> change in the situation that would overturn the approval in the
> Adoption Call.
> Regarding the table on implementation status, other CFRG members
> pointed out the size of the table.
> For this, I followed your comments and increased readability by
> splitting the table.
> Also, this table is required information to show that we are following
> the selection policy, not to advertise it.
> We are aware that we have reached a consensus by keeping the size to
> the minimum required.
>
>
>> Detailed comments:
>> 1) Appendix A: the description of the so-called line function is very
>> unclear for non-pairing people (which I presume is most of the CFRG),
>> where expressing this in a style resembling elliptic curve notation mo=
re
>> would certainly help. Some suggestions: express the line function as
>> Line_function(P1,P2,Q), where P1:=3D(x1,y1) and P2:=3D(x2,y2) are affi=
ne
>> points of G2 (curve defined over GF(p^2)) and where Q:=3D(X,Y) is an
>> affine point of G1 (curve defined over GF(p)), mapping to subgroup G_T=
>> of GF(p^k)^*. This allows expressing the number l if P1=3DP2 as
>> l:=3Dlambda:=3D(3*x1^2+a)/(2*y1), which is familiar in point doubling
>> formulas for short-Weierstrass curves (where, here, domain parm a is
>> zero) and, similarly, if P1<> (+/-) P2, as l:=3Dlambda:=3D(y2-y1)/(x2-=
x1)
>> (see, e.g., [3]). Here, it would also help explaining what happens in
>> case of non-affine inputs (point-at-infinity) and why the output would=
>> be an element of the prime-order multiplicative subgroup G_T of GF(p^k=
)^*.
> Thank you for pointing this out.
> I understood that your comment means that in Appendix A, the
> expressions for the x- and y-coordinates in the Affine coordinates of
> the rational point A are represented as A[1] and A[2], respectively.
> I agree with your point that the expressions are not familiar, so I
> will correct it by using the symbols x and y.
>
>
>> 2) Appendix A, last para before A.1: one should mentions the image of
>> the point-at-infinity under this Frobenius map.
> I am afraid that I explain this to experts, but the Frobenius map is
> an isomorphism map, so the identity element (the point at infinity) is
> mapped to the identity element.
> Since we think it is trivial, we describe no explanation about it.
>
>> 3) Appendix A.1: this section seems to be full of ambiguities and
>> errors:
> (a) should one assume the parameter t is the same as the one
>> definining the prime p, etc.? (if so, please say so);
> The parameter t is defined in the main part of 4.2.1 and 4.2.2, so I
> hope you will check the draft properly.
> Also, the method of expressing parameters p and r as polynomials of
> the basic parameters (in this case t) is familiar to those in the
> field of pairing.
>
>
>> (b) write c:=3Dc0+c1*2+ ... + c_{L}*2^{L} and explain that c_L is nonz=
ero and that
>> the Ate pairing procedure works no matter the choice of the coefficien=
ts
>> in the range {-1,0,1} (if not, much explanation is needed, since, e.g.=
,
>> c=3D0+1=3D2-1 may have different results;
> Thank you for your comments.
> As a reiteration, we would like to note that our target is *Optimal*
> Ate pairing.
> As mentioned in the draft, the parameter c is a specific value
> determined by the parameter t.
> The calculation method is outside the scope of our standardization,
> and since there are several ways to expand c, our policy is that
> implementers can choose the best one.
>
>
>> (c) fix the loop to "for i:=3DL-1 downto 0";
> Thanks for pointing that out.
> I'll revise it to "downto" according to your comments.
>
>> (d) replace the silly "|" language in the if condition "c_i=3D1
>> | c_i=3D-1" by "c_i nonzero" (you are writing this for humans, not for=
>> parsers);
> Thank you for your comments.
> Indeed, I agree that it is not common to express "or" with "|".
> So, I will define "! =3D" is defined as "not equal to" in advance and
> then modify to "c_i ! =3D zero".
>
>
>> (d) the Line_function has three arguments, but in the call
>> Line_function(T, ci*Q) it only has two: should this include P as third=
>> argument?;
> I'm sorry but I had a typo, so thank you for pointing it out.
> I will revise it.
>
>> (e) how does one know the line function never receives
>> non-affine points as input?;
> You can also calculate pairing with other coordinates than Affine
> coordinates, such as projective coordinates.
> However, we have a policy of not mentioning specific calculations that
> use other coordinates in particular, as it may violate patents.
> We recognize that there is no big influence even if the coordinates
> are different because it does not affect the final calculation results
> of pairing or test vectors.
>
>
>> (f) the line with frobenius maps seems to compute Q1:=3Dfrob(Q); Q2:=3D=
frob(Q1) and,
>> if so, doesn't one get Q2=3Dfrob(frob(Q))=3DQ since Q is a point of G2=20
and,
>> thereby a point of a curve defined over GF(p^2)?
> Algorithms using the Frobenius map are not the target of our standardiz=
ation.
> For this reason, we consider the reference information on the
> calculation method to be sufficient.
> If you want to know the details of the calculation method, please
> refer to the reference information.
>
>
>
>> 4) Appendix A.1: how does one know that f is never the zero element 0
>> (if so, it is not in GF(p^k)*)?
> We believe that it is clear from the method of calculation that f does
> not equal zero.
> For f to be zero, the numerator of the Line Function needs to be zero.
> The numerator of the Line Function is when the difference of the
> x-coordinates of the points is zero, that is, in an elliptic curve,
> when the two input rational points are equal.
> However, in this case, the process is (3 * A[1]^2), which is not zero.
> Implementers can check that the implementation is correct by testing
> with test vectors and boundary values.
>
>
>> 5) Appendix A.1: the Ate pairing seems to use integer c written in
>> NAF-notation. If so, shouldn't one at least say something about side
>> channels, in case the inputs or outputs of the Ate pairing are
>> non-public parameters? What about the huge final exponentiation in
>> GF(p^k)^*, where the exponent h:=3D(p^k-1)/r has an enormous size (~
>> p^{k-1})? (Note RS: I did ask about side-channels in my review of the
>> rev07-draft [rev07-comment #10], but that comment was never addressed.=
)
> Although the NAF representation is sometimes used as a side-channel
> countermeasure, the NAF representation in pairing calculations is used
> for accelerating purposes.
> The reason for this is that the parameter c is public information, not =
secret.
> The cases where side-channel attack countermeasures are required as
> pairing-based cryptography are described in security considerations.
>
>
>> 6) Appendix A.2: the beginning of that section is virtually the same a=
s
>> Appendix A.1's, but misses some language (e.g., on "sum of
>> (i=3D0,1,...,L)" --> equals c, order r --> of G1, etc. Remarks on some=20
of
>> the steps of the listed procedure similar to those with Appendix A.1 a=
pply.
> Thank you for pointing this out.
> We will revise the description so that description is aligned.
>
>
>> 7) Appendix A would benefit from a much better explanation of the role=
>> of the Ate pairing in pairing-based crypto. Otherwise, this seems just=
>> loose sand, without context. (If the goal is to educate the CFRG
>> audience about coolness of pairing-based crypto, why not provide
>> sufficient detail to raise interest?; otherwise, why pursuing this dra=
ft?)
> We consider it sufficient to show that pairing realizes for great
> applications in the Introduction section.
>
>
>> 8) Appendix B: the relationship between elements of GF(p^k) and the
>> output sequences (e_0,...,e_{11}), resp. (e_0,...,e_{47}) is not
>> described in sufficient detail.
> Thanks for your comments.
> The symbol e consistently represents the value of the pairing in the
> draft, but we will describe the explanation again.
>
>
>> 9) Appendix C: this appendix is so poorly written and the construction=
>> so adhoc that this should be abandoned right away (see also my previou=
s
>> comment in my rev-07 draft review (rev07-comments#21/#22). Here, simpl=
y
>> observe that this point encoding only works for BLS12-381 and not for,=
>> e.g., BN462, purely because of poor design choices made. Please also s=
ee
>> Note 2 of Appendix I.8 of draft-ietf-lwig-curve-representations-13
>> (which describes SEC1 representations, but now for any field of odd
>> characteristic). Simply using the SEC1-encoding, where one squeezes-in=
>> the 1-octet identifier for affine points (0x04), point-at-infinity
>> (0x00), and compressed y-coordinate (0x02 or 0x03) in the leftmost 2
>> bits of the tight MSB/msb-order representation of elements of GF(p),
>> where the bit-length of p has two fixed bit positions for BLS12-381 an=
d
>> BN462 case does the job.
>> 10) Appendix C: while I think this appendix should be ditched right aw=
ay
>> and replaced by a more systematic approach that, in principle, applies=
>> to all pairing-based curve domain parameters (see prevous comment),
>> there are also some problems with the text itself, including (a) the
>> high-level remarks are confusing and do not seem to contain any useful=
>> information, so might easily be removed; (b) The I2OSP and OS2IP
>> functions in RFC 8017 do describe integer-to-octet-string and
>> octet-string-to-integer conversions, but do not specify the bit-orderi=
ng
>> (which is needed to describe the encoding of integers as bit-strings a=
nd
>> vice-versa); (c) Step 2 (in Appendix C.1) seems to confuse
>> specification and implementation (since seemingly aimed at machines
>> rather than humans); (d) Step 3 (in Appendix C.1) seems to suggest tha=
t
>> an element x=3Dx0 + u*x1 of GF(p^2) is represented in the order "highe=
st
>> coefficient first", whereas in Section 2.5 this seems to be in the ord=
er
>> "lowest coefficient first" (although this is hard to figure out due to=
>> the recursive definition in terms of towers of fields) - it is hard to=
>> figure out what "see discussion of vector representation above" refers=
>> to, since there does not seem to have been one; (e) Step 8 (in Appendi=
x
>> C.2) may result in output P:=3D(x,-y), where the second coordinate is =
a
>> negative integer (and, thereby, not in the interval [0,p)).
> I recognized that detailed comments 9 and 10 are about Appendix C.
> The position of Appendix C is that it is reference information for
> implementers, not a standardization target.
> Since the author understands that the methods in Appendix C don't
> apply to BN462, it is also clearly stated that the methods are for
> BLS12-381 and are for reference only.
> As for the contents of the Appendix in the draft (excluding typos), I
> think that there is no problem with the current expression.
>
>
>> Editorial comments:
>> 1) Appendix A, last para before A.1: this para refers to Barreto-Naehr=
ig
>> curves and should be moved to the beginning of Appendix A.1.
> Thank you for your comment.
> This is not a technique specific to BN curves, so we will remove "for
> BN curves".
>
>> 2) Appendix A, last para before A.1: why not expressing the Frobenius
>> map in a more human-friendly way, e.g., frob(x,y):=3D(x^p,y^p), where =
one
>> leaves the parameter p implicit?
> Thank you for your suggestion.
> We will revise it according to your comments.
>
>
>> 3) Appendix B, l. 8: in "where u is a indeterminate", change "a" to "a=
n".
> I=E2=80=99m sorry but I had a typo, so thank you for pointing it out.
> I will revise it.
>
>> 4) Appendix B, l. 8: check for consistent naming of BLS48-581, etc.
>> (underscore vs. dash language). Also elsewhere. BTW - it would help to=
>> add the curve name to section headings to make these easier to find,
>> e.g., adding BLS12_381 to the title of Section 4.2.1, etc.
> Thanks for pointing this out.
> I will revise the wording to be consistent, using underscores.
> Additionally, we will revise the title as you suggested.
>
>> 5) Appendix C, p. 49: replace "sign_F_p" by "sign_GF(p)", etc.
> Thank you for your comments.
> I will revise it.
>
>> 6) Section 4.2.1, last para: I am not sure what adding the new (in
>> rev08) advertisement for another cfrg draft (hash-to-curve) adds to th=
is
>> document, since it seems to be just PR, without any context. Shouldn't=
>> one shy away from cross-marketing?
> There is no cross-marketing implication as you have pointed out.
> As for the pairing draft, we are citing it because it is a draft that
> should be cited from the perspective that the Hashing feature is
> necessary for the protocol implementation.
>
> Best regards,
> Yumi
>
> 2021=E5=B9=B43=E6=9C=8818=E6=97=A5(=E6=9C=A8) 21:53 Rene Struik :
>> Hi Stanislav:
>>
>> I am puzzled that the 2nd WGLC is on rev09 of the pairing curve draft =
(i.e., the one posted on Nov 16th last year).
>>
>> On Nov 11th, I posted another review on rev08 of this document (see [1=
]) {for my review of the previous rev07 version, see [2]}.
>>
>> I could not find any response by the authors to my detailed comments o=
f my rev08 review. Since they posted the current rev09 version (that is u=
nder 2nd WGLC) on Nov 16th, considerations of those comments must have ha=
ppened within that 5-day time window. The authors, however, stated in [3]=20
"Because we are currently considering Rene's latest comments, I'm sorry =
but this version does not reflect them".
>>
>> Isn't the normal step to consider received comments? If so, isn't the =
2nd WGLC premature?
>>
>> (FYI - the authors only commented - after almost four months - on my m=
inor note regarding normative vs. informative reference classification, b=
ut not at all on the much larger review I did in [1].)
>>
>> Best regards, Rene
>>
>> [1] Review RS of draft-irtf-cfrg-pairing-friendly-curves-08 (Nov 11, 2=
020):
>> https://mailarchive.ietf.org/arch/msg/cfrg/kAQwgiKejMby4aYONkQzt0ZiOOU=
/
>>
>> [2] Review RS of draft-irtf-cfrg-pairing-friendly-curves-07 (July 12, =
2020):
>> https://mailarchive.ietf.org/arch/msg/cfrg/pW71h3yUETnqedHsH0m3rwzPnm4=
/
>>
>> [2] Message Yumi Sakemi on draft-irtf-cfrg-pairing-friendly-curves-09 =
(Nov 16, 2020):
>> https://mailarchive.ietf.org/arch/msg/cfrg/NNpHIWGOvsSBd22gg7Ve10zDhT4=
/
>>
>>
>> On 2021-03-18 7:04 a.m., Stanislav V. Smyshlyaev wrote:
>>
>> Dear CFRG participants,
>>
>> This message starts a second 3-week RGLC on "Pairing-Friendly Curves" =
(draft-irtf-cfrg-pairing-friendly-curves-09), that will end on April 9th.=20
See https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-cur=
ves/ for the latest version of the draft.
>>
>> We are having the second RGLC since Yumi Sakemi has provided (see http=
s://mailarchive.ietf.org/arch/msg/cfrg/2-LVS6EXc4TfY1zlHRGUXe3cu6w/) repl=
ies for the questions raised after the first RGLC.
>>
>> Please send your comments, as well as expression of support to publish=20
as an RFC (or possible reasons for not doing so) in reply to this message=20
or directly to CFRG chairs.
>>
>> Regards,
>> Stanislav, Nick and Alexey
>>
>>
>> _______________________________________________
>> CFRG mailing list
>> CFRG@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
>>
>>
>> --
>> email: rstruik.ext@gmail.com | Skype: rstruik
>> cell: +1 (647) 867-5658 | US: +1 (415) 287-3867
>>
>> _______________________________________________
>> CFRG mailing list
>> CFRG@irtf.org
>> https://www.irtf.org/mailman/listinfo/cfrg
--=20
email: rstruik.ext@gmail.com | Skype: rstruik
cell: +1 (647) 867-5658 | US: +1 (415) 287-3867