[CFRG] Re: Pairing-Friendly Curves: Open Questions Before Draft Update

[Watson Ladd <[e-mail]>]

On Fri, Dec 12, 2025 at 8:25 AM Nick Sullivan
<[e-mail]> wrote:
>
> Dear CFRG Participants,
>
> Following the IETF 124 presentation on the pairing-friendly curves draft (https://datatracker.ietf.org/doc/draft-irtf-cfrg-pairing-friendly-curves/) we’re working with the authors and new contributors to bring this work to closure.` Before preparing an updated version or scheduling an interim, we want to confirm group consensus around several open questions raised during reviews since the last RGLC and again recently:
>
> Document scope and structure
>
> Should the draft stay focused on curve parameters and test vectors, or also include interface guidance, serialization formats, or tutorial content? Should nonessential background material (e.g. pairing formulae, curve surveys) be moved to an appendix or companion document? Should the draft’s title or positioning be updated to reflect this narrower focus?

I think the draft should include serialization formats. Interface
guidance I am less sure about, but could be welcome. I'm not sure how
formulas are nonessential to help implementors.
>
> Curve selection
>
> Is the current set of curves appropriate? Some suggest narrowing to BLS12-381 plus one BLS24 and one BLS48 to target 128-, 192-, and 256-bit security levels. Others recommend removing BN curves that may no longer meet security or deployment criteria. A shared rationale is needed for inclusion or removal. Should this document support only BLS-style use cases, or also applications like ZKPs or IBE?

I think the document should support the full scope of applications.

>
> Interfaces and related primitives
>
> Should the draft describe expected abstractions or interfaces (e.g. mapping to G1/G2, referencing hash-to-curve), or should it remain neutral and defer to other specs like RFC 9380? Should the draft specify a minimal pairing API (e.g. function signature or domain separation guidance), or leave that entirely to downstream specs?

I don't think we should cover things an already existing spec covers,
but there shouldn't be gaps.

>
> Serialization
>
> The current draft allows both compressed and uncompressed encodings, including identity elements. Concerns were raised about interoperability and risks from optional encodings. Should the draft specify a simpler, consistent serialization format for implementers? Should identity points be disallowed or tightly constrained?

Compressed encodings can be a challenge when decompression is more
expensive than ensuing processing. Choosing only uncompressed could be
fine. Not sure about identity points.
>
> Framing and utility
>
> To support adoption, should the draft explicitly document security assumptions (e.g. resistance to DLP via exTNFS), implementation risks (e.g. subgroup checks), and what classes of protocols these curves are appropriate for? Should test vectors include intermediate values or results for multiple encodings?

I think documenting security assumptions would be really useful.
>
> Please respond on the list with input on any of the above. Once we’ve collected feedback, we’ll open issues in the GitHub repo and evaluate whether a short interim is needed.
>
> Thanks,
> Nick (for the chairs)
>
> Relevant threads:
> https://mailarchive.ietf.org/arch/msg/cfrg/KmqSMLWzuj7MSGNuv3PiReZ-jVE/
> https://mailarchive.ietf.org/arch/msg/cfrg/-1nTbbVRlkP5wV2odEYFac-jK08/
> https://mailarchive.ietf.org/arch/msg/cfrg/OOwChBvt4vjJrfUYEF0g_ENbSlc/
> https://mailarchive.ietf.org/arch/msg/cfrg/JnyN9-G6vIGSMuWyyqoWNNdQ6Xk/
> https://mailarchive.ietf.org/arch/msg/cfrg/wypZbN6YlgqL7KmrvGojFBarMqY/
> https://mailarchive.ietf.org/arch/msg/cfrg/Mr3oRJpwbRd-czt50ksAOkrNuTo/
> _______________________________________________
> CFRG mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]



-- 
Astra mortemque praestare gradatim