Subject: [Suit] Value of COSE_Mac_Tagged/COSE_Sign_Tagged/COSE_Mac0_Tagged/COSE_Sign1_Tagged

From: Akira Tsukamoto <[email-masked]>
Date: Thu, 9 Apr 2020 10:59:11 +0900

Hi all,

I am not sure this is the right place to ask.

This is the feedback from the TEEP-wg after the virtual hackathon and interim meeting.

TEEP was using COSE_Mac_Tagged/COSE_Sign_Tagged/COSE_Mac0_Tagged/COSE_Sign1_Tagged.
Are these tags defined the value in some drafts or iana?
When we were trying to implement the teep, we could not put the bstr or int/uint for the tags.

I the draft-ietf-suit-manifest-01, it also using these tags in page 43,
https://tools.ietf.org/html/draft-ietf-suit-manifest-01

as

SUIT_Authentication_Wrapper = [ + (
     COSE_Mac_Tagged /
     COSE_Sign_Tagged /
     COSE_Mac0_Tagged /
     COSE_Sign1_Tagged)
]

COSE_Mac_Tagged = any
COSE_Sign_Tagged = any
COSE_Mac0_Tagged = any
COSE_Sign1_Tagged = any

It was deleted in teep at the link bellow of the pull request after the discussion from the hackathon,
https://github.com/ietf-teep/teep-protocol/commit/151e72b0ea3ab8ff8f59ea42004180d90006f8c9
but would be nice to know if it was OK with similar bellow,

COSE_Mac_Tagged = 1
COSE_Sign_Tagged = 2
COSE_Mac0_Tagged = 3
COSE_Sign1_Tagged = 4

Thanks,
-Akira

---

From: Jim Schaad <[email-masked]>
Date: Wed, 8 Apr 2020 20:45:19 -0700

These values are defined in RFC 8152,  draft-ietf-cose-rfc8152bis-struct or
in the IANA registry.

Jim

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Akira Tsukamoto
Sent: Wednesday, April 8, 2020 6:59 PM
To: [email-masked]
Subject: [Suit] Value of
COSE_Mac_Tagged/COSE_Sign_Tagged/COSE_Mac0_Tagged/COSE_Sign1_Tagged

Hi all,

This is the feedback from the TEEP-wg after the virtual hackathon and
interim meeting.

TEEP was using
COSE_Mac_Tagged/COSE_Sign_Tagged/COSE_Mac0_Tagged/COSE_Sign1_Tagged.
Are these tags defined the value in some drafts or iana?
When we were trying to implement the teep, we could not put the bstr or
int/uint for the tags.

as

COSE_Mac_Tagged = any
COSE_Sign_Tagged = any
COSE_Mac0_Tagged = any
COSE_Sign1_Tagged = any

It was deleted in teep at the link bellow of the pull request after the
discussion from the hackathon,
https://github.com/ietf-teep/teep-protocol/commit/151e72b0ea3ab8ff8f59ea4200
4180d90006f8c9
but would be nice to know if it was OK with similar bellow,

COSE_Mac_Tagged = 1
COSE_Sign_Tagged = 2
COSE_Mac0_Tagged = 3
COSE_Sign1_Tagged = 4

Thanks,
-Akira

_______________________________________________
Suit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/suit

---

From: Akira Tsukamoto <[email-masked]>
Date: Thu, 9 Apr 2020 15:53:46 +0900

Hi Jim,

I think I started figure out what was going on.

The RFC8152 describes as:
  COSE_Mac_Tagged   = #6.97(COSE_Mac)
  COSE_Sign_Tagged  = #6.98(COSE_Sign)
  COSE_Mac0_Tagged  = #6.17(COSE_Mac0)
  COSE_Sign1_Tagged = #6.18(COSE_Sign1)

and I was confused with the #6 and the brackets on the right side.
After reading the implementation of tinycbor and IANA,

Tinycbor
https://github.com/intel/tinycbor/blob/master/src/tags.txt
IANA
https://www.iana.org/assignments/cbor-tags/cbor-tags.xhtml

probably it is

  COSE_Mac_Tagged   = #6.97(COSE_Mac)

means that

  CBOR Tag is 97

and uses

COSE_Mac = [
    Headers,
    payload : bstr / nil,
    tag : bstr,
    recipients :[+COSE_recipient]
]

and the examples is,

    97(
      [
        / protected / h'a1010f' / {
            \ alg \ 1:15 \ AES-CBC-MAC-256//64 \
          } / ,
        / unprotected / {},
        / payload / 'This is the content.',
        / tag / h'9e1226ba1f81b848',
        / recipients / [
          [
            / protected / h'',
            / unprotected / {
              / alg / 1:-6 / direct /,
              / kid / 4:'our-secret'
            },
            / ciphertext / h''
          ]
        ]
      ]
    )

