Summary

  • 摘要。IANA 的 SFrame 登记表标注最后更新于 2026 年 5 月 5 日。表中有 Nh、Nka、Nk、Nn、Nt 五列尺寸，并把 0x0006 至 0x0008 分给 AES-256-CTR/HMAC-SHA512 的三种标签长度。三行的 Recommended 都是 Y，引用仍是草案第 06 版的临时标识。
  • IETF 文件记录显示该草案还在 RFC Editor 队列。登记完成、RFC 编号落定、软件支持和实际通话采用，是四份不同的收据。

五列数字把“支持”变成可检查的尺寸

现行 RFC 9605创设 SFrame 密码套件表时，列出编号、名称、是否推荐、参考文件和变更控制者。密钥、nonce 和认证标签的长度散见规范正文。后续草案要求把其中五项直接写进 IANA 公表：哈希输出长度 Nh，复合加密方案中底层加密密钥长度 Nka，加密密钥长度 Nk，nonce 长度 Nn，以及通常由标签构成的额外字节数 Nt。这让表格从编号目录变成参数核对表。

表格已经照此改动。旧的五种套件填上了对应尺寸；新三行的 Nh 均为 64 字节、Nka 为 32、Nk 为 96、Nn 为 12，Nt 则分别是 10、8、4。草案解释，相比 AES-128-CTR/HMAC-SHA256 所需的 48 字节 SFrame 内部派生材料，新构造使用 96 字节；计算标签时的初始值从 32 字节变为 64。附录还提供测试向量。工程师可以据此测试实现是否按正确尺寸处理，而不必把“256 位”当成一张含混的品质贴纸。

另一个小字母更像治理开关：Y。RFC 9605 规定，普通的 Specification Required 登记默认是 N；把套件标为 Y 或 D，或者修改已有的这类推荐，需要 Standards Action。IETF 的修订历史记录了 4 月关于文档 Standards Track 身份与推荐套件分配是否一致的讨论。这个过程解释了为什么表格可以写 Y。它不替任何应用选择套件，也不审查某次通话的密钥处理。

临时引用已经住进正式登记表

三个新编号的参考栏写着 RFC-barnes-sframe-iana-256-06。这是有意保留的临时指向，不是最终 RFC 号。草案第 06 版日期为 5 月 4 日，IANA 表格的最近更新日期为 5 月 5 日。到 10 月 28 日，Datatracker 仍将文件列为 RFC 编辑队列，IANA 动作状态为 RFC-Ed-Ack。公众今天就能核对这些编号和尺寸；正式出版的文件仍在另一条时间线上。

应用的时间线又不同。RFC 9605 把何时开启 SFrame、选择哪种密码套件交给应用自身。其安全章节还指出，短认证标签需要额外措施抵御伪造尝试，使用完整长度的标签通常更省事。新表格列出的 10、8、4 字节标签，正好把这种选择具体化。四字节标签在登记表里是一个参数；放进产品后，它就牵动密钥、重放与伪造防护的设计。表格不会替开发团队承担这一部分工作。

所查官方文件没有给出采用这些新编号的具体产品、媒体会话或部署记录。最终编号的 RFC、产品配置和运行测试会改变这项判断。目前能确证的是：公众已经有了一张写明编号、尺寸、引用和变更控制者的表。