Re: [CFRG] Second RGLC on draft-irtf-cfrg-pairing-friendly-curves

[Yumi Sakemi <[e-mail]>]

Dear Rene and Watson

I'm so sorry for my late reply.
Thank you for your comments.
I checked and discussed with my co-authors about comments from Rene and Watson.
As a result, we came up with the idea that the position of our I-D
might be different from what Rene and Watson commented on our I-D.
Below are the stances we understand when making comments from Rene and
Watson and the positions/stances of our I-D.

- Rene's stance
It is the point of view that the I-D should be for educational
purposes regarding pairing.
For example, the quality of the I-D is inadequate for a textbook and
inappropriate for an IRTF draft.

- Watson's stance
 Standardization of pairing implementation.
 For example, there is a lack of detailed explanation of the
implementation method in the I-D.

To be clarified by Prof. Colin and Stanislav in the 2nd RGLC, the
stance of our activities is to make an informational RFC
about “secure parameters of pairing-friendly curves” promoting Secure
Pairing Cryptography on the Internet.

Kim's attack in 2016 led to a review of the security of pairing-friendly curves
no matter how there are still many implementations that contain
insecure parameters.
To solve this problem, we focus on providing an informative document
that implementers of
pairing-based cryptographies can refer to when selecting secure parameters.
Therefore, it is out of our scope in our I-D that a specific document
aimed at standardization and education of pairing algorithms.

We would appreciate it if you could reconfirm the stance and purpose of our I-D.

Best regards,
Yumi


<<FOR YOUR INFORMATION>>
In the following, I would like to explain the background and purpose
of our activities again for your reference.
As shown in our I-D, there are many kinds of types and parameters for
pairing-friendly curves, and it is difficult for implementers of
pairing-based cryptographies to select which parameter is secure.
For example, the parameters of pairing-friendly curves given in
standard specifications such as ISO and TCG have not been updated
since before Kim's attack in 2016, so implementers may refer to
insecure and inappropriate parameters when referring to these standard
specifications.
To address this issue, we propose to publish RFC for secure parameters
of pairing-friendly curves so that pairing implementors can safely
select secure parameters.

The proposed parameters in our I-D were selected based on the
selection policy of "security" and "widely used" after organizing the
security of parameters of pairing-friendly curves shown in standard
specifications, libraries, and applications.

On the other hand, again, we do not aim to standardize the method of
pairing implementation.
A pairing implementation consists of many arithmetic operations,
including operations on finite fields, twist techniques, operations on
elliptic curves, pairing operations, and applications of pairing.
Since many approaches to accelerate each type of operation have been
proposed, we don't want to limit the implementation methods in our
I-D.
Nevertheless, the existence of methods to improve the efficiency of
pairing computation is useful as references, so we have made
references to textbooks, papers, and other publications to present
carefully selected information.
Another way to look at it is that acceleration methods may have
patents against them, so we avoid such risks.

2021年9月10日(金) 7:43 Watson Ladd <[e-mail]>:
>
> On Fri, Aug 13, 2021 at 11:40 AM Stanislav V. Smyshlyaev
> <[e-mail]> wrote:
> >
> > Dear CFRG participants,
> >
> > This message starts a second RGLC on "Pairing-Friendly Curves" (draft-irtf-cfrg-pairing-friendly-curves-10), that will end on September, 8th.
> >
> > See https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves/ for the latest version of the draft.
> >
> > We are having the second RGLC since Yumi Sakemi has provided (see https://mailarchive.ietf.org/arch/msg/cfrg/-1nTbbVRlkP5wV2odEYFac-jK08/) updated replies for the questions raised after the first RGLC.
> >
> > Please send your comments, as well as expression of support to publish as an RFC (or possible reasons for not doing so) in reply to this message or directly to CFRG chairs.
>
> The timing of this WGLC was a bit unfortunate for me, and I apologize
> for my late submission.
>
> I think this draft has many issues. It doesn't limit the number of
> choices, it doesn't provide enough information to implementers, it's
> filled with extraneous information about history and applications and
> much useful information is in the appendices. I don't think this
> draft's publication will help authors who would like to point to a
> reference for BLS12 and how to implement it.
>
> Sincerely,
> Watson Ladd
>
> --
> Astra mortemque praestare gradatim
>
> _______________________________________________
> CFRG mailing list
> [e-mail]
> https://www.irtf.org/mailman/listinfo/cfrg



-- 
Yumi Sakemi, Ph. D.
 Infours Inc.

E-Mail: [e-mail]