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

[Nick Sullivan <[e-mail]>]

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?

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?

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?

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?

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?

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/