Subject: [Suit] Question about draft-moran-suit-manifest-00.txt

From: "Dr. Pala" <[email-masked]>
Date: Mon, 13 Nov 2017 15:22:10 +0800

Hi all,

I quickly skimmed the draft and I have a question for the authors. In 
particular, it seems that the authors mandate for the use of CBOR for 
authentication/encryption of Payload (COSE_Encrypt) and Manifest 
(COSE_Mac, COSE_Mac) without, AFAIK, ever mentioning CBOR explicitly.

If that is correct (I got through it VERY quickly), since the Charter 
explicitly focuses on ASN.1 encoding (and CBOR, if ever, might be 
considered in the future), I am a little confused about the use of COSE 
in the I-D.

Can the author(s) provide some clarification on this point ?

Cheers,
Max

-- 
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
OpenCA Logo

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Nov 2017 16:04:12 +0800

On Nov 13, 2017, at 15:22, Dr. Pala <[email-masked]> wrote:
> 
> Hi all,
> 
> I quickly skimmed the draft and I have a question for the authors. In particular, it seems that the authors mandate for the use of CBOR for authentication/encryption of Payload (COSE_Encrypt) and Manifest (COSE_Mac, COSE_Mac) without, AFAIK, ever mentioning CBOR explicitly. 
> If that is correct (I got through it VERY quickly), since the Charter explicitly focuses on ASN.1 encoding (and CBOR, if ever, might be considered in the future), I am a little confused about the use of COSE in the I-D.
> 

I’m not an author, but I think it is abundantly clear that the current draft charter text does not reflect the current consensus.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Mon, 13 Nov 2017 09:57:46 +0000

Hi Max,

Our initial submission described the implementation we have with the mbed update service. It uses ASN.1 and we described why we thought the choice of ASN.1.

From the mailing list we learned that the cool kid in town is now COSE/CBOR. Hence, we have tried to reflect this aspect in the design. Of course, the current version of the document is not inline with our implementation anymore.

What format(s) the group will select in the end remains to be seen.

Ciao
Hannes

From: Suit [mailto:[email-masked]] On Behalf Of Dr. Pala
Sent: 13 November 2017 15:22
To: [email-masked]
Subject: [Suit] Question about draft-moran-suit-manifest-00.txt

Hi all,

Cheers,
Max
--
Best Regards,
Massimiliano Pala, Ph.D.
OpenCA Labs Director
[OpenCA Logo]
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: "Dr. Pala" <[email-masked]>
Date: Mon, 13 Nov 2017 22:29:58 +0800

Hi Hannes,

thanks for the clarification :D My personal experience is that with 
device vendors is that they will go long way to even "simplify" dealing 
with encoding (or, as it seems in this case, more decoding).

Maybe there could be also some space for considering ad-hoc (instead of 
generic encoding rules) binary formats that can be better understood by 
device manufacturer (that usually complain about having even a 5-10k 
enc/dec library... :D).

Thanks Again,

Ciao,
Max

On 11/13/17 5:57 PM, Hannes Tschofenig wrote:
>
> Hi Max,
>
> Our initial submission described the implementation we have with the 
> mbed update service. It uses ASN.1 and we described why we thought the 
> choice of ASN.1.
>
> From the mailing list we learned that the cool kid in town is now 
> COSE/CBOR. Hence, we have tried to reflect this aspect in the design. 
> Of course, the current version of the document is not inline with our 
> implementation anymore.
>
> *From:*Suit [mailto:[email-masked]] *On Behalf Of *Dr. Pala
> *Sent:* 13 November 2017 15:22
> *To:* [email-masked]
> *Subject:* [Suit] Question about draft-moran-suit-manifest-00.txt
>
> Hi all,
>
> considered in the future), I am a little confused about the use of 
> COSE in the I-D.
>
> 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.
>
>
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: Carsten Bormann <[email-masked]>
Date: Mon, 13 Nov 2017 23:21:25 +0800

On Nov 13, 2017, at 22:29, Dr. Pala <[email-masked]> wrote:
> 
> Maybe there could be also some space for considering ad-hoc (instead of generic encoding rules) binary formats that can be better understood by device manufacturer (that usually complain about having even a 5-10k enc/dec library... :D).

Prepare to spend 722 bytes of code for the CBOR decoder library (unless you need floating point data, then it becomes around 800).

Grüße, Carsten

---

From: "Dr. Pala" <[email-masked]>
Date: Tue, 14 Nov 2017 00:15:53 +0800

Hi Carsten,

that is really interesting! Can you please provide a reference to such 
implementation?

Thanks,
Max

---

