[CFRG] Re: draft-irtf-cfrg-pairing-friendly-curves: question on the scope of PR #71 (Group/Scalar interface)

[Yumi Sakemi <[e-mail]>]

Hi Michele,

Thank you for the detailed answers, and for the survey in the second half.
Apologies
for the slow reply. Taking your points in order.

Section 5 has been rewritten since -13, and the rewrite is what will appear
in -14.
Section numbers below are the -14 ones; where I mean -13, I say so.

PR #71 and the scope questions

Understood on all four. We will close #71 in favour of Section 5 and issue
#74, as you
suggest. Good to know that G1 of BLS12-381 is what you need and that
Section 5 covers it.

Your point in answer 1 is the one we wanted to build on: a curve document
should specify
validation criteria, not only constants and point formats. We agree, and
-13 was
incomplete in exactly that respect.

Non-canonical encodings

You were right. In -13, Section 5.4 rejected scalars outside [0, r-1] while
Section 5.3
did not check the coordinates at all, and the only mention was the informal
remark in
Section 6 that you found. -14 makes it normative: every GF(p) coefficient
recovered while
deserializing MUST be an integer in [0, p-1], and an implementation MUST
return INVALID
otherwise. The requirement is stated once, in Section 5.4, and covers both
coordinates on
E, recovered with OS2IP, and the coefficients of coordinates on E',
recovered with OS2FE.

Frank Denis, who implemented the draft independently in Zig, raised the
same point, so
the gap is well attested. We also checked what deployed implementations do,
and all three
of the reference implementations we use for test vectors already reject
out-of-range
coordinates: blst in both the compressed and uncompressed paths,
zkcrypto/bls12_381 in
Fp::from_bytes, and gnark-crypto in SetBytesCanonical. All three apply the
check right
after masking the three metadata bits, which is exactly where it belongs.
So this is the
document catching up with practice rather than imposing something new.

The subgroup check: you were right, and -14 merges the two

You asked whether there is a reason for keeping deserialization and the
subgroup check
separate. Having looked into it properly, for this document there is not.

What -13 got wrong is the type. The document defines G_1 and G_2 in Section
2.2, Section
5 spoke of "the output point is on the curve E", and it never said which of
the two the
procedure returned. Your "confusing for implementers" reading was fair.

In -14, deserialization returns an element of G_1 or of G_2, with the
subgroup check
included and the type stated in the name: octets_to_point_G1 and
octets_to_point_G2, in
Section 5.4. Serialization is named to match, point_to_octets_G1 and
point_to_octets_G2,
in Section 5.3. There is no deserialization procedure that stops at E or E'.
subgroup_check_G1 and subgroup_check_G2 are still specified separately, in
Section 5.4.1,
since a point can also arise from addition or scalar multiplication rather
than from
decoding, but decoding always includes the check.

Three things pushed us here.

First, Section 6.2 of draft-irtf-cfrg-bbs-signatures already names this
operation, as
"octets_to_point_G1 or octet_to_point_G2 ... operations that both
deserialize an octet
string to get an elliptic curve point and then check if the resulting point
is part of
the G1 or G2 group", and observes that libraries provide it. So the shape
is not new; it
is what the ecosystem already builds.

Second, that same section exists because the separated form is easy to get
wrong: it says
the subgroup check "is REQUIRED by all implementations" and that "failure
to comply would
lead to unpredicted behavior and vulnerabilities". It also makes the
mathematical point
plainly -- "the pairing operation is undefined when its input points are
not in G1 and
G2" -- which is the honest answer to what a curve point outside G1 is good
for in a
pairing protocol: nothing. On BLS12-381 the G1 cofactor is about 126 bits,
so any such
input is adversarial by construction.

Third, the gap does open in practice. In
draft-irtf-cfrg-bbs-blind-signatures-03,
Section 5.4.2 decodes a commitment with octets_to_point_E1 and checks for
INVALID and for
the identity, but not for subgroup membership, while a structurally
parallel decode later
in the same document does check it. We will raise that with the authors
separately; we
mention it here only because it is the clearest argument for not leaving
the choice to
each call site.