Thanks,

-Akira

On 4/9/20 12:45, Jim Schaad wrote:
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-ietf-suit-manifest-01&amp;data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7Cdddac6fb0a33483c20b308d7dc387820%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637220007412654750&amp;sdata=knhFlGCBf5M1hwal1kdnGXinEa2ROXc7cxau7GN5uOs%3D&amp;reserved=0
> 
> as
> 
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fcommit%2F151e72b0ea3ab8ff8f59ea4200&amp;data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7Cdddac6fb0a33483c20b308d7dc387820%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637220007412654750&amp;sdata=QDJd5wiBo6p2c3Z0qc9eWvKbVBkO0kA%2FhmwCcxf1O%2FU%3D&amp;reserved=0
> 4180d90006f8c9
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7Cdddac6fb0a33483c20b308d7dc387820%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637220007412654750&amp;sdata=e3YPByN13RYRMDIturl6CD5D3wue1cFaHntsxh115RQ%3D&amp;reserved=0
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 9 Apr 2020 08:40:00 +0000

Hi Akira, Hi Jim,

based on our TEEP conference call we reduced the size of options down to COSE_Sign1. Hence, the rest is gone.
That should make things easier and COSE_Sign1 is defined in the COSE spec itself.

I posted a PR with the new CDDL at https://github.com/ietf-teep/teep-protocol/pull/26

Ciao
Hannes

-----Original Message-----
From: Suit <[email-masked]> On Behalf Of Akira Tsukamoto
Sent: Thursday, April 9, 2020 8:54 AM
To: Jim Schaad <[email-masked]>; [email-masked]
Subject: Re: [Suit] Value of COSE_Mac_Tagged/COSE_Sign_Tagged/COSE_Mac0_Tagged/COSE_Sign1_Tagged

Hi Jim,

Tinycbor

probably it is

means that

  CBOR Tag is 97

and uses

