Subject: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

From: Tobias Looker <[email-masked]>
Date: Wed, 2 Mar 2022 04:32:16 +0000

Hi All,

This is an email to introduce the newly submitted draft titled "CBOR Web Token (CWT) Claims in COSE Headers", the current abstract is as follows.

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

https://datatracker.ietf.org/doc/draft-looker-cose-cwt-claims-in-headers/

As covered in the introduction of this draft, a similar mechanism already exists for JWT and we see value in providing a way to do the same with CWTs.

Thanks,

[Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>

Tobias Looker

MATTR
CTO

+64 (0) 27 378 0461
[email-masked]<mailto:[email-masked]>

[Mattr website]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>

[Mattr on LinkedIn]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0>

[Mattr on Twitter]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0>

[Mattr on Github]<https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0>

This communication, including any attachments, is confidential. If you are not the intended recipient, you should not read it - please contact me immediately, destroy it, and do not copy or use any part of this communication or disclose anything about it. Thank you. Please note that this communication does not designate an information system for the purposes of the Electronic Transactions Act 2002.

---

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 2 Mar 2022 08:21:02 +0000

Hi Tobias,

Could you say something about the use cases or provide an example of what you want to accomplish?

Ciao
Hannes

From: COSE <[email-masked]> On Behalf Of Tobias Looker
Sent: Wednesday, March 2, 2022 5:32 AM
To: [email-masked]
Cc: [email-masked]
Subject: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

Hi All,

Thanks,

Tobias Looker

MATTR
CTO

+64 (0) 27 378 0461

IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

---

From: Mike Jones <[email-masked]>
Date: Wed, 2 Mar 2022 17:34:50 +0000

The use case is the same as that which motivated Section 5.3 of JWT "Replicating Claims as Header Parameters" https://datatracker.ietf.org/doc/html/rfc7519#section-5.3 - encrypted CWTs for which you'd like to have unencrypted instances of particular claims to determine how to process the CWT prior to decrypting it.  Note that https://datatracker.ietf.org/doc/html/rfc7519#section-10.4 explicitly registers the "iss", "sub", and "aud" claims as JWE header parameter values exactly for this purpose.

This draft defines a syntax for COSE to likewise enable the corresponding CWT claims to be passed in the clear in the COSE header, just as JWT claims can be replicated as JOSE header parameters when needed.

                                                                                  -- Mike

From: Hannes Tschofenig <[email-masked]>
Sent: Wednesday, March 2, 2022 12:21 AM
To: Tobias Looker <tobias.looker=[email-masked]>; [email-masked]
Cc: Mike Jones <[email-masked]>
Subject: RE: Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

Hi Tobias,

Ciao
Hannes

From: COSE <[email-masked]<mailto:[email-masked]>> On Behalf Of Tobias Looker
Sent: Wednesday, March 2, 2022 5:32 AM
To: [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

Hi All,

Thanks,

Tobias Looker

MATTR
CTO

+64 (0) 27 378 0461

---

From: Laurence Lundblade <[email-masked]>
Date: Wed, 2 Mar 2022 10:33:41 -0800

Makes sense to me. Helps out for the EAT claim named “profile” which gives information about the type of the token you might want before fully verifying it. Addresses an issue Anders brought up about the profile claim.

LL

> On Mar 2, 2022, at 9:34 AM, Mike Jones <Michael.Jones=[email-masked]> wrote:
> 
> The use case is the same as that which motivated Section 5.3 of JWT “Replicating Claims as Header Parameters” https://datatracker.ietf.org/doc/html/rfc7519#section-5.3 <https://datatracker.ietf.org/doc/html/rfc7519#section-5.3> – encrypted CWTs for which you’d like to have unencrypted instances of particular claims to determine how to process the CWT prior to decrypting it.  Note that https://datatracker.ietf.org/doc/html/rfc7519#section-10.4 <https://datatracker.ietf.org/doc/html/rfc7519#section-10.4> explicitly registers the “iss”, “sub”, and “aud” claims as JWE header parameter values exactly for this purpose.
>  
> From: COSE <[email-masked] <mailto:[email-masked]>> On Behalf Of Tobias Looker
> To: [email-masked] <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>
> https://datatracker.ietf.org/doc/draft-looker-cose-cwt-claims-in-headers/ <https://datatracker.ietf.org/doc/draft-looker-cose-cwt-claims-in-headers/>
>  
>  <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>	
>  
> 
> Tobias Looker
> 
> MATTR
> CTO
> 
> +64 (0) 27 378 0461
> [email-masked] <mailto:[email-masked]>
>  <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WeN4boYw%26u%3Dhttps%253a%252f%252fmattr.global%252f&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076709977%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=tKqCMzLUQNCeORd908YqfqZoT7tCy%2FMVwXdjpch1sDY%3D&reserved=0>	
>  <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1SbN9fvNg%26u%3Dhttps%253a%252f%252fwww.linkedin.com%252fcompany%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076719975%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=t%2BidOI32oaKuTJf1AkcG%2B%2FirIJwbrgzXVZnjOAC52Hs%3D&reserved=0>	
>  <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiW1WdMte6ZA%26u%3Dhttps%253a%252f%252ftwitter.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=BD9WWyXEjVGlbpbCja93yW%2FzLJZpe%2Ff8lGooe8V6i7w%3D&reserved=0>	
>  <https://aus01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fscanmail.trustwave.com%2F%3Fc%3D15517%26d%3Dw46s4eMXULV_ns1ZfAKYLbVKcqey_PHiWwGdMoDtMw%26u%3Dhttps%253a%252f%252fgithub.com%252fmattrglobal&data=04%7C01%7CSteve.Lowes%40mbie.govt.nz%7C5a65fe33c70b41fd8ba908d976f3a2f1%7C78b2bd11e42b47eab0112e04c3af5ec1%7C0%7C0%7C637671611076729970%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4AhRuXZCnU5i3hcngo4H3UiNayYUtXpRcImV4slS1mw%3D&reserved=0>
> 
> _______________________________________________
> COSE mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/cose

---

From: Anders Rundgren <[email-masked]>
Date: Thu, 3 Mar 2022 08:38:47 +0100

> Makes sense to me. Helps out for the EAT claim named “profile” which gives information about the type of the token you might want before fully verifying it. Addresses an issue Anders brought up abo…

Not so fast  :)  I brought up a bunch of things which can be illustrated by this (just implemented...) example of an encryption object:

211(["https://example.com/myobject", {
   / COSE content encryption algorithm = A256GCM /
   1: 3,
   / Key encryption container /
   2: {
     / COSE Key encryption algorithm = ECDH-ES+A256KW /
     1: -31,
     / Key identifier /
     3: "mykey",
     / Ephemeral key /
     5: {
       / COSE Key type = OKP /
       1: 1,
       / COSE Curve = X25519 /
       -1: 4,
       / COSE X coordinate /
       -2: h'33a04b83d4428824b6d5477522d4a88fac4441122bc46136c0203faa308c3929'
     },
     / Encrypted key /
     10: h'e08977c25aeccaecd63b3367de2e2b8f700c82e098ad1e5099d9db510920ccff14debf820427e4ba'
   },
   / Tag /
   8: h'59a84826983e3247fbec4295f75cc138',
   / IV /
   9: h'fd8556c122cff2bc128d5119',
   / Encrypted data /
   10: h'e16b16c29da5163eb0131dd1f10f080f8850f55df2ae9d89a3b839ad50952858445f290dfb60'
}])

The core of this builds on /Deterministic CBOR/ which unleashes the /true power/ of CBOR in a way legacy solutions do not.   The enhancements include:

  * Eliminating wrapping of header and (unencrypted) application data.
  * Using the entire container (modulo the algorithm output variables which are added lastly) as input to a signature process and to the authentication part of an encryption process.  In the example that includes the top-level CBOR tag as well.  cryptoOperation(cborObject.encode()) is all that it takes on the encoder's side.

This is pretty much what the X.509 folks have been doing from the very start so there is close to zero innovation here 😁<https://apps.timwhitlock.info/emoji/tables/unicode#emoji-modal>

In the example I have also used a URL as profile/object type indicator since IANA CBOR custom tag 1537244 or whatever you end-up with, simply isn't pretty enough :)  To be more serious: URLs are /decentralized/ and would in this context probably be /browseable/ as well.

Cheers,
Anders

---

From: Laurence Lundblade <[email-masked]>
Date: Thu, 3 Mar 2022 00:21:29 -0800

Yes, the only issue of yours that addresses is the ability to access the profile claim before decoding, decrypting and verifying the COSE payload.

LL

> On Mar 2, 2022, at 11:38 PM, Anders Rundgren <[email-masked]> wrote:
> 
> 211(["https://example.com/myobject" <https://example.com/myobject>, {
> The core of this builds on Deterministic CBOR which unleashes the true power of CBOR in a way legacy solutions do not.   The enhancements include:
> Eliminating wrapping of header and (unencrypted) application data.
> Using the entire container (modulo the algorithm output variables which are added lastly) as input to a signature process and to the authentication part of an encryption process.  In the example that includes the top-level CBOR tag as well.  cryptoOperation(cborObject.encode()) is all that it takes on the encoder's side.
> This is pretty much what the X.509 folks have been doing from the very start so there is close to zero innovation here 😁
>  <https://apps.timwhitlock.info/emoji/tables/unicode#emoji-modal>
> 
> In the example I have also used a URL as profile/object type indicator since IANA CBOR custom tag 1537244 or whatever you end-up with, simply isn't pretty enough :)  To be more serious: URLs are decentralized and would in this context probably be browseable as well.
> 
> Cheers,
> Anders
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 3 Mar 2022 09:40:33 +0000

Hi Mike,

Thanks for the quick response. Section 5.3 of the JWT RFC explains what is being done but no use case is given. Why would someone want to encrypt a claim and then put the plaintext version into the outer header.

The argument (in JWT) is given as follows:

"
   This might be used, for
   instance, in application processing rules to determine whether and
   how to process the JWT before it is decrypted.
"

>From a security point of view it is not clever to make decisions based on unprotected data when the same data is encrypted in the actual payload.

On top of that Section 5.3 of the JWT RFC furthermore does not mandate that the recipient compares the unencrypted data with the version of the encrypted data. (Only a SHOULD is given and that is even softened in the rest of the sentence.)

Ciao
Hannes

From: Mike Jones <[email-masked]>
Sent: Wednesday, March 2, 2022 6:35 PM
To: Hannes Tschofenig <[email-masked]>; Tobias Looker <tobias.looker=[email-masked]>; [email-masked]
Subject: RE: Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

                                                                                  -- Mike

From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Sent: Wednesday, March 2, 2022 12:21 AM
To: Tobias Looker <tobias.looker=[email-masked]<mailto:tobias.looker=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Cc: Mike Jones <[email-masked]<mailto:[email-masked]>>
Subject: RE: Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

Hi Tobias,

Ciao
Hannes

Hi All,

Thanks,

Tobias Looker

MATTR
CTO

+64 (0) 27 378 0461

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 3 Mar 2022 09:44:57 +0000

Hi Anders,

Thanks for jumping in.

The example you provide below is actually quite interesting and related to a question I posted to the list a few days ago (see https://mailarchive.ietf.org/arch/msg/cose/9nowDz5kbfUvrGR-o6U1Tm31XAA/).

I am not sure whether the intention of Tobias & Mike are actually to re-define the way how encryption is accomplished. They should confirm.

Ciao
Hannes

From: Anders Rundgren <[email-masked]>
Sent: Thursday, March 3, 2022 8:39 AM
To: Laurence Lundblade <[email-masked]>; Mike Jones <Michael.Jones=[email-masked]>
Cc: Hannes Tschofenig <[email-masked]>; Tobias Looker <tobias.looker=[email-masked]>; [email-masked]
Subject: Re: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

211(["https://example.com/myobject"<https://example.com/myobject>, {

Cheers,
Anders

---

From: Mike Jones <[email-masked]>
Date: Thu, 3 Mar 2022 17:02:10 +0000

We are *definitely* not attempting to change anything about COSE message processing, including how encryption is done.  We are defining an additional header parameter that can be used – that’s it.

                                                       -- Mike

From: Hannes Tschofenig <[email-masked]>
Sent: Thursday, March 3, 2022 1:45 AM
To: Anders Rundgren <[email-masked]>; Laurence Lundblade <[email-masked]>; Mike Jones <[email-masked]>
Cc: Tobias Looker <[email-masked]>; [email-masked]
Subject: RE: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

Hi Anders,

Thanks for jumping in.

Ciao
Hannes

From: Anders Rundgren <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, March 3, 2022 8:39 AM
To: Laurence Lundblade <[email-masked]<mailto:[email-masked]>>; Mike Jones <Michael.Jones=[email-masked]<mailto:Michael.Jones=[email-masked]>>
Cc: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>; Tobias Looker <tobias.looker=[email-masked]<mailto:tobias.looker=[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: Re: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

Cheers,
Anders

---

From: Anders Rundgren <[email-masked]>
Date: Fri, 4 Mar 2022 07:54:04 +0100

On 2022-03-03 18:02, Mike Jones wrote:
>
> We are **definitely** not attempting to change anything about COSE message processing, including how encryption is done.  We are defining an additional header parameter that can be used – that’s it.
>

Dear Mike, what I showed is effectively an /alternative to COSE/. It is a spin-off from an attempt to marry FIDO and CBOR for payment authorizations.  Since FIDO signatures are pretty unique, it is not entirely obvious what to do: https://www.w3.org/TR/webauthn-2/images/fido-signature-formats-figure2.svg

By leaving "Legacy CBOR" [*] behind, you can create FIDO based authorization signatures like this:

{
/ Key 1-9 hold application data /
   1: "1.0",
   2: {
     1: "Space Shop",
     2: "7040566321",
     3: "435.00",
     4: "EUR"
   },
   3: "spaceshop.com",
   4: "FR7630002111110020050014382",
   5: "0057162932",
   6: "https://bankdirect.com",
   7: "additional stuff...",
   8: {
     1: {
       3: "Android",
       4: "10.0"
     },
     2: {
       3: "Chrome",
       4: "103"
     }
   },
   9: "2022-02-02T10:14:07+01:00",
/ Enveloped authorization signature object /
   10: {
/ COSE signatureAlgorithm = ES256 /
     1: -7,
/ COSE publicKey /
     2: {
/ COSE kty = EC /
       1: 2,
/ COSE crv = P-256 /
       -1: 1,
/ COSE x /
       -2: h'e812b1a6dcbc708f9ec43cc2921fa0a14e9d5eadcc6dc63471dd4b680c6236b5',
/ COSE y /
       -3: h'9826dcbd4ce6e388f72edd9be413f2425a10f75b5fd83d95fa0cde53159a51d8'
     },
/ FIDO authenticatorData /
3: h'412e175a0f0bdc06dabf0b1db79b97541c08dbacee7e31c97a553588ee922ea70500000017',
/ FIDO ASN.1 encoded signature /
5: h'304402205c29e1971c0ceb78a977b7fac2aa955ccc8e7d1b6de79e2b9fd1b230313392b70220392d17dacff64bf69a7586cc1aa11e93611a0514ae0c431eef67d47718de763a'
   }
}

The signature validation algorithm then becomes quite simple:
- Collect key and algorithm data from the authorization signature object.
- Save and Remove FIDO "authenticatorData" and FIDO "signature" from the CBOR container.
- Set "authorizationData" = re-serialized CBOR container.
- Verify signature using ("authenticatorData" || sha256(authorizationData) as signed data.

The same model (but without the FIDO specific "authenticatorData" and double hashing) can be applied to most other systems requiring signed CBOR data.  As shown in the previous posting, the core concept fits encryption as well.

I'm considering submitting some of this to the EU ID-Wallet program:
https://ec.europa.eu/info/funding-tenders/opportunities/portal/screen/opportunities/topic-details/digital-2022-deploy-02-electronic-id

Cheers,
Anders

*] The rationale for keeping legacy CBOR seems pretty hollow: https://github.com/cyberphone/D-CBOR/blob/main/d-cbor-4-constrained-devices.md

> -- Mike
>
> *From:*Hannes Tschofenig <[email-masked]>
> *Sent:* Thursday, March 3, 2022 1:45 AM
> *To:* Anders Rundgren <[email-masked]>; Laurence Lundblade <[email-masked]>; Mike Jones <[email-masked]>
> *Cc:* Tobias Looker <[email-masked]>; [email-masked]
> *Subject:* RE: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers
>
> Hi Anders,
>
> Thanks for jumping in.
>
> *From:*Anders Rundgren <[email-masked]>
> *Sent:* Thursday, March 3, 2022 8:39 AM
> *To:* Laurence Lundblade <[email-masked]>; Mike Jones <Michael.Jones=[email-masked]>
> *Cc:* Hannes Tschofenig <[email-masked]>; Tobias Looker <tobias.looker=[email-masked]>; [email-masked]
> *Subject:* Re: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers
>

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 4 Mar 2022 08:08:02 +0100

> - Save and Remove FIDO "authenticatorData" and FIDO "signature" from the CBOR container.  

This is what we called the “transform” in the beloved XMLDSig.
The complexities of this step can be the basis of interesting vulnerabilities (or interoperability failures).

> - Set "authorizationData" = re-serialized CBOR container.

(Using deterministic serialization.
Fortunately, that works much better in CBOR than in other serialization formats.)

> - Verify signature using ("authenticatorData" || sha256(authorizationData) as signed data.

Now you have verified a signature as applied to the transformed data.
COSE differs in design by signing the actual data as interchanged.
(This is not as expensive to do in CBOR as in serialization formats that cannot efficiently encode byte strings, i.e., binary data.)

Grüße, Carsten

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 8 Mar 2022 06:23:56 +0100

> The complexities of this step can be the basis of interesting vulnerabilities (or interoperability failures).

Since I had not worked with low-level encoders and decoders, I spent a couple of days in the lab (kitchen actually).

To not be dependent on my own stuff (which of course works flawlessly since it was from the beginning designed with FIDO in mind), I applied the more universal CSF (CBOR Signature Format) to Laurence's excellent QCBOR library.  This is what I came up with:
https://github.com/cyberphone/D-CBOR/blob/main/verify-demo/csf-verifier.c
The actual transform part is performed by FOUR LINES of C.  This was a surprise even to me.

Carsten, you should be proud; CBOR is the by far best data interchange format for blending with cool cryptographic constructs!

Could wrapping your precious data in bstr just in order to sign it, be headed for obsolescence? :)

Regarding the other "hot" subject, deterministic serialization, the demo does not depend on that since it operates directly on the CBOR data.  However, high-level CBOR tools that convert streaming CBOR to internal self-serializing objects, do:
https://github.com/cyberphone/openkeystore/blob/9470afdcd4d820489b3351c21b256d994930e422/library/src/org/webpki/cbor/CBORMap.java#L328

Cheers,
Anders

---

From: Laurence Lundblade <[email-masked]>
Date: Tue, 8 Mar 2022 09:07:38 -0800

> On Mar 7, 2022, at 9:23 PM, Anders Rundgren <[email-masked]> wrote:
> 

Your code accesses private QCBOR data structures to make this work, but no fear because 1) this part of QCBOR is not going to change and 2) I’m working on a PR to allow access to encoded maps and arrays <https://github.com/laurencelundblade/QCBOR/pull/117>. (I’m  bit bogged down on QCBOR PRs these days)

> Could wrapping your precious data in bstr just in order to sign it, be headed for obsolescence? :)

I suspect not because decoders in other languages won’t be so easy to modify for this.

LL

---

From: Anders Rundgren <[email-masked]>
Date: Tue, 8 Mar 2022 18:50:09 +0100

On 2022-03-08 18:07, Laurence Lundblade wrote:

Hi Laurence,
This is just a PoC with the aim showing that the scheme I'm advocating is simple.
I'm sure CBOR tool designers can implement something fitting (if they feel a need).

In my Java implementation, the read-and-delete operation requires TWO lines of code.  That is some 1000-5000 times times less than a full-blown XML transform.

This is another, related topic:
https://github.com/cyberphone/D-CBOR/blob/main/d-cbor-4-constrained-devices.md#handling-indefinite-length-data

Cheers,
Anders

> 
>> On Mar 7, 2022, at 9:23 PM, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>>
>>> On 2022-03-04, at 07:54, Anders Rundgren <[email-masked] <mailto:[email-masked]>> wrote:
>>>>
>> https://github.com/cyberphone/D-CBOR/blob/main/verify-demo/csf-verifier.c <https://github.com/cyberphone/D-CBOR/blob/main/verify-demo/csf-verifier.c>
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 11 Mar 2022 12:45:22 +0000

Hi Mike,

maybe you can give examples of where this feature is used in JWTs, which would explain why you want to have it in CWTs as well.

Ciao
Hannes

From: Mike Jones <[email-masked]>
Sent: Thursday, March 3, 2022 6:02 PM
To: Hannes Tschofenig <[email-masked]>; Anders Rundgren <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: Tobias Looker <[email-masked]>; [email-masked]
Subject: RE: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

                                                       -- Mike

From: Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, March 3, 2022 1:45 AM
To: Anders Rundgren <[email-masked]<mailto:[email-masked]>>; Laurence Lundblade <[email-masked]<mailto:[email-masked]>>; Mike Jones <[email-masked]<mailto:[email-masked]>>
Cc: Tobias Looker <[email-masked]<mailto:[email-masked]>>; [email-masked]<mailto:[email-masked]>
Subject: RE: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

Hi Anders,

Thanks for jumping in.

Ciao
Hannes

Cheers,
Anders

---

From: Tobias Looker <[email-masked]>
Date: Sun, 13 Mar 2022 20:47:08 +0000

Hi Hannes,

I can elaborate.

Encrypted CWTs - In some circumstances CWT claims can be useful to have available for processing prior to decryption. For example the iss claim can be used to indicate to a recipient of an encrypted CWT how it should be decrypted, by informing the recipient who encrypted (and potentially signed) it.

Detached Signature - In cases where a detached signature COSE structure is being used the payload can be un-available (or of invalid form) to express CWT claims. A concrete example is being able to express who signed the detached signature structure (using the iss claim) and when it expires (using the exp claim).

Thanks,

Tobias Looker

MATTR
CTO

+64 (0) 27 378 0461

________________________________
From: Hannes Tschofenig <[email-masked]>
Sent: 12 March 2022 01:45
To: Mike Jones <[email-masked]>; Anders Rundgren <[email-masked]>; Laurence Lundblade <[email-masked]>
Cc: Tobias Looker <[email-masked]>; [email-masked] <[email-masked]>
Subject: RE: [COSE] Newly Submitted Draft - CBOR Web Token (CWT) Claims in COSE Headers

EXTERNAL EMAIL: This email originated outside of our organisation. Do not click links or open attachments unless you recognise the sender and know the content is safe.

Hi Mike,

Ciao

Hannes

                                                       -- Mike

Hi Anders,

Thanks for jumping in.

Ciao

Hannes

This is pretty much what the X.509 folks have been doing from the very start so there is close to zero innovation here ??

Cheers,
Anders

---

From: Laurence Lundblade <[email-masked]>
Date: Sun, 13 Mar 2022 15:20:38 -0700

For EAT, putting the profile claim in a header could be really useful, especially if the EAT is encrypted.

The profile claim tells you the something about the format and type of the EAT, maybe even which processor to hand it off too. It’s nice to be able to do the hand off without having to decrypt and verify. 

The intended use claim is another good candidate for this header.

I like the addition a lot.

LL

> On Mar 13, 2022, at 1:47 PM, Tobias Looker <[email-masked]> wrote:
> 
> Hi Hannes,
> 
> I can elaborate.
> 
> From: Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>
> To: Mike Jones <[email-masked] <mailto:[email-masked]>>; Anders Rundgren <[email-masked] <mailto:[email-masked]>>; Laurence Lundblade <[email-masked] <mailto:[email-masked]>>
> Cc: Tobias Looker <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]> <[email-masked] <mailto:[email-masked]>>
> From: Hannes Tschofenig <[email-masked] <mailto:[email-masked]>> 
> To: Anders Rundgren <[email-masked] <mailto:[email-masked]>>; Laurence Lundblade <[email-masked] <mailto:[email-masked]>>; Mike Jones <[email-masked] <mailto:[email-masked]>>
> Cc: Tobias Looker <[email-masked] <mailto:[email-masked]>>; [email-masked] <mailto:[email-masked]>
> The example you provide below is actually quite interesting and related to a question I posted to the list a few days ago (seehttps://mailarchive.ietf.org/arch/msg/cose/9nowDz5kbfUvrGR-o6U1Tm31XAA/ <https://mailarchive.ietf.org/arch/msg/cose/9nowDz5kbfUvrGR-o6U1Tm31XAA/>).
>  
> From: Anders Rundgren <[email-masked] <mailto:[email-masked]>> 
> To: Laurence Lundblade <[email-masked] <mailto:[email-masked]>>; Mike Jones <Michael.Jones=[email-masked] <mailto:Michael.Jones=[email-masked]>>
> Cc: Hannes Tschofenig <[email-masked] <mailto:[email-masked]>>; Tobias Looker <tobias.looker=[email-masked] <mailto:tobias.looker=[email-masked]>>; [email-masked] <mailto:[email-masked]>

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 14 Mar 2022 08:56:48 +0000

Hi Tobias,

Thanks for your feedback. A few remarks below.

[hannes] There is already a field in COSE that allows you to identify the key, namely the kid. (key identity)

[hannes] Can you show me how this looks like?

Ciao
Hannes