A side effect worth noting: merging also closes an encoding defect we had
on our list.
BLS48-581 has b = 1, so (p-1, 0) is a point of E, and since sign_GF_p(0) =
0 and -0 = 0,
both values of S_bit decoded to it -- two encodings of one point. Its order
is 2, and r is
an odd prime, so octets_to_point_G1 rejects it and the ambiguity disappears.

Since you would be a consumer of this, one question. Rather than wait, we
wrote the text,
so what is left to check is whether the shape is usable as it stands. Would
Section 5.4
let sigma-protocols cite us in Section 8.2.1 for BLS12-381 G1, instead of
restating the
validation steps? "MUST perform full point validation" is what
octets_to_point_G1 does,
subgroup check included. The one item that would still need a sentence on
your side is
the identity: octets_to_point_G1 returns it like any other group element,
and Section
5.6.2 leaves acceptance to the calling protocol, with rejection as the
RECOMMENDED
default -- which is the choice -03 already makes, in "neither produced nor
accepted". If
the shape does not fit what you need, please say so; it is much easier to
adjust before
-14 is posted than after.

On a single interface across drafts

We agree with how you put it in answer 4 -- every specification should
answer the same
checklist and behave predictably, with curve-specific answers -- and -14
answers all four
of your items explicitly: accepted encoding and length in Sections 5.1 and
5.6.1,
rejection of non-canonical field encodings in Section 5.4, curve and
subgroup membership
in Sections 5.4 and 5.4.1, and scalar range in Section 5.2.

On the first of those, a protocol that wants a single exact-length
canonical encoding gets
exactly that. Section 5.6.1 makes the compressed form RECOMMENDED for
transmitted values,
and asks a protocol to state which forms it accepts, noting that accepting
both means one
point has two encodings -- which matters wherever an encoded point is
hashed or compared
as bytes. We stopped short of mandating one form for every user of the
format, because the
uncompressed form remains in use for stored values that are validated once,
where
recovering y from x on every use is not worth the saved space.

On a single low-level interface we are more cautious, and since you allow
for that --
"I do not think every draft necessarily needs to expose the same low-level
API" -- what
follows is our reason rather than a counter-proposal. The reason is
arithmetic rather than
preference. The cofactor structure differs per curve, including within our
own document:
using the parameters in Section 4.2, the G1 cofactor is about 126 bits for
BLS12-381 and
64 bits for BLS48-581, but for BN462 it is exactly 1, so every point of
E(GF(p)) is in G1
and the check is vacuous there. There is also a structural gap:
pairing-based work has
G_T, which Section 2.2 defines as an order-r subgroup of the multiplicative
group of
GF(p^k) rather than a group of curve points, and an EC group interface has
no slot for it.
Section 5 of -14 states its own scope in the same terms: what it encodes
are the objects
that protocols transmit, points on E and E' and scalars, and it does not
define an
encoding for elements of GF(p^k).

That same boundary is why -14 says nothing about your third alignment
point, sampling.
The document defines no operation that produces a scalar, so the choice
between [0, r-1]
and [1, r-1] does not arise in it; Section 5.6.3 covers only the receiving
side, whether a
protocol accepts a zero scalar it has decoded. If you see a reason for a
curve document to
speak to the sampling range as well, we would be glad to hear it.

Identity and zero

Both remain protocol-dependent policies in -14, but they are no longer
coupled.

On identity, the default is already the choice you would make. Section
5.6.2 makes
rejection the RECOMMENDED default, and a protocol that wants it says so in
one sentence.
We stopped short of having deserialization itself reject the identity
element, as you
suggested: octets_to_point_G1 and octets_to_point_G2 return it like any
other group
element, because some protocols do reference the identity element in a
public statement,
and a curve document that rejected it outright would place those outside
the format. If
that balance is wrong, we would rather hear it before the document is
finished than
after.

Section 5.4 of -13 said the zero scalar follows "the same
protocol-dependent policy as
the identity point". That link does not hold: Section 3.1 of RFC 9591
rejects the identity
element on deserialization but accepts zero scalars, so the two are
independent decisions
in at least one existing specification. In -14 they are separate: the
identity element in
Section 5.6.2, the zero scalar in Section 5.6.3.

One note on your survey, offered in case it is useful. RFC 9497 appears on
both sides of
the zero question: Section 2.1 defines RandomScalar as choosing a nonzero
element in
GF(p), while all five ciphersuites in Section 4 implement it as "returning
a uniformly
random Scalar in the range [0, G.Order() - 1]".

