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

[David Waite <[e-mail]>]

> On Dec 12, 2025, at 9:25 AM, Nick Sullivan <[e-mail]> wrote:
> 
<snip>

> 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?
WRT serialization around BLS-12-381:

- draft-irtf-cfrg-bbs-signatures-09 appendix B.2 duplicates the point encoding and decoding, and the algorithm uses this binary representation to serialize points as messages in the signature algorithm (with constraints, discussed below under the curve selection topic)

- draft-ietf-cose-bls-key-representations-08 references this, and also applies a delta to the BBS definition as the prescribed way to represent BLS48-581 points in JWK/CWK documents

- draft-irtf-cfrg-bls-signature-06 instead references a historical version of a rust crate README.

Also, the document originally referenced by paring-friendly-curves for the ZCash work (for its own appendix describing this representation) appears to have moved or disappeared - I believe because the above mentioned README.md has since been edited.

It would be great if we could reference this representation definitively in one place, without indicating ZCash as a possibly more authoritative work, and ideally without other dependent specs needing to constrain or expand upon the format. I don’t think any of the three documents I’ve referenced above are ideal though - I think that the serialization should be in this document or one split out from it.

My preference as an implementor would be not to split out the point representation - or to have pairing-friendly-curves normatively reference the document that these were split into. As much as possible we should encourage a single serialization for valid points on a particular curve.

I suspect such representations are also useful for documenting and leveraging test vectors.

> 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?
draft-irtf-cfrg-pairing-friendly-curves draft 10 dropped the definition of BLS48-581 - I couldn’t immediately see why. However the bls-key-representations draft expects to reference the BLS48-581 curve definition from pairing-friendly-curves - so bls-key-representations no longer has a clear reference path to the curve parameters used for BLS48-581.

BBS does not create a crypto suite leveraging BLS48-581 currently, and I don’t know whether there is a need for BLS48-581 elsewhere (i.e. whether it was supported by bls-key-representations only because prior drafts of friendly-curves defined it).

<snip>

> 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?
My take is that we should have a single encoding function per curve that produces fixed-length, compressed, non-identity elements - and a decoding function that fails on uncompressed and identity elements.

In the BLS case, that encoding should be a subset of the ZCash-based serialization, restricting that “C" is always 1 and “I" is always 0. BBS I believe constrains the algorithm to only support compressed points, but does not constrain serializing infinity.

Applications could still have their own binary representation of infinity if they needed it. However, implementations of the deserialization algorithm could by default avoid infinity and non-curve points in the cases where they are not valid.

We could also define a consistent bit prefix scheme for various curves as well (that happens to be compatible with the zcash subset when the field is 5 mod 8), possibly as simple as a leading sign bit on an X value, itself prefixed by a leading 1 and an appropriate number of zeros as needed to byte-align. I don’t have any delusions that such a serialization would “win” when a curve is coming from work within another community which has already defined their own representations, however.

<snip>

-DW