From: Brendan Moran <[email-masked]>
Date: Mon, 13 Nov 2017 19:25:01 +0000

Hi Max,

There are many implementations listed here: http://cbor.io/impls.html
I believe the one that Carsten is referring to is this one: https://github.com/cabo/cn-cbor

Best Regards,
Brendan

On 13 Nov 2017, at 16:15, Dr. Pala <[email-masked]<mailto:[email-masked]>> wrote:

Hi Carsten,

that is really interesting! Can you please provide a reference to such implementation?

Thanks,
Max

On 11/13/17 11:21 PM, Carsten Bormann wrote:
On Nov 13, 2017, at 22:29, Dr. Pala <[email-masked]<mailto:[email-masked]>> wrote:
Maybe there could be also some space for considering ad-hoc (instead of generic encoding rules) binary formats that can be better understood by device manufacturer (that usually complain about having even a 5-10k enc/dec library... :D).
Prepare to spend 722 bytes of code for the CBOR decoder library (unless you need floating point data, then it becomes around 800).

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

---

From: "Dr. Pala" <[email-masked]>
Date: Tue, 14 Nov 2017 07:20:53 +0800

Hi Brendan,

thanks for the reference. From a quick scan of the C implementation it 
seems they all seem implementations that require an OS and/or stdlib (I 
might be wrong, though :D). Does anybody on the list have experience (or 
references) with developing CBOR on a microcontroller ?

Cheers,
Max

On 11/14/17 3:25 AM, Brendan Moran wrote:
>>>> Maybe there could be also some space for considering ad-hoc 
>>>> (instead of generic encoding rules) binary formats that can be 
>>>> better understood by device manufacturer (that usually complain 
>>>> about having even a 5-10k enc/dec library... :D).
>>> Prepare to spend 722 bytes of code for the CBOR decoder library 
>>> (unless you need floating point data, then it becomes around 800).
>>>
>>
>> [email-masked] <mailto:[email-masked]>

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 14 Nov 2017 08:18:32 +0800

> On Nov 14, 2017, at 07:20, Dr. Pala <[email-masked]> wrote:
> 
> Hi Brendan,
> 
> thanks for the reference. From a quick scan of the C implementation it seems they all seem implementations that require an OS and/or stdlib (I might be wrong, though :D). Does anybody on the list have experience (or references) with developing CBOR on a microcontroller ?

cn-cbor was specifically designed to run in an environment without malloc (even though it defaults to using it) — that’s where the code size measurements are from.  There are a few other implementations of this kind, e.g. the one in RIOT (which does need some serious attention, though). Of course, the majority of the 45 implementations for 20 programming languages are for general purpose environments, if only because the language itself is so.  C, C++, and maybe Rust are the languages used in the embedded space.

Grüße, Carsten

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 Nov 2017 06:29:03 +0000

Carsten,

It is not just CBOR but also COSE that needs to be implemented.

Ciao
Hannes

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Carsten Bormann
Sent: 13 November 2017 23:21
To: Dr. Pala
Cc: [email-masked]
Subject: Re: [Suit] Question about draft-moran-suit-manifest-00.txt

Grüße, Carsten

---

From: "Dr. Pala" <[email-masked]>
Date: Tue, 14 Nov 2017 14:48:15 +0800

Hi Hannes,

Maybe I am wrong, but I it might not necessarily be true. Could, for 
example, the authentication data be a PKIX detached signature over the 
CBOR blob ?

Cheers,
Max

---

From: Hannes Tschofenig <[email-masked]>
Date: Tue, 14 Nov 2017 06:51:57 +0000

Hi Max,

My understanding was that those folks asking for CBOR encoding actually meant that they want to use CBOR encoding of the manifest, which is then protected by the COSE security mechanisms. So, you will need a parser that supports COSE, which uses CBOR.

Ciao
Hannes

-----Original Message-----
From: Suit [mailto:[email-masked]] On Behalf Of Dr. Pala
Sent: 14 November 2017 14:48
To: [email-masked]
Subject: Re: [Suit] Question about draft-moran-suit-manifest-00.txt

Hi Hannes,

Maybe I am wrong, but I it might not necessarily be true. Could, for example, the authentication data be a PKIX detached signature over the CBOR blob ?

Cheers,
Max

---

From: Brendan Moran <[email-masked]>
Date: Tue, 14 Nov 2017 09:41:32 +0000

Yes COSE permits this for very little overhead above the CBOR parser and the signature verification mechanism.

Best Regards,
Brendan

> On 14 Nov 2017, at 06:48, Dr. Pala <[email-masked]> wrote:
>
> Hi Hannes,
>