[CFRG] Re: Review of draft-irtf-cfrg-pairing-friendly-curves-13

[Yumi Sakemi <[e-mail]>]

Hi Emil, and CFRG,

Following up on my reply of 28 July, where I said we would file GitHub
issues
for each point and post the links back here: the tracking issue is now up.

Review from Emil Lundberg (CFRG list): summary and tracking
https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/issues/105

It lists all eleven points from the three messages
in this thread with the current disposition of each, so that none of them
is tracked only in our
private notes. Where an item is being handled in an existing issue or pull
request, the table points there:

- Items 1, 3 and 7 (the Section 2.5 octet-string convention, the [MP04]
reference, and the lwig citation) are resolved in #104, now merged.
Section 2.5 was removed and the conventions it carried were made
self-contained.
- Item 2 (the E' deserialization gap) is your PR #91. The Section 2.5
question was the blocker on merging it, and that is now cleared.
- Item 4 is your PR #95, still open.
- Items 8 and 9 are in Section 5, so they will land together with the
Section 5 restructuring tracked in #74. Item 10 is in Section 6; its
second half is the same sentence as item 9, so that part moves with it,
and the coefficient-range paragraph will be rewritten alongside.
- Items 5, 6 and 11a-11g are editorial and will land in -14. That includes
crediting all of the WebAuthn co-authors, as promised.

Two rows of the table record a reading that differs slightly from the
comment
as written (the premise of item 6a, and the formula suggested under item 8).
Our reasoning is set out there, so please do push back on the issue if we
have it wrong.

We will keep the issue updated as items land, and I will post here again
when
-14 goes out.

Thanks again for the review.

Best regards,
Yumi

On Tue, Jul 28, 2026 06:18 PM, Yumi Sakemi <[e-mail]>
wrote:

> Hi Emil,
>
> Thank you for all of this -- across the serialization issues, the broader
> review comments, and the follow-up on Appendix A/B, this is an incredible
> amount of careful review, and exactly the kind of input we were hoping for
> ahead of the next Crypto Panel round.
>
> We're going to work through everything properly rather than rush a
> response -- we'll file GitHub issues for each point and post the links back
> here as we go, so nothing gets lost.
> On point 2 (the E' deserialization gap), we'd very much welcome a PR if
> you have one ready; otherwise we'll take a pass at it ourselves.
> And sorry about the [W3C] reference only crediting you -- that's on us, we
> should have listed all of the WebAuthn co-authors; we'll fix that too.
>
> On the Appendix A/B question -- the lwig-curve-representations reference
> for the towered GF(p^12) representation does look off, thank you for
> digging into that. We'll also take a look at your implementation, as
> offered.
>
> Thanks again for taking the time to go through the draft in this much
> detail -- we'll be back with updates as we work through the list.
>
> Best regards,
> Yumi
>
> On Tue, Jul 28, 2026 05:35 PM, Emil Lundberg <[e-mail]> wrote:
>
>> 11. Another oddity in the references:
>> - The [Zcash] "What are zk-SNARKs?" reference is attributed to
>> "Lindemann, R.", but Rolf Lindemann (author of FIDO ECDAA Algorithm) is not
>> its author (I confirmed this with Rolf off list).
>>
>> Emil Lundberg
>>
>> Staff Engineer | Yubico <http://www.yubico.com/>
>>
>>
>>
>>
>> Den mån 27 juli 2026 kl 20:07 skrev Emil Lundberg <[e-mail]>:
>>
>>> Hi Yumi and CFRG,
>>>
>>> Continuing from the thread about issues #74 and #84
>>> <https://mailarchive.ietf.org/arch/msg/cfrg/UIDHgwRtkl86O37kQDET-wWWwPc/>,
>>> here are a few more review comments on pairing-friendly-curves-13, mostly
>>> regarding clarity and the like:
>>>
>>> 4. In section 2.2. Pairings
>>> <https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-13.html#name-pairings>
>>> :
>>> I initially read (GF(p^k))^* as an arbitrary-dimension Cartesian
>>> product, rather than the * just denoting multiplication. I'm not sure that
>>> needs fixing (or what a good fix would be), but this is also written
>>> inconsistently, varying between both (GF(p^k))^* and (GF(p^k))* throughout
>>> the draft.
>>>
>>> 5. In section 4. Selection of Pairing-Friendly Curves
>>> <https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-13.html#name-selection-of-pairing-friend>
>>> :
>>> This draft consistently spells "BLS12_381" with an underscore, but all
>>> other literature I've seen spells it "BLS12-381" with a dash, including in
>>> particular the {{BLS12_381}} reference but also RFC 9380,
>>> draft-irtf-cfrg-bbs-signatures-10 and draft-boneh-bls-signature-00. It
>>> might be worth aligning on spelling. (Probably also consider the same
>>> spelling convention for BLS48-581, though none of those 4 references name
>>> that curve)
>>>
>>> 6. In section 4.1. Adoption Status of Pairing-friendly Curves
>>> <https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-13.html#name-adoption-status-of-pairing->
>>> :
>>> - The "Arnd" notation seems to not appear anywhere (not in the draft,
>>> nor at the adoption-status.html link above). Where is this survey? It seems
>>> like a table might be missing, or something like that.
>>> - It's not clear to me what "and viewpoints of secure usage of
>>> parameters" is intended to mean. Perhaps consider something like: "and
>>> because we recommend against using parameters lower than the 128-bit
>>> level", if that is what you mean?
>>>
>>> 7. In section 4.2.1. BLS Curves for the 128-bit security level
>>> (BLS12_381)
>>> <https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-13.html#name-bls-curves-for-the-128-bit->:
>>> You note that BP' is "encoded with [I-D.ietf-lwig-curve-representations]",
>>> but I'm not sure that reference is relevant? Presumably this refers to Appendix
>>> I.8 Conversion Between Curve Points and Octet Strings
>>> <https://datatracker.ietf.org/doc/html/draft-ietf-lwig-curve-representations-23#appendix-I.8>,
>>> but that seems unrelated since the limbs are spelled as individual integers
>>> rather than as a single concatenated octet string?
>>>
>>> 8. In section 5.3. Point Deserialization Procedure
>>> <https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-13.html#name-point-deserialization-proce>
>>> :
>>> - Should we give any guidance on how to determine whether y2 is a
>>> square, or leave that out of scope? Or perhaps instead say to first compute
>>> y=sqrt(y2), then compute y2'=y*y and abort unless y2==y2'?
>>> - Should we give any guidance on how to compute sqrt(y2), or leave that
>>> out of scope? For example, is y = y2^((p-1)/2) always valid for all p (or
>>> at least for the p used in BLS12-381 and BLS48-581)?
>>>
>>> 9. In section 5.5. Identity Point Handling
>>> <https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-13.html#name-identity-point-handling>
>>> :
>>> "accepting [the identity point] has contributed to at least one
>>> documented issue in a deployed protocol"
>>> Perhaps include a link/reference to this documented issue?
>>>
>>> 10. In section 6. Security Considerations
>>> <https://www.ietf.org/archive/id/draft-irtf-cfrg-pairing-friendly-curves-13.html#name-security-considerations>
>>> :
>>> "When converting between an element in an extension field and an octet
>>> string, implementors should check that the coefficient is within an
>>> appropriate range {{IEEE1363}}. If the coefficient is out of range, there
>>> is a possible that security vulnerabilities such as signature forgery may
>>> occur."
>>> Is this meant to be "each coefficient" instead of "the coefficient"? Or
>>> "prime field" instead of "extension field"?
>>> I ask because I think that polynomials of too high degree should be
>>> unrepresentable if using the deserialization procedure in section 5.3,
>>> since the deserialization (assuming it mirrors the serialization) only
>>> decodes coefficients for degrees lower than the degree of the polynomial
>>> modulus.
>>>
>>> "Treating the identity element as an unremarkable, always-valid
>>> deserialization result [...] has contributed to at least one documented
>>> issue in a deployed protocol construction."
>>> Again: perhaps include a link/reference to this documented issue?
>>>
>>> 11. Regarding references:
>>> - The link to the reference [CF06] gives "DOI not found".
>>> - The [W3C] reference is described as WebAuthn Level 1, but /TR/ is a
>>> link to the latest version (currently L2, soon L3), not a stable link to
>>> L1. Use this instead (for L1, or a later snapshot link if you want to
>>> upgrade): https://www.w3.org/TR/2019/REC-webauthn-1-20190304/
>>> - Why am I the only author credited for the WebAuthn [W3C] reference? :)
>>> - The link to [EPID] appears to be a dead link.
>>> - [DFINITY] appears to be a dead link.
>>> - Maybe update [I-D.boneh-bls-signature] from Individual-Draft status to
>>> RG status: draft-irtf-cfrg-bls-signature?
>>>
>>> I also have a few more minor comments on style, formatting etc. which
>>> I'll raise as GitHub issues/PRs rather than taking up space on the mail
>>> list. Thanks again for your work!
>>>
>>>
>>> Emil Lundberg
>>>
>>> Staff Engineer | Yubico <http://www.yubico.com/>
>>>
>>>
>>>