跳到主要内容

10. IANA 考量

  1. IANA 考量

IANA 已更新除 "COSE Header Parameters" 和 "COSE Key Common Parameters" 之外的所有 COSE 注册表, 使其指向本文档而不是 [RFC8152].

10.1. 对 "COSE Key Types" 注册表的变更

IANA 已在 "COSE Key Types" 注册表中添加一列. 新列标记为 "Capabilities", 并已根据表 22 中的条目填充.

        +=======+===========+============================+
| Value | Name | Capabilities |
+=======+===========+============================+
| 1 | OKP | [kty(1), crv] |
+-------+-----------+----------------------------+
| 2 | EC2 | [kty(2), crv] |
+-------+-----------+----------------------------+
| 3 | RSA | [kty(3)] |
+-------+-----------+----------------------------+
| 4 | Symmetric | [kty(4)] |
+-------+-----------+----------------------------+
| 5 | HSS-LMS | [kty(5), hash algorithm] |
+-------+-----------+----------------------------+
| 6 | WalnutDSA | [kty(6), N value, q value] |
+-------+-----------+----------------------------+

表 22: Key Type Capabilities

10.2. 对 "COSE Algorithms" 注册表的变更

IANA 已在 "COSE Algorithms" 注册表中添加一列. 新列标记为 "Capabilities", 并已为所有当前的非临时注册填充 "[kty]".

IANA 已更新 "COSE Algorithms" 注册表中的 Reference 列, 对于此前尚未包含本文档的所有行, 都将本文档作为引用加入.

IANA 已向 "COSE Algorithms" 注册表添加新行.

+===============+=======+===============+===========+=============+
| Name | Value | Description | Reference | Recommended |
+===============+=======+===============+===========+=============+
| IV-GENERATION | 34 | For doing IV | RFC 9053 | No |
| | | generation | | |
| | | for symmetric | | |
| | | algorithms. | | |
+---------------+-------+---------------+-----------+-------------+

表 23: COSE Algorithms 注册表中的新条目

此注册的 Capabilities 列为空.

10.3. 对 "COSE Key Type Parameters" 注册表的变更

IANA 已把 "Key Type" 为 1 且 "Name" 为 "x" 的行的描述修改为 "Public Key". 见已按此变更修改的表 20.

10.4. Expert Review 指示

[RFC8152] 建立的所有 IANA 注册表至少部分定义为 Expert Review [RFC8126]. 本节给出专家应关注事项的一些一般指导, 但指定他们为专家是有原因的, 因此应给予他们相当大的裁量空间.

Expert reviewers 应考虑以下事项:

  • 应阻止 point squatting. 鼓励评审者为注册请求获取足够信息, 以确保该用途不会重复已有注册, 且该 code point 很可能会在部署中使用. 标记为 private use 的范围旨在用于测试目的和封闭环境; 其他范围中的 code point 不应为测试而分配.

  • 在 Standards Action 范围内注册 code point 需要 Standards Track 或 BCP RFC. Specification Required 范围应有规范, 但在 RFC 可用之前进行早期分配被认为是允许的. 对于 first-come, first-served 范围, 如果预期这些点会以可互操作方式在封闭环境之外使用, 则需要规范. 未提供规范时, 所提供的描述需要包含足够信息, 以识别该点用于什么目的.

  • 专家在批准 code point 分配时应考虑字段的预期用途. Standards Action 范围仅供 Standards Track 文档使用这一事实, 并不意味着 Standards Track 文档不能分配该范围之外的点. 应权衡编码值长度, 该长度剩余多少 code point, 以及其将用于的设备大小.

  • 注册算法时, 应阻止 vanity registrations. 一种做法是要求注册方提供关于该算法安全分析的额外文档. 另一个应考虑的事项是向 Crypto Forum Research Group (CFRG) 请求关于该算法的意见. 算法预期满足社区的安全要求以及消息结构的要求, 才适合注册.