Skip to main content

10. IANA Considerations

  1. IANA Considerations

IANA has updated all COSE registries except for "COSE Header Parameters" and "COSE Key Common Parameters" to point to this document instead of [RFC8152].

10.1. Changes to the "COSE Key Types" Registry

IANA has added a new column in the "COSE Key Types" registry. The new column is labeled "Capabilities" and has been populated according to the entries in Table 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] |
        +-------+-----------+----------------------------+

                 Table 22: Key Type Capabilities

10.2. Changes to the "COSE Algorithms" Registry

IANA has added a new column in the "COSE Algorithms" registry. The new column is labeled "Capabilities" and has been populated with "[kty]" for all current, nonprovisional registrations.

IANA has updated the Reference column in the "COSE Algorithms" registry to include this document as a reference for all rows where it was not already present.

IANA has added a new row to the "COSE Algorithms" registry.

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

        Table 23: New entry in the COSE Algorithms registry

The Capabilities column for this registration is to be empty.

10.3. Changes to the "COSE Key Type Parameters" Registry

IANA has modified the description to "Public Key" for the line with "Key Type" of 1 and the "Name" of "x". See Table 20, which has been modified with this change.

10.4. Expert Review Instructions

All of the IANA registries established by [RFC8152] are, at least in part, defined as Expert Review [RFC8126]. This section gives some general guidelines for what the experts should be looking for, but they are being designated as experts for a reason, so they should be given substantial latitude.

Expert reviewers should take the following into consideration:

  • Point squatting should be discouraged. Reviewers are encouraged to get sufficient information for registration requests to ensure that the usage is not going to duplicate an existing registration and that the code point is likely to be used in deployments. The ranges tagged as private use are intended for testing purposes and closed environments; code points in other ranges should not be assigned for testing.

  • Standards Track or BCP RFCs are required to register a code point in the Standards Action range. Specifications should exist for Specification Required ranges, but early assignment before an RFC is available is considered to be permissible. Specifications are needed for the first-come, first-served range if the points are expected to be used outside of closed environments in an interoperable way. When specifications are not provided, the description provided needs to have sufficient information to identify what the point is being used for.

  • Experts should take into account the expected usage of fields when approving code point assignment. The fact that the Standards Action range is only available to Standards Track documents does not mean that a Standards Track document cannot have points assigned outside of that range. The length of the encoded value should be weighed against how many code points of that length are left and the size of device it will be used on.

  • When algorithms are registered, vanity registrations should be discouraged. One way to do this is to require registrations to provide additional documentation on security analysis of the algorithm. Another thing that should be considered is requesting an opinion on the algorithm from the Crypto Forum Research Group (CFRG). Algorithms are expected to meet the security requirements of the community and the requirements of the message structures in order to be suitable for registration.

Last updated on