| rfc9596v1.txt | rfc9596.txt | |||
|---|---|---|---|---|
| Internet Engineering Task Force (IETF) M.B. Jones | Internet Engineering Task Force (IETF) M.B. Jones | |||
| Request for Comments: 9596 Self-Issued Consulting | Request for Comments: 9596 Self-Issued Consulting | |||
| Category: Standards Track O. Steele | Category: Standards Track O. Steele | |||
| ISSN: 2070-1721 Transmute | ISSN: 2070-1721 Transmute | |||
| May 2024 | June 2024 | |||
| CBOR Object Signing and Encryption (COSE) "typ" (type) Header Parameter | CBOR Object Signing and Encryption (COSE) "typ" (type) Header Parameter | |||
| Abstract | Abstract | |||
| This specification adds the equivalent of the JSON Object Signing and | This specification adds the equivalent of the JSON Object Signing and | |||
| Encryption (JOSE) typ (type) header parameter to CBOR Object Signing | Encryption (JOSE) "typ" (type) header parameter to CBOR Object | |||
| and Encryption (COSE). This enables the benefits of explicit typing | Signing and Encryption (COSE). This enables the benefits of explicit | |||
| (as defined in RFC 8725, "JSON Web Token Best Current Practices") to | typing (as defined in RFC 8725, "JSON Web Token Best Current | |||
| be brought to COSE objects. The syntax of the COSE type header | Practices") to be brought to COSE objects. The syntax of the COSE | |||
| parameter value is the same as the existing COSE content type header | type header parameter value is the same as the existing COSE content | |||
| parameter. | type header parameter. | |||
| Status of This Memo | Status of This Memo | |||
| This is an Internet Standards Track document. | This is an Internet Standards Track document. | |||
| This document is a product of the Internet Engineering Task Force | This document is a product of the Internet Engineering Task Force | |||
| (IETF). It represents the consensus of the IETF community. It has | (IETF). It represents the consensus of the IETF community. It has | |||
| received public review and has been approved for publication by the | received public review and has been approved for publication by the | |||
| Internet Engineering Steering Group (IESG). Further information on | Internet Engineering Steering Group (IESG). Further information on | |||
| Internet Standards is available in Section 2 of RFC 7841. | Internet Standards is available in Section 2 of RFC 7841. | |||
| skipping to change at line 70 ¶ | skipping to change at line 70 ¶ | |||
| Acknowledgements | Acknowledgements | |||
| Authors' Addresses | Authors' Addresses | |||
| 1. Introduction | 1. Introduction | |||
| CBOR Object Signing and Encryption (COSE) [RFC9052] defines header | CBOR Object Signing and Encryption (COSE) [RFC9052] defines header | |||
| parameters that parallel many of those defined by the JSON Object | parameters that parallel many of those defined by the JSON Object | |||
| Signing and Encryption (JOSE) specifications [RFC7515] [RFC7516]. | Signing and Encryption (JOSE) specifications [RFC7515] [RFC7516]. | |||
| However, one way in which COSE does not provide equivalent | However, one way in which COSE does not provide equivalent | |||
| functionality to JOSE is that it does not define an equivalent of the | functionality to JOSE is that it does not define an equivalent of the | |||
| typ (type) header parameter, which is used for declaring the type of | "typ" (type) header parameter, which is used for declaring the type | |||
| the entire JOSE data structure. The security benefits of having typ | of the entire JOSE data structure. The security benefits of having | |||
| (type) are described in Section 3.11 of [RFC8725], which recommends | "typ" (type) are described in Section 3.11 of [RFC8725], which | |||
| its use for "explicit typing" -- using typ values to distinguish | recommends its use for "explicit typing" -- using "typ" values to | |||
| between different kinds of JSON Web Tokens (JWTs) [RFC7519]. | distinguish between different kinds of JSON Web Tokens (JWTs) | |||
| [RFC7519]. | ||||
| This specification adds the equivalent of the JOSE typ (type) header | This specification adds the equivalent of the JOSE "typ" (type) | |||
| parameter to COSE so that the benefits of explicit typing can be | header parameter to COSE so that the benefits of explicit typing can | |||
| brought to COSE objects. The syntax of the COSE type header | be brought to COSE objects. The syntax of the COSE type header | |||
| parameter value is the same as the existing COSE content type header | parameter value is the same as the existing COSE content type header | |||
| parameter, allowing both unsigned integer CoAP Content-Formats values | parameter, allowing both unsigned integers as registered in the "CoAP | |||
| [CoAP.ContentFormats] and string Media Type values [MediaTypes] to be | Content-Formats" registry [CoAP.ContentFormats] and string media type | |||
| used. | values [MediaTypes] to be used. | |||
| The term "COSE object" is used as defined in [RFC9052]. An example | The term "COSE object" is used as defined in [RFC9052]. An example | |||
| of a COSE object is a COSE_Sign1 structure, as described in | of a COSE object is a COSE_Sign1 structure, as described in | |||
| Section 4.2 of [RFC9052]. | Section 4.2 of [RFC9052]. | |||
| 1.1. Requirements Notation and Conventions | 1.1. Requirements Notation and Conventions | |||
| The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", | |||
| "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and | |||
| "OPTIONAL" in this document are to be interpreted as described in | "OPTIONAL" in this document are to be interpreted as described in | |||
| BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all | |||
| capitals, as shown here. | capitals, as shown here. | |||
| 2. COSE "typ" (type) Header Parameter | 2. COSE "typ" (type) Header Parameter | |||
| The typ (type) header parameter is used by COSE applications to | The "typ" (type) header parameter is used by COSE applications to | |||
| declare the type of this complete COSE object, as compared to the | declare the type of this complete COSE object, as compared to the | |||
| content type header parameter, which declares the type of the COSE | content type header parameter, which declares the type of the COSE | |||
| object payload. This is intended for use by the application when | object payload. This is intended for use by the application when | |||
| more than one kind of COSE object could be present in an application | more than one kind of COSE object could be present in an application | |||
| data structure that can contain a COSE object; the application can | data structure that can contain a COSE object; the application can | |||
| use this value to disambiguate among the different kinds of COSE | use this value to disambiguate among the different kinds of COSE | |||
| objects that might be present. It will typically not be used by | objects that might be present. It will typically not be used by | |||
| applications when the kind of COSE object is already known. Use of | applications when the kind of COSE object is already known. Use of | |||
| this header parameter is OPTIONAL. | this header parameter is OPTIONAL. | |||
| The syntax of this header parameter value is the same as the content | The syntax of this header parameter value is the same as the content | |||
| type header parameter defined in Section 3.1 of [RFC9052]; it is | type header parameter defined in Section 3.1 of [RFC9052]; it is | |||
| either an unsigned integer CoAP Content-Formats [CoAP.ContentFormats] | either an unsigned integer as registered in the "CoAP Content- | |||
| value or a string content type value. Content type values have a | Formats" registry [CoAP.ContentFormats] or a string content type | |||
| media type name [MediaTypes] and MAY include media type parameters. | value. Content type values have a media type name [MediaTypes] and | |||
| MAY include media type parameters. | ||||
| This parameter is ignored by COSE implementations (libraries | The "typ" (type) header parameter is ignored by COSE implementations | |||
| implementing [RFC9052] and this specification), other than being | (libraries implementing [RFC9052] and this specification), other than | |||
| passed through to applications using those implementations. Any | being passed through to applications using those implementations. | |||
| processing of this parameter is performed by the COSE application | Any processing of this parameter is performed by the COSE application | |||
| using application-specific processing rules. For instance, an | using application-specific processing rules. For instance, an | |||
| application might verify that the typ value is a particular | application might verify that the "typ" value is a particular | |||
| application-chosen media type and reject the data structure if it is | application-chosen media type and reject the data structure if it is | |||
| not. | not. | |||
| The typ parameter MUST NOT be present in unprotected headers. | The "typ" parameter MUST NOT be present in unprotected headers. | |||
| The typ parameter does not describe the content of unprotected | The "typ" parameter does not describe the content of unprotected | |||
| headers. Changes to unprotected headers do not change the type of | headers. Changes to unprotected headers do not change the type of | |||
| the COSE object. | the COSE object. | |||
| 3. Security Considerations | 3. Security Considerations | |||
| The case for explicit typing of COSE objects is equivalent to the | The case for explicit typing of COSE objects is equivalent to the | |||
| case made for explicit typing in Section 3.11 of [RFC8725]: Explicit | case made for explicit typing in Section 3.11 of [RFC8725]: Explicit | |||
| typing can prevent confusion between different kinds of COSE objects. | typing can prevent confusion between different kinds of COSE objects. | |||
| COSE applications employing explicit typing should reject COSE | COSE applications employing explicit typing should reject COSE | |||
| skipping to change at line 148 ¶ | skipping to change at line 150 ¶ | |||
| they expect in that application context. They should also reject | they expect in that application context. They should also reject | |||
| COSE objects without a type header parameter when one is expected. | COSE objects without a type header parameter when one is expected. | |||
| 4. IANA Considerations | 4. IANA Considerations | |||
| 4.1. COSE Header Parameter Registrations | 4.1. COSE Header Parameter Registrations | |||
| IANA has registered the following value in the IANA "COSE Header | IANA has registered the following value in the IANA "COSE Header | |||
| Parameters" registry [COSE.HeaderParameters]. | Parameters" registry [COSE.HeaderParameters]. | |||
| +========+=======+========+=======================+=================+ | +======+=====+======+=======================+===========+=========+ | |||
| | Name | Label | Value | Value Registry | Description | | |Name |Label|Value | Value Registry |Description|Reference| | |||
| | | | Type | | | | | | |Type | | | | | |||
| +========+=======+========+=======================+=================+ | +======+=====+======+=======================+===========+=========+ | |||
| | typ | 16 | uint / | [CoAP.ContentFormats] | Content | | |typ |16 |uint /| [CoAP.ContentFormats] |Content |Section 2| | |||
| | (type) | | tstr | or [MediaTypes] | type of the | | |(type)| |tstr | or [MediaTypes] |type of the|of RFC | | |||
| | | | | registry | complete | | | | | | registry |complete |9596 | | |||
| | | | | | COSE object | | | | | | |COSE object| | | |||
| +--------+-------+--------+-----------------------+-----------------+ | +------+-----+------+-----------------------+-----------+---------+ | |||
| Table 1 | Table 1 | |||
| 5. References | 5. References | |||
| 5.1. Normative References | 5.1. Normative References | |||
| [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate | |||
| Requirement Levels", BCP 14, RFC 2119, | Requirement Levels", BCP 14, RFC 2119, | |||
| DOI 10.17487/RFC2119, March 1997, | DOI 10.17487/RFC2119, March 1997, | |||
| End of changes. 12 change blocks. | ||||
| 38 lines changed or deleted | 40 lines changed or added | |||
This html diff was produced by rfcdiff 1.48. | ||||