A note on -03, which appeared while we were drafting this

Thank you for wiring us in as the normative source for BLS12-381 G1. Two of
the pointers
land in a place we should flag, since -03 cites us by revision and
implementers will
follow them.

Both were right when they were written: through -12 the ZCash serialization
format was
Appendix C, and -13 promoted it into the body as Section 5. We moved it
without telling
anyone, so the drift is ours rather than yours. Section 5 is reorganised
once more in -14,
so the pointers below are the ones we would suggest.

Section 8.2.1, serialize([A]), cites "Appendix C of [PAIRING]". Appendix C
of -13 is
"Test Vectors of Optimal Ate Pairing". In -14 the serialization procedure
is Section
5.3, the per-curve parameters -- including the 48-byte compressed length
you call Ne --
are in Section 5.1, and the serialization test vectors are in Appendix D.
The
appendices themselves did not move between -13 and -14.

Section 2.3.1 cites "Appendix C of [PAIRING]" for the identity requirement.
In -14 that
is Section 5.6.2, "Identity Element".

generator() citing Section 4.2.1 is correct, in -13 and in -14.

Also, Section 8.2.2 defines the scalar field encoding inline: big-endian
I2OSP with
Ns = 32, and deserialization failing unless the result is in [0, order()).
Section 5.2 of
-14, "Scalar Serialization", specifies exactly that for BLS12-381, with the
same byte
order and the same range requirement, so you could cite us there too if
that would be
useful. That material is Section 5.4 in -13.

For reference, Section 5 of -14 is titled "Serialization and Validation"
and is organised
as: 5.1 Parameters and Notation, 5.2 Scalar Serialization, 5.3 Point
Serialization, 5.4
Point Deserialization (with 5.4.1 Subgroup Membership), 5.5 Applicability
to BN462, and
5.6 Requirements on Calling Protocols (5.6.1 Accepted Point Form, 5.6.2
Identity Element,
5.6.3 Zero Scalar).

Two practical notes on citing us, offered so that you have to change these
pointers only
once. Issues are still open against the document, and some of them could
move section
numbers again, so we would suggest updating the pointers after -14 is
posted rather than
now. And if you cite the section name alongside the number -- for example,
Section 5.3
("Point Serialization") of [PAIRING] -- the reference stays followable
through any later
renumbering. We will tell this list whenever section numbers move, and we
will send the
final ones for -14 when it is posted; we are notifying the other documents
that cite us as
well.

Best regards,
Yumi

On Mon, Aug 03, 2026 08:22 AM, Michele Orrù <[e-mail]> wrote:

