Re: [Teep] JSON/JOSE vs. CBOR/COSE

Thanks, Akira.

If we decide to only use CBOR/COSE for the TEEP protocol then the draft becomes simpler. It still make sense to put examples with CBOR diagnostic format into the draft. That's something we should certainly do.

I am pushing for a decision about this topic because
* the draft needs to be updated in time for the IETF submission deadline,
* the reference implementations need to progress, and
* making a decision gives us clarity about the direction we are heading.

For the reference implementation I am wondering whether it makes sense to re-use QCBOR and an enhanced version* of t_cose. Hackathon participants were quite impressed with QCBOR and t_cose.

Ciao
Hannes

*: I am speaking about an enhanced version because t_cose implements only verifying digital signatures. The sign functionality is missing. (At least that's my understanding.)

-----Original Message-----
From: Akira Tsukamoto <akira.tsukamoto@gmail.com>
Sent: Monday, February 24, 2020 2:01 PM
To: Henk Birkholz <henk.birkholz@sit.fraunhofer.de>
Cc: Konda Tirumaleswar Reddy <TirumaleswarReddy_Konda@mcafee.com>; Mingliang Pei <mingliang.pei=40broadcom.com@dmarc.ietf.org>; Nicolae Paladi <nicolae.paladi@ri.se>; Hannes Tschofenig <Hannes.Tschofenig@arm.com>; teep <teep@ietf.org>
Subject: Fwd: [Teep] JSON/JOSE vs. CBOR/COSE

I mistakenly dropped many addresses when I pressed button gmail, this is resend which I sent to Henk only.

>         On 20 Feb 2020, at 11:16, Hannes Tschofenig
>         <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com>>
>         wrote:
>
>         With the impression from the Hackathon in mind I am wondering
>         whether we should make a decision about the encoding of the TEEP
>         protocol messages. Today, the spec allows two types of
>         encodings, namely JSON and CBOR (with their security mechanisms).
>
>         It is obviously a pain to implement both encodings. The spec
>         supports two encodings because the OTrP design was based on JSON
>         / JOSE and it felt logical to “inherit” this encoding. Then, we
>         added CBOR and COSE for use with constrained devices.
>
>         I believe we should only have one encoding.
>
>         CBOR and COSE appear to be the better choice (although I have
>         been working on an implementation of JSON and JOSE at the
>         Hackathon). While JSON/JOSE is easier to debug the TEEP protocol
>         is actually quite simple. The use of CBOR/COSE will allow us to
>         keep the trusted computing base smaller considering that SUIT
>         manifests as well as EAT tokens are/can be encoded in CBOR and
>         protected by COSE.

The Hackathon at  Berlin was really productive and thanks.

I personally do not mind if the protocol spec becomes having only CBOR/COSE and drop JSON/JOSE.

I think we have two discussion on this topic, one is completing the draft and other is whether the TAM implementation must support support both CBOR and JSON.

It is very good to have some kind of reference implementation of TEEP along side with the spec draft, so I would prefer having the current implementation started on JSON to be finished and fill out the details in the spec for what we have discussed during the Hakathon.

The sequences of TEEP in JSON which I was wroking on at the Hackathon are still not mature.
https://github.com/ietf-teep/teep-protocol/issues/7
The suit representation is not there yet either.

These are the links I would like to reflect on the draft before the next IETF hackathon.
https://github.com/ietf-teep/architecture/issues/151
https://github.com/ietf-teep/teep-protocol/issues/6
https://github.com/ietf-teep/teep-protocol/issues/5
https://github.com/ietf-teep/teep-protocol/issues/4 <- we had conclusion at the Hakathon on this

Otherwise I am bit concerned many people having different interpretation from reading the draft and many implementation suffering interoperability.
Once the details is addressed in the JSON then having CBOR representation in the spec is fine.
The cbor-diag tool mentioned by Carsten at the other thread is great.
It is good if somebody starts CBOR implementation in the time being.

My thought was that switching to CBOR only and no JSON now for the Hackathon is that the TAM side is possible to talk CBOR relatively easy since there is "npm install cbor" to use cbor library with javascript, but for the implementation on TEEP device side, there are cn-cbor and tiny-cbor for c language which is not so easy for try and error and changing the message formats while the draft is also moving.

The other topic of requiring the TAM to support both JSON and CBOR in the draft, I do not feel that it should have to support both.
TAM talking otrp with json or/either teep with cbor is fine for me.

-Akira

On Fri, Feb 21, 2020 at 6:49 PM Henk Birkholz <henk.birkholz@sit.fraunhofer.de> wrote:
>
> Hi Tiru,
>
> I'd stay in the scope of CBOR and use cbor-diag. As cbor-diag can be
> directly translated into CBOR data items, that is the notation I am
> working with on a daily basis.
>
> If needed, a JSON data item can be derived from cbor-diag quite easily.
>
> Viele Grüße,
>
> Henk
>
> On 21.02.20 04:43, Konda, Tirumaleswar Reddy wrote:
> > The protocol draft can discuss either CBOR to JSON conversion or
> > diagnostic notation discussed in
> > https://tools.ietf.org/html/rfc7049#section-6 to ease debugging.
> >
> > -Tiru
> >
> > *From:* TEEP <teep-bounces@ietf.org> *On Behalf Of * Mingliang Pei
> > *Sent:* Thursday, February 20, 2020 10:52 PM
> > *To:* Nicolae Paladi <nicolae.paladi@ri.se>
> > *Cc:* Hannes Tschofenig <Hannes.Tschofenig@arm.com>; teep@ietf.org
> > *Subject:* Re: [Teep] JSON/JOSE vs. CBOR/COSE
> >
> > *CAUTION*:External email. Do not click links or open attachments
> > unless you recognize the sender and know the content is safe.
> >
> > --------------------------------------------------------------------
> > ----
> >
> > I agree we move forward TEEP protocol with one mandatory format:
> > CBOR / COSE, and focus on specifying only one for now. Thanks, Ming
> >
> > On Thu, Feb 20, 2020 at 6:26 AM Nicolae Paladi <nicolae.paladi@ri.se
> > <mailto:nicolae.paladi@ri.se>> wrote:
> >
> >
> >
> >         On 20 Feb 2020, at 11:16, Hannes Tschofenig
> >         <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com>>
> >         wrote:
> >
> >         Hi all,
> >
> >         With the impression from the Hackathon in mind I am wondering
> >         whether we should make a decision about the encoding of the TEEP
> >         protocol messages. Today, the spec allows two types of
> >         encodings, namely JSON and CBOR (with their security mechanisms).
> >
> >         It is obviously a pain to implement both encodings. The spec
> >         supports two encodings because the OTrP design was based on JSON
> >         / JOSE and it felt logical to “inherit” this encoding. Then, we
> >         added CBOR and COSE for use with constrained devices.
> >
> >         I believe we should only have one encoding.
> >
> >         CBOR and COSE appear to be the better choice (although I have
> >         been working on an implementation of JSON and JOSE at the
> >         Hackathon). While JSON/JOSE is easier to debug the TEEP protocol
> >         is actually quite simple. The use of CBOR/COSE will allow us to
> >         keep the trusted computing base smaller considering that SUIT
> >         manifests as well as EAT tokens are/can be encoded in CBOR and
> >         protected by COSE.
> >
> >     I agree, better to focus on one format.
> >
> >     Best regards,
> >
> >     Nicolae
> >
> >
> >
> >         With this email I wanted to kick-off a discussion. What do you
> >         think?
> >
> >         Ciao
> >
> >         Hannes
> >
> >         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. _______________________________________________
> >         TEEP mailing list
> >         TEEP@ietf.org <mailto:TEEP@ietf.org>
> >         https://www.ietf.org/mailman/listinfo/teep
> >
> > <https://clicktime.symantec.com/3MSsiXmEmb2Dwfb5s7ZBbYv7Vc?u=https%3
> > A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep>
> >
> >     _______________________________________________
> >     TEEP mailing list
> >     TEEP@ietf.org <mailto:TEEP@ietf.org>
> >
> > https://clicktime.symantec.com/3MSsiXmEmb2Dwfb5s7ZBbYv7Vc?u=https%3A
> > %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
> >
> >
> > _______________________________________________
> > TEEP mailing list
> > TEEP@ietf.org
> > https://www.ietf.org/mailman/listinfo/teep
> >
>
> _______________________________________________
> TEEP mailing list
> TEEP@ietf.org
> https://www.ietf.org/mailman/listinfo/teep
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.