RFC 9596

CBOR Object Signing and Encryption (COSE) "typ" (type) Header Parameter

📅 published June 2024, from ietf

Heading

Okay bestie, this is RFC 9596 and it's giving explicit typing for COSE 🦋✨

Title block: Internet Engineering Task Force (IETF), M.B. Jones (Self-Issued Consulting) and O. Steele (Transmute) 🎀. It's a Standards Track doc, ISSN 2070-1721, dated June 2024 🌸. It doesn't obsolete or update anything, so it's a clean new spec 💅.

CBOR Object Signing and Encryption (COSE) "typ" (type) Header Parameter 👑

Abstract

Okay so this spec adds the COSE version of the JOSE "typ" (type) header parameter 💖. That means COSE objects can get the same explicit typing perks that RFC 8725 ("JSON Web Token Best Current Practices") gave JWTs, and that's lowkey iconic 🧚. The syntax of the COSE type header parameter value is the same as the existing COSE content type header parameter 🫶.

Status of This Memo

This is an Internet Standards Track document 🔥.

This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 7841 ✨.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://www.rfc-editor.org/info/rfc9596 🌈.

Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. 🎀

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License 💜.

Table of Contents

1.  Introduction
  1.1.  Requirements Notation and Conventions
2.  COSE "typ" (type) Header Parameter
3.  Security Considerations
4.  IANA Considerations
  4.1.  COSE Header Parameter Registrations
5.  References
  5.1.  Normative References
  5.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction 🦋

Okay so COSE [RFC9052] has header parameters that match a lot of the ones in JOSE [RFC7515] [RFC7516] 💅. But here's the tea: COSE doesn't have a "typ" (type) header parameter, which JOSE uses to declare the type of the whole data structure 💀. The security perks of "typ" are explained in Section 3.11 of [RFC8725], which pushes for "explicit typing", where you use "typ" values to tell different kinds of JSON Web Tokens (JWTs) [RFC7519] apart 🙈.

This spec fixes that by adding the JOSE "typ" equivalent to COSE, so explicit typing can work for COSE objects too 🎀✨. The syntax matches the existing COSE content type header parameter, so you can use unsigned integers from the "CoAP Content-Formats" registry [CoAP.ContentFormats] or string media type values [MediaTypes] 🌸.

The term "COSE object" is used as defined in [RFC9052]. An example is a COSE_Sign1 structure, as described in Section 4.2 of [RFC9052] 🧚.

1.1. Requirements Notation and Conventions

Here's how the key words work: "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be read as described in BCP 14 [RFC2119] [RFC8174] only when they're in ALL CAPS, just like shown here 🫶.

2. COSE "typ" (type) Header Parameter 👑

Okay the "typ" (type) header parameter is used by COSE apps to declare the type of the entire COSE object 💖. The content type header parameter is different, since it declares the type of the COSE object payload 💅. This is meant for when more than one kind of COSE object could show up in an app data structure that holds one, so the app can tell them apart 🦋. It typically won't be used when the kind of COSE object is already known 🙈. Use of this header parameter is OPTIONAL ✨.

The syntax of this header parameter value is the same as the content type header parameter from Section 3.1 of [RFC9052]. It's either an unsigned integer registered in the "CoAP Content-Formats" registry [CoAP.ContentFormats] or a string content type value. Content type values have a media type name [MediaTypes] and MAY include media type parameters 🌈.

COSE implementations (libraries that implement [RFC9052] and this spec) ignore the "typ" (type) header parameter, other than passing it through to apps that use them 🫶. Any processing of it is done by the COSE app with its own app-specific rules 🔥. For example, an app might check that the "typ" value is a particular app-chosen media type and reject the data structure if it isn't 💜.

The "typ" parameter MUST NOT be present in unprotected headers 🚫.

The "typ" parameter doesn't describe the content of unprotected headers. Changing unprotected headers doesn't change the type of the COSE object 🧚.

3. Security Considerations 💀

The case for explicit typing of COSE objects is the same as the case made for explicit typing in Section 3.11 of [RFC8725]: explicit typing can prevent confusion between different kinds of COSE objects 🚨.

COSE apps using explicit typing SHOULD reject COSE objects with a type header parameter value that's different from the values they expect in that app context 😭. They SHOULD also reject COSE objects without a type header parameter when one is expected 🙈.

4. IANA Considerations 🌸

4.1. COSE Header Parameter Registrations

IANA has registered the following value in the IANA "COSE Header Parameters" registry [COSE.HeaderParameters] 🎀.

+======+=====+======+=======================+===========+=========+
|Name  |Label|Value | Value Registry        |Description|Reference|
|      |     |Type  |                       |           |         |
+======+=====+======+=======================+===========+=========+
|typ   |16   |uint /| [CoAP.ContentFormats] |Content    |Section 2|
|(type)|     |tstr  | or [MediaTypes]       |type of the|of RFC   |
|      |     |      | registry              |complete   |9596     |
|      |     |      |                       |COSE object|         |
+------+-----+------+-----------------------+-----------+---------+

Table 1

5. References 📚

5.1. Normative References

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8725]  Sheffer, Y., Hardt, D., and M. Jones, "JSON Web Token Best
           Current Practices", BCP 225, RFC 8725,
           DOI 10.17487/RFC8725, February 2020,
           <https://www.rfc-editor.org/info/rfc8725>.

[RFC9052]  Schaad, J., "CBOR Object Signing and Encryption (COSE):
           Structures and Process", STD 96, RFC 9052,
           DOI 10.17487/RFC9052, August 2022,
           <https://www.rfc-editor.org/info/rfc9052>.

5.2. Informative References

[CoAP.ContentFormats]
           IANA, "CoAP Content-Formats",
           <https://www.iana.org/assignments/core-parameters>.

[COSE.HeaderParameters]
           IANA, "COSE Header Parameters",
           <https://www.iana.org/assignments/cose>.

[MediaTypes]
           IANA, "Media Types",
           <https://www.iana.org/assignments/media-types>.

[RFC7515]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web
           Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
           2015, <https://www.rfc-editor.org/info/rfc7515>.

[RFC7516]  Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
           RFC 7516, DOI 10.17487/RFC7516, May 2015,
           <https://www.rfc-editor.org/info/rfc7516>.

[RFC7519]  Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
           (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
           <https://www.rfc-editor.org/info/rfc7519>.

Acknowledgements 🫶

We would like to thank Henk Birkholz, Carsten Bormann, Susan Hares, Dan Harkins, Murray Kucherawy, Marco Tiloca, Gunter Van de Velde, Éric Vyncke, and Dale Worley for their valuable contributions to this specification 💖.

Authors' Addresses 🦋

Michael B. Jones
Self-Issued Consulting
Email: michael_b_jones@hotmail.com
URI:   https://self-issued.info/

Orie Steele
Transmute
Email: orie@transmute.industries
📦 where this page comes from