> Hi Yumi,
>
> Apologies for the late reply, and thank you for starting this thread.
> Let me answer your questions directly, and then summarize the
> potential security concerns with the different group abstractions. I
> believe the second part may also be useful to the editors of:
>
> - draft-irtf-cfrg-cpace
> - draft-irtf-cfrg-bbs-*
> - draft-google-cfrg-libzk
>
> This is my personal view, not that of the editors of the
> sigma-protocols specification.
>
> 1. Since raising the issue of incompatible group abstractions across
> CFRG drafts at IETF 125, I have written my own interface and
> considerations to make sigma-protocols self-contained [12]. The curve
> document should (ideally) specify not only the curve constants and the
> point format but also validation criteria (see below).
> 2. Should pairing-friendly-curves be the normative source of order(),
> serialize(), and deserialize() for sigma-protocols? For BLS12-381:
> yes, and this was addressed in draft -13, Section 5. I need only G1
> for now.
> 3. This point no longer applies in the current specification; I don't
> recall why I raised it (sorry).
> 4. Curve-specific definitions suffice. What matters is that each
> curve's specification answers the same checklist and behaves
> predictably (see below).
>
> I am comfortable with PR #71 [14] remaining on hold, or being closed
> in favor of Section 5 / issue #74 [15].
>
> Now for the longer part, I'd like to make a plea to the wider
> community to commit to a single EC group interface.
>
> A specification should define:
>
> - the exact accepted encoding and length (see identity discussion);
> - whether non-canonical field encodings are rejected;
> - whether curve membership and prime-order subgroup membership are checked;
> - the accepted scalar range.
>
> If we could align all drafts, I would pick the following:
>
> - Point decoding accepts only an exact-length canonical point
> encoding, checks curve membership and membership in the intended
> prime-order subgroup, and has an explicit identity policy (rejection
> seems the easiest, even if this will make some ZK use cases weird;
> padding is an alternative).
> - Scalar decoding accepts only canonical encodings of integers in [0,
> r - 1], where r is the prime subgroup order.
> - Sampling APIs distinguish between sampling from [0, r - 1] and
> sampling from [1, r - 1].
>
> I do not think every draft necessarily needs to expose the same
> low-level API, but they should share a common, exact and predictable
> behavior.
> A longer description follows.
>
> # Subgroup membership check on deserialization
>
> The pairing line (BBS §1.2 [6], BLS §1.3 [9]) treats checking that a
> point lies in the prime-order subgroup as a separate operation
> (subgroup_check), not guaranteed by deserialization (octets_to_point);
> pairing-friendly-curves-13 likewise validates only curve membership on
> deserialization (§5.3) and leaves the subgroup check to the receiver
> (§6) [10].
> The VOPRF line (RFC 9497 [1]; sigma-protocols §2.3.1 [12]) requires
> deserialization to reject inputs outside the prime-order subgroup.
>
> This split is confusing for implementers. Is there a reason for
> keeping the two operations separate?
>
> # Non-canonical encodings
>
> When parsing a byte string encoding an integer mod p, the obvious
> choice is that implementations MUST reject integers >= p.
>
> RFC 9496 §4.3.1 (with the App. A.2 test vectors) tests rejection for
> group elements, but scalar range checks are only a SHOULD (§4.4) [4].
> pairing-friendly-curves-13 checks scalars (§5.4) but leaves point
> coordinates unchecked (§5.3), with only an informal remark in §6 [10].
> cpace-21 (§8.2, inheriting RFC 7748 §5) requires implementations to
> accept non-canonical values and reduce them mod p [5].
>
> # Identity handling
>
> - In RFC 9497, DeserializeElement may fail on the identity, and every
> currently defined ciphersuite rejects it [1]. The OPRF portion of
> OPAQUE inherits this group interface [3].
> - RFC 9591 rejects the identity during both serialization and
> deserialization [2].
> - RFC 9496 treats the identity as a valid group element, with a
> canonical all-zero encoding [4].
> - sigma-protocols rejects the identity during group-element
> deserialization [12].
> - BBS's protocol-level signature, proof, and public-key decoders
> reject the identity, although its lower-level curve-point decoder
> accepts the canonical identity encoding [6].
> - pairing-friendly-curves §5.5 makes identity handling
> protocol-dependent and recommends rejection as the default [10].
>
> # Zero scalars
>
> pairing-friendly-curves-13 leaves zero to a protocol-dependent policy
> (§5.5) [10], while RFC 9497 §2.1 [1], FIPS 186-5 [16], and RFC 6979
> [17] define sampling as nonzero, and RFC 9591 §3.1 [2] and libzk [11]
> include zero. This is a minor issue now since the field characteristic
> is very large, but it could become harder to deal with once we move to
> smaller fields.
>
> [1] RFC 9497 (VOPRF), Section 2.1, "Prime-Order Group"
> https://www.rfc-editor.org/rfc/rfc9497#section-2.1
>
> [2] RFC 9591 (FROST), Section 3.1, "Prime-Order Group"
> https://www.rfc-editor.org/rfc/rfc9591#section-3.1
>
> [3] RFC 9807 (OPAQUE), Section 2.1
> https://www.rfc-editor.org/rfc/rfc9807#section-2.1
>
> [4] RFC 9496 (ristretto255 and decaf448), Sections 3, 4.3, and 5.3
> https://www.rfc-editor.org/rfc/rfc9496#section-3
>
> [5] draft-irtf-cfrg-cpace-21, Sections 6 and 8
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-cpace-21
>
> [6] draft-irtf-cfrg-bbs-signatures-10
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bbs-signatures-10
>
> [7] draft-irtf-cfrg-bbs-blind-signatures-03
>
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bbs-blind-signatures-03
>
> [8] draft-irtf-cfrg-bbs-per-verifier-linkability-03
>
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bbs-per-verifier-linkability-03
>
> [9] draft-irtf-cfrg-bls-signature-07, Section 1.3
>
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-bls-signature-07#section-1.3
>
> [10] draft-irtf-cfrg-pairing-friendly-curves-13, Sections 4–6
>
> https://datatracker.ietf.org/doc/html/draft-irtf-cfrg-pairing-friendly-curves-13
>
> [11] draft-google-cfrg-libzk-02, Section 2
> https://datatracker.ietf.org/doc/html/draft-google-cfrg-libzk-02#section-2
>
> [12] draft-irtf-cfrg-sigma-protocols, editor's copy
>
> https://mmaker.github.io/draft-irtf-cfrg-sigma-protocols/draft-irtf-cfrg-sigma-protocols.html
>
> [13] draft-irtf-cfrg-fiat-shamir, editor's copy
>
> https://mmaker.github.io/draft-irtf-cfrg-sigma-protocols/draft-irtf-cfrg-fiat-shamir.html
>
> [14] pairing-friendly-curves PR #71
> https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/pull/71
>
> [15] pairing-friendly-curves issue #74
> https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/issues/74
>
> [16] FIPS 186-5, Digital Signature Standard (DSS)
> https://csrc.nist.gov/pubs/fips/186-5/final
>
> [17] RFC 6979, Deterministic Usage of DSA and ECDSA
> https://www.rfc-editor.org/rfc/rfc6979
>
> Best,
> --
> Michele
>
> On Sat, Jul 18, 2026 at 8:32 AM Yumi Sakemi <[e-mail]>
> wrote:
> >
> > Hi Michele,
> >
> > We wanted to bring a question from GitHub PR #71
> > (add sketch interface for elliptic curves and scalars,
> > https://github.com/cfrg/draft-irtf-cfrg-pairing-friendly-curves/pull/71
> > )
> > to the list, since the discussion has so far only happened there, and
> the scope may be of interest to others in the RG working on related specs.
> >
> > The PR proposes adding a Group/Scalar abstraction to
> draft-irtf-cfrg-pairing-friendly-curves, closely mirroring the interface
> already defined in draft-irtf-cfrg-sigma-protocols (Section
> {{group-abstraction}}). We want to make sure we understand the intended use
> before shaping this addition, so a few clarifying questions:
> >
> > 1. Since sigma-protocols already defines its own self-contained
> Group/Scalar interface and (as far as we can tell) doesn't rely on the
> pairing operation itself, could you help us understand what gap in PFC this
> is meant to fill?
> >
> > 2. We noticed sigma-protocols currently has a fully-specified
> ciphersuite only for P-256, while test vectors already exist for
> sigma-proofs(BLS12-381, SHAKE128). Is the goal for PFC to become the
> normative source for BLS12-381's (G1) order()/serialize()/deserialize(), so
> that a future BLS12-381 ciphersuite section in sigma-protocols could cite
> PFC directly rather than re-deriving these the way it does for P-256? If
> so, would this be scoped to G1 only, or would you also need it for G2
> and/or the other curves in our set (BN462, BLS48-581)?
> >
> > 3. On the comment that "the split between EC interfaces and Field
> interfaces creates confusion in the Fiat-Shamir spec" — could you point us
> to where this shows up concretely? We noticed draft-irtf-cfrg-fiat-shamir's
> Codec section describes elliptic-curve operations as free functions over a
> "coordinate field"/"scalar field" (e.g. ecpoint_to_bytes, absorb_scalars),
> which reads a bit differently from the object-style Group/Scalar interface
> used in sigma-protocols. Is that the inconsistency you're referring to, or
> is it something else?
> >
> > 4. Relatedly, our normative point-serialization work (#74) is
> necessarily curve-specific — for instance BN462 needs a different encoding
> than the Zcash-style flag-bit scheme we use for BLS12-381 and BLS48-581.
> Would per-curve point_to_octets/octets_to_point definitions (already
> underway) meet what you need for sigma-protocols, or is there a more
> abstract, interface-level definition you're after independent of that work?
> >
> > We're happy to continue on GitHub or here, whichever is easier — just
> want to make sure whatever we add actually serves the downstream need.
> >
> > Best regards,
> > Yumi
>