Skip to main content

11. IANA Considerations

  1. IANA Considerations

The registries and registrations listed below were defined by RFC 8152 [RFC8152]. The majority of the following actions are to update the references to point to this document.

Note that while [RFC9053] also updates the registries and registrations originally established by [RFC8152], the requested updates are mutually exclusive. The updates requested in this document do not conflict or overlap with the updates requested in [RFC9053], and vice versa.

11.1. COSE Header Parameters Registry

The "COSE Header Parameters" registry was defined by [RFC8152]. IANA has updated the reference for this registry to point to this document instead of [RFC8152]. IANA has also updated all entries that referenced [RFC8152], except "counter signature" and "CounterSignature0", to refer to this document. The references for "counter signature" and "CounterSignature0" continue to reference [RFC8152].

11.2. COSE Key Common Parameters Registry

The "COSE Key Common Parameters" registry [COSE.KeyParameters] was defined in [RFC8152]. IANA has updated the reference for this registry to point to this document instead of [RFC8152]. IANA has also updated the entries that referenced [RFC8152] to refer to this document.

11.3. Media Type Registrations

11.3.1. COSE Security Message

IANA has registered the "application/cose" media type in the "Media Types" registry. This media type is used to indicate that the content is a COSE message.

Type name: application

Subtype name: cose

Required parameters: N/A

Optional parameters: cose-type

Encoding considerations: binary

Security considerations: See the Security Considerations section of RFC 9052.

Interoperability considerations: N/A

Published specification: RFC 9052

Applications that use this media type: IoT applications sending security content over HTTP(S) transports.

Fragment identifier considerations: N/A

Additional information: * Deprecated alias names for this type: N/A

  *  Magic number(s): N/A

  *  File extension(s): cbor

  *  Macintosh file type code(s): N/A

Person & email address to contact for further information: [email protected]

Intended usage: COMMON

Restrictions on usage: N/A

Author: Jim Schaad

Change Controller: IESG

Provisional registration? No

11.3.2. COSE Key Media Type

IANA has registered the "application/cose-key" and "application/cose- key-set" media types in the "Media Types" registry. These media types are used to indicate, respectively, that the content is a COSE_Key or COSE_KeySet object.

The template for "application/cose-key" is as follows:

Type name: application

Subtype name: cose-key

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

Security considerations: See the Security Considerations section of RFC 9052.

Interoperability considerations: N/A

Published specification: RFC 9052

Applications that use this media type: Distribution of COSE-based keys for IoT applications.

Fragment identifier considerations: N/A

Additional information: * Deprecated alias names for this type: N/A

  *  Magic number(s): N/A

  *  File extension(s): cbor

  *  Macintosh file type code(s): N/A

Person & email address to contact for further information: [email protected]

Intended usage: COMMON

Restrictions on usage: N/A

Author: Jim Schaad

Change Controller: IESG

Provisional registration? No

The template for registering "application/cose-key-set" is:

Type name: application

Subtype name: cose-key-set

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: binary

Security considerations: See the Security Considerations section of RFC 9052.

Interoperability considerations: N/A

Published specification: RFC 9052

Applications that use this media type: Distribution of COSE-based keys for IoT applications.

Fragment identifier considerations: N/A

Additional information: * Deprecated alias names for this type: N/A

  *  Magic number(s): N/A

  *  File extension(s): cbor

  *  Macintosh file type code(s): N/A

Person & email address to contact for further information: iesg@ietf .org

Intended usage: COMMON

Restrictions on usage: N/A

Author: Jim Schaad

Change Controller: IESG

Provisional registration? No

11.4. CoAP Content-Formats Registry

IANA added entries to the "CoAP Content-Formats" registry as indicated in [RFC8152]. IANA has updated the reference to point to this document instead of [RFC8152].

11.5. CBOR Tags Registry

IANA added entries to the "CBOR Tags" registry as indicated in [RFC8152]. IANA has updated the references to point to this document instead of [RFC8152].

11.6. 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