2) Developers Gatherings
3) SUIT Architecture
4) SUIT Information Model
5) SUIT Manifest Format
6) Any Other Business (if time permits)
Report from SUIT Hackathon on 13 July 2020 is here: https://www.ietf.org/proceedings/108/slides/slides-108-suit-hackathon-report-00
Note to chairs: Don't schedule the hackathon on the same day as the IETF draft deadline.
RD: In IETF last call - has some comments but can be dealt with as last call comments
RD: Still working on the AD Review
BM: Any place where there is not clarity or pointers are wrong it would be nice to get these so they can be fixed in terms of orginization.
BM: Should manifest layout be described before the processing is done.
RH: & DT: Pick one - but probably yes
DT: Hints for reporting and attestation are not the same
BM: Yes - result depends on what the reporting system is. Bootloader with no network access would need to do attestation for protection from app.
BM: Three options for how to use packed CBOR when available. Personal preference would be use in v2 format. But can cause a fracturing of the ecosystem
RH: Worry if people know v2 is coming they might not do v1.
HB: Would take option 2 by elimination of the other options. Not great but can't wait.
DT: If no extra bytes from packed then don't worry about the v2 in the future.
MCR: A time to a stable version of packed CBOR is going to be shorter than RFC.
BM: We are going to want to influence how packed CBOR is done.
BM: Based on comments - currently should do nothing. If benefit comes, then deal with this later. Work on a v2 ONLY IF it offers a reduction in size that is meaningful.
DT: Same thing if we need to do an addition to SUIT for new feature. Big issue is keeping backwards compatability.
BM: Easier to see how this works for features advertised in the manifest rather than the encoding of the manifest itself.
DT: Perhaps need to add a capability for feature identifiers even if we don't have an option yet.
BM: Yes, but should be new/different draft.
DB : Will the packed representation be optional?
BM: Can just pack what we got, which will mostly be fine. However could also redesign how manifest is laid out. Example would be no need for component indexes because this is dealt with by the packing system.
HT: TEEP protocol does have some basic reporting of capabilities. Might need more details specified if this is done.
CONSENSUS -- leave manifest as-is for now; consider in the future implementation as an extension, or a SUIT manifest v2, if there is a benefit offered by packing.
BM: Current processing of COSE requires random access of the manifest to build the hash which is signed. Look at making the layout of the data so that it can be done linearly by. Put a suit digest in the COSE signature payload inline not detached. Digest applies to the manifest. But the signature can be computed based on the current data already received. Does add some space of one digest per manifest thing.
BM: Snide remark: Packed CBOR would deal with the multiple authentication issue by extracting hash items.
BM: Should we take the SUIT_Digest out and instead use the authentication in the array?
RH: I think that makes sense.
RH: If a subdomain of a PEN is used, can delegate the sub-arc of the PEN when subsidary sold.
DT: Third disadvange is common to both. Sub-registration is going to generate a new uuid. PEN could get get a new one for each list
BM: IANA says get a sub PEN not a new one -- delegate
DT: Does any of this apply to class ID as well?
BM: Not readable text. for class id this is not designed for reverse lookup. All of the model information needs to be part of the class identifier.
DT: Can do comparisions on the values but can only do reverse lookup if publicly available database exists.
DT: This could play interesting with packed CBOR
BM: With packed CBOR this could go away then - use local dictionary on the device and all of this disappears.
BM: Not opposed to using PEN for vendor ID. Want to ask about orgs that don't want to have any public exposure in a database. Experience says that class mappings will be published if "easy" to do.
HB: Multiple ways to deal with shy orgs. Example of splitting PENs to positive/neg numbers - increase space. Loose collision prevention if this is not arbitrated.
BM: Either randomness or authority for dealing with uniqueness. We could recommend using the vendor name as the bstr, and allow fallback to the PEN as an integer. The data type indicates the kind of information provided.
DT: Love Henk's idea.
DB: What is scope of uniqueness here?
BM: Goals: My one vendor produces two devices which are incompatable. Prevent cross loading of data. Two jurisdictions all for the same name to be used for different companies. Problem can come back if locally signatures are striped and added. This prevents just the public key from providing differentiation. Secondary issue is delegation of manifests. Example of vendor ships device, but uses a different vendor's operation system update. Needs to be able to identify both vendor ids in the manifest shipped by vendor #1. Asking every user to get a PEN might be a non-starter
RH: Think discussion has resolved this.
DT: Does the thing after the comma - is that a PEN or a full ID
BM: It's a full OID.
BM: Vendor ID is an array of UINT (for a PEN) or a bstr.
BM: Class ID - prefix it uses is a UUID. computed from OID representation of vendor ID.
DT: Keep class ID discussion on the list
DB: Envision the use of conflicting negative numbers from combined manifests
BM: Yes it would be fine as long as different custom parsers are used based on the multiple manifest guidance in the draft.
DT: Can say that interpretation of negative numbers is driven by the vendor ID?
JS: Can the same negative number mean different things for different devices?
DT: Does this mean that the negative number needs to be scoped for class id?
RH: Need some advice that says don't reuse the same negative number across devices for different things. Hackthon project to validate that all of the rules in a manifest are correct.
BM: Add text that if fine - only needed if 3 or more. Any commentary?
No input from WG; leave conditions and directives as-is. Move Abort from command to condition.
Want to simplify
JS: Use the new << >> diagnostic text from the CDDL document to do this.
BM: Authors think that all needed data is there. Want input from TEEP.
DT: Answer might be yes - implicit creation of security domains based on ID deletion of security domains - garbage collection? For component IDs if last item is removed then container should be removed - more than just a TEEP issue
BM: Should handle that more explicitly. Go to list on question of explicit deletion
DT: If larger issue then should create a tracking issue. Add new dependency delete old one
BM: Can replace old with new by using the same id. Could also replace with zero size object.
DT: Sometimes the same identifier cannot be reused for different reasons. Need to be explicit in document.
DT: Handle case where binary is already local and need to get information to install it. Not sure if everything is right.
DW: At what point do we cut off this discussion and publish the draft? We do have IANA registration for going forward.
BM: Is there enough to support RATS?
DT: (as individual, not as chair) Should factor reporting stuff into a new draft
BM: Sounds fine.
DT: Potentially up to four additional drafts from discussions.
RH: Question - do we recharter for this? Take to the mail list.
Assign DW to start the recharter discussion.
*[RD]: Roman Danyliw
*[BM]: Brendan Moran
*[DT]: Dave Thaler
*[RH]: Russ Housley
*[HT]: Hannes Tschofenig
*[HB]: Henk Birkholz
*[MCR]: Micheal Richardson
*[DB]: David Brown
*[JS]: Jim Schaad
*[DW]: David Waltermire