摘要

  • CFRG于2026年9月7日发布draft-irtf-cfrg-pairing-friendly-curves第14版。它仍是IRTF研究组名下、拟作为Informational文档发布的活跃Internet-Draft，不是RFC，也不是IETF标准。
  • 新版为BLS12-381和BLS48-581规定点的规范性序列化与反序列化流程，并为这两条曲线及BN462规定标量流程。解码器在返回群元素或INVALID之前，要检查规范坐标、曲线归属和子群成员资格。
  • 共同解码并未写完协议合同。调用协议还要声明接收压缩点、非压缩点还是两者，并分别决定是否接纳单位元、是否接纳零标量。
  • 与第13版相比，第14版取消“默认建议拒绝单位元”的普遍立场，把零标量从单位元政策中拆开，并新增点形式的明确选择。由于现有实践未收敛，它也有意不定义BN462点的规范编码。
  • Daniel Kade建议每个下游规范公布一份七字段“接纳档案”。这是本文的治理分析，不是CFRG或草案提出的要求。

数学上有效，协议里仍可能无效

密码协议里的“验证”经常混合两项工作。第一项是数学验证：字节长度和元数据位是否正确，坐标是否采用唯一的规范表示，重建出的点是否位于指定曲线上并属于要求的子群。第二项是语义验证：即使这个群元素完全有效，本消息位置是否允许它出现。

第14版把第一项写得更明确。点反序列化过程只能返回群元素或INVALID。它不会把大于等于域模数的坐标先取模再继续，而是直接拒绝，从而避免同一坐标出现多种字节表示。它会检查曲线方程和子群；即使两个点类型的编码长度相同，也不能因此混用解码路径。

标量的规范性同样清楚：编码整数必须小于标量域的阶。全零字节对应一个规范的零标量，但“存在唯一编码”与“允许在这里使用”是两回事。通用解码器不知道这个字段是私钥、挑战值、系数，还是允许出现加法单位元的中间量。

因此，两套实现可以都正确执行第14版的数学检查，却在调用协议层失去互操作性。一套在解码后拒绝某个值，另一套接纳；或者两套都接纳同一点，却把接收到的不同字节形式当成不同对象。共同规范只解决了边界的一半。

三个开关不能压成一个“非零检查”

第一项决定是点形式。第14版要求调用协议说明：只接收压缩点、只接收非压缩点，还是两者皆可。两者皆可并非单纯节省或增加带宽。它意味着同一个数学点可能有两串合法字节。如果应用直接散列、签名、比较这些输入字节，或者以它们作为数据库键和缓存键，表示差异就会穿过数学层进入系统状态。

第二项决定是单位元。某些构造有明确理由拒绝它。BLS签名草案的KeyValidate就不允许单位元，这与无效的零私钥以及单位元签名情形有关。但在另一种代数构造里，单位元可能有合法用途。第14版因而不再给出适用于一切协议的默认结论，而是把判断交给具体语义和威胁模型。

第三项决定是零标量，而且它独立于单位元。第13版把拒绝单位元称为建议默认值，并称零标量沿用相同的协议政策。第14版拆开二者。RFC 9591给出一个很实用的对照：它的元素反序列化拒绝单位元，标量反序列化却没有附加同等的零值拒绝。

这三项决定不存在固定组合。某协议可以只收压缩点、拒绝单位元，却在特定字段允许零；另一协议可以接收两种点形式，在某项运算中允许单位元，同时拒绝零标量。把它们合并成密码库中的一个“严格模式”开关，等于让库替协议做了一项没有授权的治理决定。

BN462显示共同格式的止步处

第14版为BLS12-381和BLS48-581定义点编码，却没有为BN462做同样的事。BN462的基域模数占462位；58字节共464位，只剩两个空闲位，而共同压缩格式需要携带三项元数据。

草案的资料性附录列出互不兼容的现有做法：使用类似SEC1的类型字节，另设一个标志字节，或者采用不沿用同一元数据约定的紧凑格式。作者表示，他们审查的规范并不要求BN462点编码，现实实践也尚未收敛，因此没有把任一方案写成规范性共同路径。

这不是在说BN462没有实现，也不是判定某种编码不安全，更不意味着所有现有软件必须修改。它只划清引用的效力：如果一个调用协议需要在网络上传输BN462点，单独引用第14版不够，它还必须精确指出另一个编码规范，或自行完整定义所采用的约定。

地方决定可以保留，但不能隐身

开发记录解释了这次重写的由来。CFRG代码库的issue 74要求形成一处权威序列化定义，避免相关规范各自复制后逐渐分叉。pull request 108把命名流程、子群检查、调用协议决定和测试向量等改动带入第14版。CFRG邮件列表上的编辑说明则提醒依赖文档的作者关注新章节。BBS签名草案和COSE的BLS密钥表示草案说明，这类依赖不是抽象设想。

把数学表示集中到一份小而明确的共同规范，可以减少一种漂移；它却不应越权替各个应用决定语义。按照最小共同规范、未来决定本地化的思路，本地选择完全可以不同。关键是把选择写出来。只存在于库默认值中的本地决定，不是模块化，而是一条没有文档的分叉。

我建议每个调用规范公布一份“接纳档案”，至少列出七项：所引用曲线文档的确切版本、曲线、允许的点形式、单位元规则、零标量规则、子群验证路径，以及在使用BN462点时采用的外部编码依据。实现方可把同一组字段放进互操作测试和兼容性报告。

“接纳档案”这个名称和七字段结构是Daniel Kade的建议，第14版并未要求。它的作用不是统一所有本地决定，而是让评审者在代码进入网络边界之前，看见决定由谁作出、版本是什么、哪一项仍没有共同答案。

来源