Subject: [Suit] New preliminary information model draft

From: Brendan Moran <[email-masked]>
Date: Wed, 13 Jun 2018 14:23:51 +0000

I have uploaded a new information model draft to the suit-wg repo:
https://github.com/suit-wg/information-model/blob/v01/draft-ietf-suit-information-model.md

You can see the diff using Github’s comparison tool:
https://github.com/suit-wg/information-model/compare/master...v01

Best Regards,
Brendan

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, 14 Jun 2018 13:06:31 +0200

… and, if you are interested in this, you may want to take part in the informal web call we are having in about 23 minutes at

> 	13:30..15:00 CEST on https://jitsi.tools.ietf.org/suit-dt

Grüße, Carsten

> On Jun 13, 2018, at 16:23, Brendan Moran <[email-masked]> wrote:
> 
> _______________________________________________
> Suit mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/suit

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Jun 2018 13:15:27 +0200

I believe MFT10 and its mitigations still confuse

— is the sender *authorized* to make claims about the firmware image at hand for device X
— does the sender *intend* to make a claim about this firmware destined for device X

The first one can be supported by ACLs.
But the sender may very well be authorized to make a claim, it may just not want to, pertaining to device X.

In general, signed claims may need destination verification.

In a CWT, this is often done with the “aud” claim field.
I have not made up my mind if something like that is enough here as well or we need something more well structured for destination verification.

Grüße, Carsten

---

From: Carsten Bormann <[email-masked]>
Date: Thu, 14 Jun 2018 13:29:16 +0200

A few more items (some editorial):

"optional to implement" -- do we need to talk about protocol evolution
(extensibility), specifically about ignorable (elective) and mandatory
(critical) elements?

* referencing RFC 4122: cite in 4.3
* why are we using pre-RFC5378 boilerplate?
* The "use UTC as serial" text is a hint for implementers/users, not part of the information model.
* Confidential Information Disclosures (what is confidential?) -> Disclosures of Confidential Information

* "version" (an identifier space implying some form of ordering) vs. "identifier" (no such implication)
* "last application time" -- the time this was last applied?

Grüße, Carsten

> On Jun 14, 2018, at 13:15, Carsten Bormann <[email-masked]> wrote:
>