Virtual Interim meeting RATS/TEEP/SUIT Wednesday January 26, 1800UTC webex: Slides are at: * https://datatracker.ietf.org/meeting/interim-2022-rats-01/materials/slides-interim-2022-rats-01-sessa-teep-requirements-relevant-to-class-id-discussion-00 Present: 1. Ira McDonald 2. Laurence Lundblade 3. Nancy Cam-Winget 4. Ned Smith 5. Roman Danyliw 6. Russ Housley 7. Hannes Tschofening 8. Henk Birkholz 9. Scott Fluhrer 10. David Waltermire 11. Dick Wilkins 12. Michael Richardson 13. Dave Thaler 14. Brendan Moran 15. Kathleen Moriarty 16. Guy Fedorkow Notes taken by Michael Richardson, Nancy Cam-Winget, and Russ Housley Note Well presented Dave Thaler talking about slides. Presenting TEEP use cases that describe requirements for SUIT and RATs. MCR asked if a Venn diagram has been attempted. DT suggested that requirement 1 and 2 might be satisfied by a single claim registry, but that hardware might have multiple claims associated with them, but was uncertain if that translated to a single claim in the Evidence. BR: we just need to know if it is compatible, so any identifier works, as long as it matches and does not overlap. MCR departs meeting here. (13:28) DT: mentions that there are 2 related topics: what goes into a SUIT manifest (that the attester uses to evaluate its relevance), the second pieces is the evaluation of the actual attestation values. The purpose of this meeting is to determine what should go into the SUIT manifest but can also have discussion of the interdependencies. Describes the TEEP use case and its need to determine what the SUIT manifest should contain. BM: aligns in general...attestation evidence doesn't need to have information about the taxonomy to reduce bandwidth, especially for small devices. Don't send redundant information. DT: what would verifier use? BM: identifiers need to indicate many different things, and it could be a list of identifiers, or single that names the whole bundle. Can we support both approaches? DT: there are large devices that Intel is generating vs. IoT (constrained devices) BM: we should not preclude either case DT: a specific device might be designed to implement a particular specification, but it will just identify the device model BM: understands Dave's point, attestation results do need more detail as the verifier will need that information; but sees that we should not require it i the evidence DT: any claim you put in attestation result, there may be a manufacturer that may want to put it as evidence HB: the claims cannot be globally understood DT: it's a policy decision HB: but it could be overloaded in a signature DT: from TEEP perspective, it doesn't care what's in the evidence as it never sees evidence. It cares about what is in the attestation result. NS: Does the attestation ?? DT: reiterates TEEP only cares about what's in the attestation result as the evidence is passed as an opaque result Brendan presents. Created slides with Henk, to discuss what is in the SUIT report draft and the SUIT EAT claims (in RATs). Describes the relationship between the drafts. There may be overlap in the parameters for the SUIT components that is also defined in the SUIT EAT claims; proposes convergence to a component that is referenced in the SUIT reports draft by defining one EAT claim that gets defined in the SUIT RATs claims draft. RH: trying to understand recommendation BM: clarifies the converged proposal DT: not sure he understands proposal BM: SUIT EAT claims draft has every SUIT parameter as a claim, but that needs to be reworked. But those identifiers are already defined in SUIT manifest draft; doing the translation to a claim seems a lot of extra work that may not be necessary. The SUIT report has a way to help as it has a container definition that can be used as the EAT claim DT: (he speaks too fast!) Seems some claims seem to be in duplication HB: existing definition of the system and SUIT claims should be semantically equivalent to what is being defined in RATs DT: presented a table that showed claims that are already represented in the EAT draft. BM: it's legitimate to have in SUIT multiple class and vendor claims (even encouraged), but not sure how that maps in RATs DT: asks to clarify are you trying to identify vendor or class? Are they in the same claim set or they are atomic within a claim set but can have multiple claims BM: both DT: elaborates on use case BM: can have a single component that matches different classes. Describes example for running checks of bootloader vs. hardware. DT: within each claim set, each would be a singleton claim. Class identifier can see that one as being interesting and maybe seeing it in multiple claim sets vs. multiple values LL: discussion is more about software compatibility. If there are clear claims that we have agreement and are broad for software updates, they can be included in the EAT document. But it seems that it is more SUIT specific vs. EAT claims. Preference is that it is not in the EAT document and not hold the EAT draft. BM: agrees and is suggesting that the document gets moved out of RATs and go into SUIT HB: can use the definitions used in SUIT, but the equivalences need to be clarified and explicitly spelled out which can be done in SUIT LL: just wants to ensure that we don't duplicate HB: device, vendor and version are the three that overlap LL: the claims iof interest are UUID, hardware vendor/OEM, hardware model and hardware version those are the relevant claims he sees as needing discussion. Vendor not attestor. NS: that is the discussion that we should focus on, question is where should that discussion happen (RATs or SUIT)? LL: if it's a claim then RATs; both in its semantic meaning and how it is used RH: that makes sense, but from SUIT charter, one of the points of description for firmware status should be done in SUIT independent of whether it uses EAT DT: that's what his presentation was trying to highlight, given the overlap. SUIT can define how the claims are used NS: does any of this tie into which drafts need to be adopted? DT: Laurences has already specified that EAT spec already has the claims that should map to SUIT HB: Can Dave T. reiterate the mapping on the list to continue on the list. NCW: suggests the discussion be continued at least with SUIT and RATs and perhaps include TEEP NS: RATS and SUIT have respective drafts that should be aligned. The discussions should happen in both WGs simultaneously until alignment is achieved. TEEP can be informed of alignment status as needed. Calls for adoption may be premature until there is rough consensus on alignment between affected drafts. HB: believes there should be a merge where they end up is another further discussion Ned calls time and ends session