From 591d07a09aaeaee5942f848ef3145c127d961449 Mon Sep 17 00:00:00 2001 From: Michael Jones Date: Thu, 9 Nov 2023 12:37:16 +0100 Subject: [PATCH 1/3] Described use cases for non-CBOR payloads and claims semantics --- draft-ietf-cose-cwt-claims-in-headers.md | 11 ++++++++++- 1 file changed, 10 insertions(+), 1 deletion(-) diff --git a/draft-ietf-cose-cwt-claims-in-headers.md b/draft-ietf-cose-cwt-claims-in-headers.md index f84cabf..803cfc8 100644 --- a/draft-ietf-cose-cwt-claims-in-headers.md +++ b/draft-ietf-cose-cwt-claims-in-headers.md @@ -37,12 +37,16 @@ organization = "Self-Issued Consulting" .# Abstract This document describes how to include CBOR Web Token (CWT) claims in the header parameters of any COSE structure. This functionality helps to facilitate applications that wish to make use of CBOR Web Token (CWT) claims in encrypted COSE structures and/or COSE structures featuring detached signatures, while having some of those claims be available before decryption and/or without inspecting the detached payload. +Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. {mainmatter} # Introduction In some applications of COSE, it is useful to have a standard representation of CWT claims [@!RFC8392] available in the header parameters. These include encrypted COSE structures, which may or may not be an encrypted CWT and/or those featuring a detached signature. +Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. +For instance, an application might want to include an "iss" (issuer) claim in a COSE_Sign1 structure, +when what is being signed is a non-CBOR data structure such as a bitmap image. Section 5.3 of JSON Web Token (JWT) [@RFC7519] defined a similar mechanism for expressing selected JWT based claims as JOSE header parameters. This JWT feature was motivated by the desire to have certain claims, such as the Issuer value, be visible to software processing the JWT, even though the JWT is encrypted. No corresponding feature was standardized for CWTs, which was an omission that this specification corrects. @@ -89,7 +93,7 @@ As described in [@RFC9052], if the COSE payload is transported separately ("deta The reason for applications to verify that CWT claims that are present both in the payload and the header of a CWT are identical, unless it defines other specific processing rules for these claims, is to eliminate potential confusion that might arise by having different values for the same claim, which could result in inconsistent processing of such claims. -Profiles define how to use CWT claims for particular applications, whether they are in the COSE payload or the CWT Claims header parameter, or both. Therefore, understanding how to process the CWT Claims requires unambiguously knowing the profile being used. A recommended way to include this information in the COSE structure is use of the `typ` (type) Header Parameter [@I-D.ietf-cose-typ-header-parameter]. Other methods for determining the profile can also be used. +Profiles define how to use CWT claims and their semantics for particular applications, whether they are in the COSE payload or the CWT Claims header parameter, or both. Therefore, understanding how to process the CWT Claims requires unambiguously knowing the profile being used. A recommended way to include this information in the COSE structure is use of the `typ` (type) Header Parameter [@I-D.ietf-cose-typ-header-parameter]. Other methods for determining the profile can also be used. # IANA Considerations @@ -115,6 +119,11 @@ for their valuable contributions to this specification. # Document History +-09 + +* Described use cases where CWT claims can't be put in the payload. +* Said that profiles specify the semantics of the CWT claims. + -08 * Added Security Consideration about profiles and processing CWT claims. From 39348e68b27600a0810a0397fdf8e2ee9399051b Mon Sep 17 00:00:00 2001 From: Michael Jones Date: Thu, 9 Nov 2023 12:40:51 +0100 Subject: [PATCH 2/3] Credit Hannes and Carsten in the history entries --- draft-ietf-cose-cwt-claims-in-headers.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/draft-ietf-cose-cwt-claims-in-headers.md b/draft-ietf-cose-cwt-claims-in-headers.md index 803cfc8..7774772 100644 --- a/draft-ietf-cose-cwt-claims-in-headers.md +++ b/draft-ietf-cose-cwt-claims-in-headers.md @@ -121,8 +121,8 @@ for their valuable contributions to this specification. -09 -* Described use cases where CWT claims can't be put in the payload. -* Said that profiles specify the semantics of the CWT claims. +* Described use cases where CWT claims can't be put in the payload in response to Hannes Tschofenig's IotDir review. +* Said that profiles specify the semantics of the CWT claims in response to Carsten Bormann's feedback. -08 From bfba4618aa44a686098dcd956ce7d8ebe5a251c9 Mon Sep 17 00:00:00 2001 From: Michael Jones Date: Fri, 10 Nov 2023 15:57:14 +0100 Subject: [PATCH 3/3] Applied wording suggestions by Hannes --- draft-ietf-cose-cwt-claims-in-headers.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/draft-ietf-cose-cwt-claims-in-headers.md b/draft-ietf-cose-cwt-claims-in-headers.md index 7774772..a4a187b 100644 --- a/draft-ietf-cose-cwt-claims-in-headers.md +++ b/draft-ietf-cose-cwt-claims-in-headers.md @@ -45,8 +45,8 @@ Another use case is using CWT claims with payloads that are not CWT Claims Sets, In some applications of COSE, it is useful to have a standard representation of CWT claims [@!RFC8392] available in the header parameters. These include encrypted COSE structures, which may or may not be an encrypted CWT and/or those featuring a detached signature. Another use case is using CWT claims with payloads that are not CWT Claims Sets, including payloads that are not CBOR at all. -For instance, an application might want to include an "iss" (issuer) claim in a COSE_Sign1 structure, -when what is being signed is a non-CBOR data structure such as a bitmap image. +For instance, an application might want to include an "iss" (issuer) claim in a COSE_Sign1 structure +when the payload being signed is a non-CBOR data structure, such as a bitmap image, and the issuer value is used for key discovery. Section 5.3 of JSON Web Token (JWT) [@RFC7519] defined a similar mechanism for expressing selected JWT based claims as JOSE header parameters. This JWT feature was motivated by the desire to have certain claims, such as the Issuer value, be visible to software processing the JWT, even though the JWT is encrypted. No corresponding feature was standardized for CWTs, which was an omission that this specification corrects. @@ -93,6 +93,10 @@ As described in [@RFC9052], if the COSE payload is transported separately ("deta The reason for applications to verify that CWT claims that are present both in the payload and the header of a CWT are identical, unless it defines other specific processing rules for these claims, is to eliminate potential confusion that might arise by having different values for the same claim, which could result in inconsistent processing of such claims. +Processing information in claims prior to validating that their integrity is cryptographically secured can pose security risks. +This is true whether the claims are in the payload or a header parameter. +Implementers must ensure that any tentative decisions made based on previously unverified information are confirmed once the cryptographic processing has been completed. + Profiles define how to use CWT claims and their semantics for particular applications, whether they are in the COSE payload or the CWT Claims header parameter, or both. Therefore, understanding how to process the CWT Claims requires unambiguously knowing the profile being used. A recommended way to include this information in the COSE structure is use of the `typ` (type) Header Parameter [@I-D.ietf-cose-typ-header-parameter]. Other methods for determining the profile can also be used. # IANA Considerations