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

[Hannes Tschofenig <[e-mail]>]

I believe it is fine for anyone to start coding the messages in JSON for a prototype, as we did at the Hackathon, but another thing to describe two encodings in the spec. This does create a fair amount of interoperability problems later on. FWIW I am going to change my code to CBOR/COSE

-----Original Message-----
From: 塚本明 <[e-mail]>
Sent: Tuesday, February 25, 2020 9:37 AM
To: Henk Birkholz <[e-mail]>; Hannes Tschofenig <[e-mail]>
Cc: Konda Tirumaleswar Reddy <[e-mail]>; Nicolae Paladi <[e-mail]>; teep <[e-mail]>; Mingliang Pei <mingliang.pei=[e-mail]>
Subject: Re: [Teep] JSON/JOSE vs. CBOR/COSE


On 2020/02/24 22:44, Henk Birkholz wrote:
> Yes, absolutely. +4 on all four points.
>
> I just wanted to highlight Akira's comment that was:
>
> On 24.02.20 07:09, Akira Tsukamoto wrote:
>> 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.
>
> This approach would deduct from the benefits that were illustrated in this thread. I am not in favor of this approach, but there might be necessities that I am unaware of?

I am not sure which is beneficial or not, but I just did not see comments for the teep draft from the implementation perspective from who have tried CBOR on teep at the moment, so I felt that being able to start early with JSON was a good thing.

Also, during the hackathon at Berlin, we did have a code to show the contents of teem messages in the sources but at the end we had to use WireShark to debug when we could not figure out why it is giving some of the parsing errors for received message, so having text representation in the binary packet helped the prototyping.

I am ok for CBOR only after everything is smoothed out, just wanted to make things forward.

-Akira

>
> Viele Grüße,
>
> Henk
>
>
> On 24.02.20 08:39, Hannes Tschofenig wrote:
>> My idea was to use
>> * CDDL to describe the protocol messages (as it is already done in the spec).
>> * the CBOR diagnostic format for examples.
>> * CBOR for the over-the-wire encoding.
>> * COSE as the security-wrapper for the protocol messages.
>>
>> I believe this is also inline with your thinking. Correct?
>>
>> -----Original Message-----
>> From: Henk Birkholz <[e-mail]>
>> Sent: Monday, February 24, 2020 2:24 PM
>> To: Hannes Tschofenig <[e-mail]>; Akira Tsukamoto
>> <[e-mail]>
>> Cc: Konda Tirumaleswar Reddy <[e-mail]>;
>> Mingliang Pei <mingliang.pei=[e-mail]>; Nicolae
>> Paladi <[e-mail]>; teep <[e-mail]>
>> Subject: Re: [Teep] JSON/JOSE vs. CBOR/COSE
>>
>> Hi all,
>>
>> while I am of course in favor of using cbor-diag, please mind that
>> would be a CBOR instance example. In general, the message structure (that the cbor-diag is an example of) should be illustrated (or specified, depending on the nature of the document) in CDDL.
>>
>> I do not object to start with JSON and then finalizing with CBOR only, in principle. The only caveat here is that a lot of the benefits by using CBOR only that were highlighted in this thread are lost for the most part of the way, if you start with JSON.
>>
>> Viele Grüße,
>>
>> Henk
>>
>> On 24.02.20 08:12, Hannes Tschofenig wrote:
>>> 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 <[e-mail]>
>>> Sent: Monday, February 24, 2020 2:01 PM
>>> To: Henk Birkholz <[e-mail]>
>>> Cc: Konda Tirumaleswar Reddy <[e-mail]>;
>>> Mingliang Pei <mingliang.pei=[e-mail]>; Nicolae
>>> Paladi <[e-mail]>; Hannes Tschofenig
>>> <[e-mail]>; teep <[e-mail]>
>>> 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
>>>>           <[e-mail]
>>>> <mailto:[e-mail]>>
>>>>           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 <[e-mail]> 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 <[e-mail]> *On Behalf Of * Mingliang Pei
>>>>> *Sent:* Thursday, February 20, 2020 10:52 PM
>>>>> *To:* Nicolae Paladi <[e-mail]>
>>>>> *Cc:* Hannes Tschofenig <[e-mail]>; [e-mail]
>>>>> *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
>>>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>>>
>>>>>
>>>>>
>>>>>           On 20 Feb 2020, at 11:16, Hannes Tschofenig
>>>>>           <[e-mail]
>>>>> <mailto:[e-mail]>>
>>>>>           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
>>>>>           [e-mail] <mailto:[e-mail]>
>>>>>           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
>>>>>       [e-mail] <mailto:[e-mail]>
>>>>>
>>>>> https://clicktime.symantec.com/3MSsiXmEmb2Dwfb5s7ZBbYv7Vc?u=https%
>>>>> 3A %2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fteep
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> TEEP mailing list
>>>>> [e-mail]
>>>>> https://www.ietf.org/mailman/listinfo/teep
>>>>>
>>>>
>>>> _______________________________________________
>>>> TEEP mailing list
>>>> [e-mail]
>>>> 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.
>>>
>> 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
> [e-mail]
> 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.