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