COSE_Mac = [
    Headers,
    payload : bstr / nil,
    tag : bstr,

and the examples is,

    97(
      [

Thanks,

-Akira

On 4/9/20 12:45, Jim Schaad wrote:
> These values are defined in RFC 8152,
> draft-ietf-cose-rfc8152bis-struct or in the IANA registry.
>
> Jim
>
>
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftool
> s.ietf.org%2Fhtml%2Fdraft-ietf-suit-manifest-01&amp;data=02%7C01%7Caki
> ra.tsukamoto%40aist.go.jp%7Cdddac6fb0a33483c20b308d7dc387820%7C18a7fec
> 8652f409b8369272d9ce80620%7C0%7C0%7C637220007412654750&amp;sdata=knhFl
> GCBf5M1hwal1kdnGXinEa2ROXc7cxau7GN5uOs%3D&amp;reserved=0
>
> as
>
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith
> ub.com%2Fietf-teep%2Fteep-protocol%2Fcommit%2F151e72b0ea3ab8ff8f59ea42
> 00&amp;data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7Cdddac6fb0a33483c2
> 0b308d7dc387820%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637220007
> 412654750&amp;sdata=QDJd5wiBo6p2c3Z0qc9eWvKbVBkO0kA%2FhmwCcxf1O%2FU%3D
> &amp;reserved=0
> 4180d90006f8c9
> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.
> ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cakira.tsukamot
> o%40aist.go.jp%7Cdddac6fb0a33483c20b308d7dc387820%7C18a7fec8652f409b83
> 69272d9ce80620%7C0%7C0%7C637220007412654750&amp;sdata=e3YPByN13RYRMDIt
> url6CD5D3wue1cFaHntsxh115RQ%3D&amp;reserved=0
>

_______________________________________________
Suit mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/suit
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: Carsten Bormann <[email-masked]>
Date: Thu, 9 Apr 2020 13:07:21 +0200

> I posted a PR with the new CDDL at https://github.com/ietf-teep/teep-protocol/pull/26

Thanks, Hannes.  Based on this, Henk and I have done some additional cleanup.
We plan to have a first version of a PR by 1300Z.

Grüße, Carsten

---

From: Brendan Moran <[email-masked]>
Date: Thu, 9 Apr 2020 12:07:40 +0000

From a SUIT perspective, I’m still inclined to make sure that this is tagged as that allows for use-cases that we may not have considered.

Best Regards,
Brendan

> On 9 Apr 2020, at 12:07, Carsten Bormann <[email-masked]> wrote:
>

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 9 Apr 2020 14:12:07 +0200

> From a SUIT perspective, I’m still inclined to make sure that this is tagged as that allows for use-cases that we may not have considered.

Makes sense.  Let’s fix the definition of `SUIT-envelope` in the below.

Henk and I created a cleaned up version of the CBOR encoding and accompanying CDDL.
We should check whether this encoding helps us and then integrate it into the document.

https://github.com/ietf-teep/teep-protocol/pull/27

Grüße, Carsten

---

From: "Salz, Rich" <[email-masked]>
Date: Thu, 9 Apr 2020 13:29:01 +0000

>    Makes sense.  Let’s fix the definition of `SUIT-envelope` in the below.

We're missing the chance to use "overcoat" or "jacket" ... :)

---

From: Akira Tsukamoto <[email-masked]>
Date: Thu, 9 Apr 2020 22:38:07 +0900

Hi Carsten and Hannes,

The new pull request reflects all the discussion points of converting
from map and using minimum major type size for the array member.

When I was reading the cddl draft, I was not quite sure how to
describe the array with the label name.
In your pull request,

query-request = [
     type: TEEP-TYPE-query-request,
     token: uint,

The above cddl description has label name type and token with semicolon.
We were trying to avoid having label name inside the array.
I thought I have to use => for this purpose.

Other discussion we had with the teep is to use the same nonce as the
EAT defines.

nonce => bytes,
to be
nonce => bstr .size (8..64)

And the size of token we never really agreed about it.
How bout
  token: uint .size 4

The 32bit unsign integer seems to be reasonable for the usage in teep.

Best,
-Akira

On Thu, Apr 9, 2020 at 9:12 PM Carsten Bormann <[email-masked]> wrote:
> TEEP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/teep

---

From: Henk Birkholz <[email-masked]>
Date: Thu, 9 Apr 2020 16:13:31 +0200

Hello Akira,

in an array context, the name (aka label) is annotation only. It is not 
transferred over "the wire", so we did not bother to define a 
corresponding type.

In other words, you could simply omit "type: " and "token: " and nothing 
would change. It is annotation for humans, basically.

See https://tools.ietf.org/html/rfc8610#section-2.1

Viele Grüße,

Henk

---

From: Akira Tsukamoto <[email-masked]>
Date: Fri, 10 Apr 2020 08:43:37 +0900

Hi Henk,

Thanks for you comment.
I now am perfectly clear about the label name is just annotation for array in cddl.

Best,
-Akira

On 4/9/2020 11:13 PM, Henk Birkholz wrote:
> Hello Akira,
> 
> in an array context, the name (aka label) is annotation only. It is not transferred over "the wire", so we did not bother to define a corresponding type.
> 
> In other words, you could simply omit "type: " and "token: " and nothing would change. It is annotation for humans, basically.
> 
> See https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc8610%23section-2.1&amp;data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C85cf47c432354e5fa73a08d7dc903817%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637220384303337245&amp;sdata=%2B%2Bm5aUI2zpFdEXec5dNElG4KNhC%2B60TeUDxMcXjtGqo%3D&amp;reserved=0
> 
> Viele Grüße,
> 
> Henk
> 
>> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fpull%2F27&amp;data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C85cf47c432354e5fa73a08d7dc903817%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637220384303337245&amp;sdata=ZDVr31cNQdQNR5H2bcvnC%2Bj7m%2BDgVz1kIe4us99%2B%2BsA%3D&amp;reserved=0
>>
>>> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fietf-teep%2Fteep-protocol%2Fpull%2F27&amp;data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C85cf47c432354e5fa73a08d7dc903817%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637220384303337245&amp;sdata=ZDVr31cNQdQNR5H2bcvnC%2Bj7m%2BDgVz1kIe4us99%2B%2BsA%3D&amp;reserved=0
>>>
>>> Grüße, Carsten
>>>
>>> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep&amp;data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C85cf47c432354e5fa73a08d7dc903817%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637220384303337245&amp;sdata=CG21OuaA8t16%2BzyvSFazbG3l2sEpc9sa8trHUmX5TBI%3D&amp;reserved=0
>>
>> https://jpn01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsuit&amp;data=02%7C01%7Cakira.tsukamoto%40aist.go.jp%7C85cf47c432354e5fa73a08d7dc903817%7C18a7fec8652f409b8369272d9ce80620%7C0%7C0%7C637220384303337245&amp;sdata=Cc9I9ZFT4Ms%2BI198MQw%2B78aJxlDsTlH0EonuB%2B7rKUg%3D&amp;reserved=0
>>