Summary

  • CFRG released revision 14 of draft-irtf-cfrg-pairing-friendly-curves on 7 September 2026. It is an active IRTF research-group Internet-Draft intended for Informational publication, not an RFC or an IETF standard.
  • The revision supplies normative point serialization and deserialization for BLS12-381 and BLS48-581, plus scalar procedures for those curves and BN462. Its decoder checks canonical coordinates, curve validity and subgroup membership before returning a group element or INVALID.
  • A valid common decoding does not finish the protocol contract. The calling specification must state which point form it accepts and decide independently whether identity elements and zero scalars are admissible.
  • Revision 14 removes revision 13’s universal “recommended default” against the identity and no longer folds zero-scalar treatment into the same policy. It also deliberately leaves BN462 point encoding undefined because the surveyed implementation practice has not converged.
  • Daniel Kade proposes that every dependent specification publish a compact acceptance profile. That profile is an analytical recommendation, not a requirement of the draft or CFRG.

A valid point is not yet a valid protocol message

Cryptographic specifications often compress two different questions into the verb validate. The first is mathematical: do these bytes name one canonical field element, a point on the intended curve and a member of the correct subgroup? The second is contractual: does this protocol admit that otherwise valid value in this position?

Revision 14 draws a sharper line between them. Its point deserializers accept bytes and return either a group element or INVALID. They reject the wrong length and inconsistent metadata. They reject a coordinate at or above the field modulus rather than silently reducing it. They test whether the reconstructed point lies on the selected curve and in the required subgroup. Even where two point types have the same encoded length, the procedures keep the curve domains distinct.

For scalars, the rule is similarly canonical: the encoded integer must be below the scalar-field order. Zero has one legitimate encoding. Whether the calling protocol permits zero is not part of that canonicality test.

This is the governance seam. A reusable document can settle the shared representation and still leave an application with a smaller admissible language. Conformance to the decoder is therefore necessary but not sufficient for interoperability between two implementations of the calling protocol.

Revision 14 separates three choices that revision 13 blurred

The first choice is the accepted point form. Revision 14 tells a calling protocol to state whether it accepts compressed points, uncompressed points or both. Dual acceptance is not a cosmetic convenience. It means one mathematical point can arrive in two valid byte strings. If an application hashes the received bytes, signs them, compares them directly or uses them as a cache or database key, two implementations can agree on the point and disagree on the object.

The second choice is the identity element. Some constructions have a semantic reason to reject it. The BLS signature draft’s key-validation procedure, for example, excludes the identity in connection with the invalid zero secret key and identity-signature case. Other constructions may place an identity in a legitimate algebraic role. Revision 14 consequently leaves the decision to the construction and its threat model.

The third choice is the zero scalar, and it is independent. Revision 13 described identity rejection as the recommended default and tied zero treatment to the same protocol-dependent policy. Revision 14 removes that universal recommendation and pulls the scalar question apart. RFC 9591 offers a useful demonstration of why: its element decoder rejects identity elements, while its scalar decoder does not add an equivalent zero rejection.

These are not three alternative ways to express one switch. A protocol may accept one point form, reject identity and accept zero; another may accept both forms, admit identity in one field and reject zero in another. The common curve decoder cannot infer those semantics.

BN462 marks the limit of the common format

The revision is also explicit about what it does not standardize. It defines point serialization for BLS12-381 and BLS48-581 but not for BN462. BN462’s base-field modulus uses 462 bits. A 58-byte container provides 464 bits, leaving two spare bits, while the common compressed-point layout needs three pieces of metadata.

The draft’s informative survey records incompatible approaches in existing software: a SEC1-style type byte, a separate flag byte, and packed formats without the same metadata convention. The authors say the specifications they examined do not require a BN462 point encoding and that deployed practice has not converged. Their decision is therefore to leave that point format outside the normative common route.

That restraint should not be exaggerated. It does not mean BN462 has no implementations, that any surveyed format is insecure, or that existing deployments must be rewritten. It means a calling protocol that needs BN462 points cannot cite revision 14 alone as a complete wire-format contract. It must name another encoding specification or define its own convention.

The calling specification owns the last metre

The development record shows why the split matters. CFRG issue 74 asked for an authoritative serialization definition rather than inconsistent copies scattered across dependent documents. Pull request 108 carried the substantial rewrite into revision 14, adding named procedures, clearer membership checks, calling-protocol decisions and test-vector work. CFRG list correspondence alerted authors of dependent specifications to the new section. The BBS signatures and COSE BLS key-representation drafts illustrate that this dependency is practical rather than hypothetical.

Centralizing the mathematical rules reduces one class of drift. It cannot centralize application semantics without overruling the applications. The minimum common layer should be small enough to be stable and precise; local decisions can remain local, but only if they are visible. An unrecorded local choice is not modularity. It is an undocumented fork.

For that reason, I would require each calling specification to publish an acceptance profile containing seven entries: the referenced curve-document revision, the curve, the admitted point form or forms, the identity rule, the zero-scalar rule, the subgroup-validation route and—when BN462 points are used—the exact external encoding reference. An implementation can then expose that tuple in tests and compatibility reports.

This acceptance profile is my proposal. Revision 14 neither names nor mandates it. Its value is administrative: it converts three prose choices and one deliberate omission into a configuration that reviewers can compare before code reaches a network boundary.

Sources