Internet Engineering Task Force 112, 12 Nov 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF112-RATS-20211112-1430

Description

RATS meeting session at IETF112
2021/11/12 1430

https://datatracker.ietf.org/meeting/112/proceedings/

A

Talk about jen, hufford.

A

Honest opinion.

B

I I just described um the deep meeting, my hand fell off.

A

Okay, how about gary mantium.

C

D

E

Assist me finish this yesterday for another session, while my son went wild on candy, so um there are ways we can manage. Can someone please volunteer.

A

Was that a yes or no gary.

C

But can I just take my notes on my own pad and and send them or do I need to use the tool I'm asking.

A

uh Put you click on the meat echo link in the meeting materials and it'll bring up a window or you can got it.

C

A

C

F

It all right: okay,.

A

Thanks gary appreciate it: okay, thanks to both our scribes, eric and gary, so just uh a reminder that this session is being recorded.

A

uh In terms of note well reminders for participation uh by participating in the iutv, you agree to follow the itf processes and policies.

A

uh If you're aware that any ietf contribution is covered by patents or patent applications that are owned or controlled by you or your sponsor, you must disclose that fact or not participate in the discussion as a participant or an attendee to any itf activity. You acknowledge that written audio, video and photographic records of meetings may be made public personal information that you provide to ietf will be handled in accordance with the ietf privacy statement. As a participant or attendee. You agree to work respectfully with other participants.

A

In terms of online meeting tips make sure your video is off unless you're cheering or presenting mute, your microphone unless you're speaking use a headset as strongly recommended bullet a session blue sheet is automatically generated based on ietf data. Tracker logins chat rooms in mideco are connected to the jabra chat rooms on ietf data tracker and there's more more information here. If you need it, just a reminder of the code of conduct, itf participants extend respect and courtesy to their colleagues.

A

At all times, participants have impersonal discussion participants, devise solutions for the global internet that meet the needs of diverse technical and operational environments. Participants are prepared to contribute to the ongoing work of the group, um there's some information for access to the various meeting materials. It's also available on the on the media, echo video stream, and then the agenda for today is as you see here.

A

So unless there are any uh comments or requests for his change, I think we're ready to to jump into the agenda.

A

So first up will be a uh a discussion regarding overlap between attestation results, uh e eat and attestation sets we've in the previous meeting. We have had uh presentations on on all of these uh drafts, so those who are attending the first session should be familiar with them, and this uh session is intended to have a conversation around what the overlap is, if any and uh if there's any uh work, that's that's uh potentially a blocker for any of these moving forward.

A

So sorry about that.

A

So let me switch.

A

To another window here.

G

It's the very first slide if you thought I'm thinking about.

A

Yeah, it's this one.

G

A

Okay, so uh this, I think that this uh eric slide, so maybe eric if you wanted to just talk to it to kind of get things started. That would be great.

G

Sure, over the last few weeks, the authors of the eat drafts draft more irt and draftweight have had a discussion in the background with the chairs trying to discuss overlaps between the documents.

G

For those of you who remember ietf 111, there were dis requests by both the attestation results draft and the draft moriarty at the station sets for working group adoption, but because there was the potential for overlaps in the scope of some of the documents, people wanted to do a review of what the actual overlaps were or were not.

G

So we came up with this cut of a slide that talked about what overlaps seemed to exist between the three drafts, and I do think that we came to a consensus, I'll look for lawrence and kathleen to go ahead and confirm in terms of draft the eat draft.

G

Basically, it is defining uh claims and, as you know, that has been reviewed many times and draft moriarty, which is a listing of what sets of evidence that might be sent from an attester to a verifier.

G

It seems like it would be good to reuse the definitions of claims from the each draft, and that seems to make sense- and it's possible that over time, draft moriarty would also define new claims because there'd be a need to understand other types of evidence in in ways that are not going to be vendor specific and that we'd want to go ahead and perhaps add new claims to eat over time, and it might not go into this version of the draft, but it might go into future drafts.

G

So it didn't seem like there was a lot of overlap in that direction. On the bottom side oops, I think we have dave in the queue. So any questions on that particular relationship. Dave.

H

My understanding from the eat, spec in section 1.3.2 of eat spec, explicitly says that it's not just for things coming from the tester. It's also for claims that appear in the attestation results. It's a generic format and the eat spec currently covers both as far as its scope. um I believe that's what the document says right now. Somebody can correct me if that's not the intent.

H

That is what the document says right now, I'm just commenting because right now you classified it as coming from a tester and it should say from a tester or a verifier.

E

This is kathleen just to provide a clarification.

E

um The main purpose is to be able to define what a set looks like right and that's absolutely not covered in the e draft, so just to make sure that that distinction is very clear. This is really to set up a registry so that people could define sets of local attestations that could be sent together as a single attestation remotely for scale.

E

That's the main part, and if we need to reword some things, that's fine, but that's not covered and should not be covered in a document like the the court eat spec, because it's a small piece that is an extension and can be handled.

G

Separately, all right so um looking at the definition of the uh or eat draft, as well as the attestation sets uh to answer dave's question. The text in the draft in the e-draft does say that it's uh mostly coming from a tester, then the later section says there are new attester claims that art might become from a verifier.

G

So I do think that that's captured in the top block that there's stuff coming from the attester, as well as from the verifier, and is there any pushback that there are the overlaps, as asserted in the blue bubbles between those two drafts.

G

All right on the bottom uh relationship um as kaplan just talked about at the station sets, is really defining types and sets of evidence uh in different.

G

Sets and then that doesn't seem to have an overlap with what the generated attestation results would be from the verifier.

G

So it looks like there's not an overlap between attestation sets, which is what's being attested and the attestation results in terms of the trustworthiness claims that are coming about the overall posture of an attester as evaluated by a verifier.

G

So the assertion on the bottom angle here the bottom two without talking any relationship with eat, is that there's no obvious overlap in those two giraffes, and I see lawrence and q largely have any comments on the bottom angle or the angle that we talked about before between eat and attestation sets.

I

Yes, um uh just quickly um the the avoid attestation results, discusses identity, claims like hardware, identity,.

I

It doesn't call them claims um it it just. It just discusses that there's something that that would be a part of attestation results and it does define claims for those things.

G

Okay, we're not yet talking about that angle, yet between the top and the one on the left we'll get to that one! Next! Okay! Sorry! If I'm off there any comments on attestation results to the uh the attestation results. Voip draft in the morality draft. Is there any uh disagreement that there's no overlap there.

G

All right, so the last discussion is the one that uh that lawrence just pointed out is that there is a draft and claims in the eat. Draft on identity and the draft void attestation results has types of identity.

G

That's a part of the discussion that is needed for the use of the attestation results in secure information interaction model, so there are definitely claims of identity in the eat and there's categories of identity, types that are non-normative claims in draft voip.

G

So in the left draft void relationship to draft rats eat, there are new claims that could be taken into eat on the attestation results and there are identity types in eat that could be used in embodiments of the draft attestation results that would be used for secure information, interaction models and that's why, on the very left hand, side, there's a something that says subsequent draft embodiments could use eating coding for things like specific identity. Claims of the types that are identified in active station results.

G

J

G

G

Thank you can't hear you.

J

Oh yeah, sorry, no, when I change the audio, sometimes it skips here on my side, sorry uh yeah! This is saying um I yeah, I I think it's a little bit like like with the um attestation sets. So uh yes, I think that uh when we arrive at a maturity level that we can assess that, actually we can use uh identity claims from each if they're applicable and that's, I think, the the reason why each is there.

J

So we can reuse generic claims that are relatively universal and if we have to create additional claims, these can be in addition to each later so to speak. They don't have to be in the each core document. I think uh if we arrive at the conclusion that there's something that is definitely this disjoint uh and still about identity, I think uh it's a no-brainer to to add a either in this document or a separate document uh next to the information model that we actually do here.

J

uh Some claim definitions so they're not very far apart, and I think that is not. It will be complementary and not conflicting. We just have to make sure that we reuse everything in each that can be reused in order not to do redundant things. That would be bad.

G

All right, so I think that's a good point. There's lots of documents and lots of identities out there. Certainly, there are other giraffes like draft chen rats, te identification which also uses identities. So there will be a lot of identities that can be tested and there are some in eat. There'll be some in many other drafts.

G

Not all identities are going to come from a single place. They'll come from many places.

G

All right, so, I think that's what was requested for the kickoff of the session is what the kinds of overlaps would be.

G

It doesn't look like, there's anything normative that I see, that would be a conflict in the existing drafts, I'll. Let the others jump in and assert uh their own thoughts on this anybody else who wants to jump in. I think the answer from the last itf, though, is no. It doesn't feel like there are major overlaps in normative claims between these drafts. At this point or the purposes of the drafts.

A

Thanks eric uh so.

A

If that's the, I guess, the question is to the to the group, uh you know that are are the various concerns that uh some have had about overlap addressed by this conversation is there? Are there other aspects that we need to discuss.

C

Yeah this is gary here. I I had a question directly to eric. uh uh I'm gonna take a break from my notes and then I'll transcribe. My question uh as in as a uh as a uh eat, co-editor there is a put. There is a pull request outstanding on on attestation results and lawrence is created.

C

I am taking your last statement to mean that there is no conflict between that pull request in your draft as written. Is that correct.

G

Currently that I would agree with that, there is what I've seen with the software result and the stuff that has gone into the draft. Recently we have existing claims uh where there is a conclusion about that claim made as part of software result and having supplementary verifier. Approval of information is a very different thing that what draft void is doing, which is evaluating the overall trustworthiness of a device itself. So it's it's very independent claims. Yes,.

C

Just as a follow-up, so you would have no objection to us. uh It has incorporating a pull request and uh and uh bringing that to bringing that particular claim in to eat.

G

I think that's an independent question. I don't know if I would want to see that I don't have any problem with it, uh the so the the software result, uh but I think it's an independent question on whether people want the details of the verifier results against each claim.

G

So, if you're saying that I I have no problem from a scope overlap, I have no real uh experience in my use of verifiers to want that level of detail in a relying party. Personally, I think relying parties should be simply relying on very high level conclusions from a verifier, so I wouldn't want to verify a reliant party that is really looking at a lot of detail from a from another device.

G

So I guess you're getting into a philosophical question and the philosophical question to me is: I want my relying parties to be very simple and dumb, but if eat finds a use for having a lot of details about individual claims and people want to use that, then you know sure go right ahead.

C

Okay, thank you. Okay,.

A

All right there, it goes.

D

um uh Eric can I ask you: do you think there's a place where the relationship between these documents should be permanently recorded so that the next person who says how do these pieces fit together has somewhere to go to look.

G

That's a good question.

G

I do think that what we don't have as a working group right now is a description of what the objects are and how they relate and- and I think the question really is, as we define objects, how do we understand the schema dependencies between different objects?

G

And that is an open question that I don't think we've addressed as a working group to say what are the? What are the uh the ways these particular claims interrelate and that's a very hard problem if we want to go ahead and try to pick that up. I do think that's a very large conversation to say how. How do we make sure that our that our information models have reasonable ties between them and that's how I've reframed that question.

A

Adam's on the queue and then I think we need to lock the queue.

K

I'll, just a tail off of guy's comment on a document to say how these pieces fit together, but also, possibly, I think, it's more of a support document of being justifications for why it ended up this way in a way, because I know some of it might be on the mailing list, but some of it was through discussion and learning over time yeah. This doesn't really make sense to put these two pieces together and why they're separated now so five years from now, when someone comes back, why didn't these two pieces go together?

K

We have a justification just.

A

Can't hear you lawrence if you're speaking, oh.

I

Yeah I had a slide. I sent you, I guess that's not in the deck for presentation.

A

A

On attestation.

I

Results that I wanted to present.

I

Okay, um I'm gonna, just say what was in the slide, then I think this is actually really important, so I don't see attestation results as um just one thing: there's not going to be one attestation results draft um there.

I

There are many forms of attestation results. Attestation results in, in my view, could be as simple as a boolean, yes or no or maybe a yes, no error code, very, very, very simple.

I

Annotation results could be like eric's draft the a particular conception of a vector of uh eight values. Attestation results could be a very large pile of claims that are input to a machine learning based risk. Engine. Anastasia results could include certification information about the device through a dloa ethnic attestation. Results could be in eat format, so eric's draft could be implemented in terms of eat or it could be implemented in terms of yang or something else. Attestation results could be sea war or json or snmp or xml, or all kinds of things like that.

I

So I basically see uh the relationship between eat and eric's. Draft is kind of uh I mean whether there's overlap or not, or competition or not, is really the wrong question. The the point is uh is like it's, a the the relationship is a little more subtle. You can um use eat as kind of a substrate or a you know basis for implementing eric's draft. It can be the basis for imp for attestation results in some other uh form. You know, maybe I don't know.

I

Geary defines an attestation results scheme um and eric's draft could be also done in snmp or yang, or uh something else right. So uh I think that I mean one of my one of my requests is, it would be if um eric's draft is adopted, that it not be called attestation results, as if it were the sole solution for attestation results.

A

Okay, uh in the interest of time, I think we need to move on. Thank you. Gary.

A

So next up is direct anonymous attestation.

A

J

Stepping up trying to yeah- and I am audible, I hope so. This is a relatively small presentation about again direct anonymous adaptation. Thank you for the time here. um I think. Next to dave, we are the only authors here in the room at the moment next time. Please.

J

So um I was a little bit confused on the list because I thought there was a working group adoption coil, but it was a call for comments on the adoption and then there was an actual adoption coil, but I think these might have been conflated on the list a little bit. So I'm not sure if there is an actual difference uh on participant's side here uh at this visible difference. So my first question would be: where are we right now.

L

I'm looking at the mail list right now, um hank and I'm trying to see if there were any comments to the and my apologies. If I didn't make that clear, um because I did put out a call for adoption earlier this month.

E

L

The adoption today um all I saw was a comment question from ned.

J

So so the most comments have been they're coming in when you are asking for comments and not for adoption, so so that that is why.

L

J

This in this picture, yeah.

L

Yeah, um so perhaps the question we should be asking right now: hank, you have addressed the comments that um came in earlier back in may july, right.

J

L

J

Actually, we all did so yeah.

L

Sorry all the authors, yes, um okay, so let's just ask the question now then um question is whether I need to put a poll um for adoption. So does this working group um believe this is important work and we should adopt it as a working group document.

L

Lawrence you're, in the queue.

I

I just forgot to get out of the queue.

L

A

So I'll jump into.

J

A

If there's no one there, but basically my feedback is that, given that there appears to there's still work, that appears to be needed to support sort of the broad class of daa algorithms, uh specifically the.

J

A

Epid, it seems that there's more work, that's needed.

J

Yeah- and I think we should do this in the working group as a working group item- I think that is not a single uh author team's job to address, because because this is basically external input- and I think that's the working good process right.

L

Yeah, so, uh okay, so I just started a poll so whether we need to work whether the draft needs work more work or not, it goes to the question of do we believe the working group needs to be addressed, addressing direct anonymous attestations and that being said, whether we can adopt this particular draft as the starting point.

L

So this goes to the point of. Does the working group believe we should be adopting this draft as a working group item, and then we can start posting issues against that. So um please respond to the poll.

L

We'll give it a few I'll give it.

C

Another minute or two sorry, I'm just not raising my hand, but if nobody's on the cube. Consider that uh right hand. Can I ask a question to hank on this.

L

Talk go for it gary.

C

Yeah, so how do we make sure that we're not in conflict with what the tcg is already defined by by bringing such a draft in into this working group?.

J

We are working with the initial creators of that work in tcg into collaboration. They are their co-authors and when we are aligning this, of course, with the tsg tcg at the station working group.

C

um Let me let me put it another way. What is the then? What is the purpose we already have that uh we already have specification being defined.

J

Yeah, but we do not map that to the reds architecture, so that introduces new terminology and we have no idea how to, for example, place the daa issuer. Is that its own role? Where do we do this? How does it work with subscription? How do the others models map that will be work? That is to be done in this document here, um it's very unclear uh how, because daa is is just this is basically tpm work and and and even even with the dice relationship it is.

J

It is not clear whether gets architecture how this should work, so we define roles and conceptual messages, and now we have to understand how would these roles uh and messages we have to modified or extended to support daa, and that is already covered to a significant extent in the document today, but as ned's comments show, uh there are still some parts of the solution that we do not cover yet, and uh so I think documenting that and highlighting how this works in relationship with the architecture is fundamental to how it is implemented, then, as a let's call, it itf interoperable solution.

L

Okay, I'm gonna.

J

L

Time since I'm hold on a sec, since I'm I'm running the poll, I can't lock the queue so um kathleen. You can help me lock the queue, because we've got roman and dave and we're running out of time, and there are two other things that we need to cover in the open mic.

L

L

So so, um if we can just move on roman you're in the queue.

M

uh Thanks nancy, just for the in the spirit of transparency, I want to double check that everyone appreciates how we're doing the consensus here. So we did a call for adoption on the mailing list. As far as I can tell only one non-author supported it and then what we're doing here now is confirming what we tried on the mailing list uh in the working group, and the poll is showing us that 13 or I'm sorry 15 folks do support adoption right.

H

L

Okay, dave you're in the queue.

H

Yeah, I just wanted to add to what hank was saying in response to the question: what's the purpose daa as a concept is not specific to tcg, although it needs to be aligned um there, we also want to specify it in the ietf such that, if you're using non-tcg, related use cases, you are still capable of doing daa or at least explains how you can do daa using eats and the rest of the riots architecture, so otherwise completely agree with hank's answer. But I think that this is important for the working group. Thank you.

L

Okay, thanks and lawrence just um put in the chat that the daa needs to cover more than just tcg, which we could do if we adopted this document. Okay, I'm going to get.

A

Absolutely yeah so we're uh you know seven minutes over so but.

L

We need we need to move towards the other one.

A

L

A

L

um Procedural question: the romans since I had put out the call and the call was supposed to end by the end of today um do I need to confirm this again, roman on the mail list, or can I.

M

L

M

uh No, that that's actually why I wanted to kind of speak up, because typically we do it the other way, which is we do it at the meeting, and then we try to confirm it on the mailing list and what we and then you sum the two of those and what we did. What we're doing here is the reverse, which is we started on the mailing list and we're summing it with what the meeting results are.

M

So to me you know it doesn't matter which one you start, it's a it's a question of how you do them together, so we don't need to confirm this again on mail list, because we've already tried that and the other kind of key thing we might want to ask, is uh we didn't hear any objections raised, but you know now might be a good time before we decide to adopt it. Are there any objections we want to raise here in the mic to talk about.

L

So ned, let's use three more minutes: um okay,.

J

L

For for those that um have objections, if you want to speak now, because there is consensus.

L

I'm not closing the poll yet.

L

I'm gonna count to five: oh guy, okay,.

D

L

D

Yeah nancy, this would be quite a bit of work. Wouldn't it you know, is it? Is it something that is viewed as important enough in uh to the larger community to actually put work into it?.

L

Well speaking as the chair, this is why we're posing the question to the working group.

L

So, given that there is consensus, uh I believe this indicates that the working group believes it is important.

L

If we're running low on time, so let's ask the question um that roman post on the chat, if you can post on the chat because we are running over, would you volunteer to work on it.

L

Let me give that a few seconds.

L

Crap, okay, I'm gonna! Do the pull since we're running our time.

L

Okay, so first poll, would you be wanting to work on the daa draft.

L

I'm going to give it 10 more seconds.

L

Thanks, thomas okay, so we do have a fair number of folks willing to work on the draft. So I'm going to end that and then roman can I just say, given that we have people there, should I do another poll for reviewers.

M

I I think this is good enough. I mean we're demonstrating that up one more to say so in the chat you know it's just we're gonna have to you know, I'm I'm sensitive, as mentioned in the working group, about having enough bandwidth to do all the work, all the documents. At the same time. Maybe the follow-on discussion is about kind of sequencing and we're this where we should push the energy in the working group.

L

Okay, so the question on the chat has been: I'm gonna end the the session. uh What does it mean to not raise hand? It means that you're voting no.

L

I, like dave's response. Okay in the interest of time um we we are adopting the daa draft, so hank and the authors, please convert it to an ietf draft and you have for those who raise their hand that are willing to work on it. Please work with the current authors of that draft to improve it all right. That said, let's move forward to the next agenda item.

L

Which was what oh, the open mic.

A

uh Concise reference integrity manifest that's what I have so we still have one more presentation. Oh.

L

We do okay, I I was looking at the agenda.

J

So I just think of I assume I will present on this because thomas is blocked and yogesh is.

J

Not joining and but way is here, okay, uh but uh you give away it's like super late. Okay,.

K

J

Me, let me go into this here, then um so hi. This is about um reference integrity benefits, of course. So we have uh a mission statement here. We have to inform and uh verify about how a tesla looks like the initial cut we have here included is uh the the og reference values.

J

I think the the software results in in the new claim in lawrence's um each id, for example, would cover that when kosovo will cover that we have, uh we have an inclusion of verification, key material, so to make sure that this evidence is, uh but I have endorsed values. So these are the things that the tester really can't talk about itself. I don't know you did a tester without the camera. Looking at itself can't tell you it's green yeah, so some things have to be uh endorsed from the outside. These are endorsed values.

J

Other things are, for example, fips compliance, some other. What's on the isolation, qualities of a t, these a tester- I can't really tell about itself because they are, for example, are the hard route of trust that kickstarts all of these trustworthiness claims, and so uh that that's of course in here there are future steps. But in the interest of time I might not go through all of this.

J

I think that's very important to highlight that uh extensibility is key here and we have a a vast uh um maybe doing that, but we have a lot of uh places where we can add ext code points uh like like new uh claims that will be defined uh uh when there's more each claims in the future and and some things that we need here uh um so next slide. Please, um there is already uh applicability to this, so in tcg this was taken up actually and uh they have uh adopted the information model over there.

J

That's interesting to the uh layered attestation, as these endorsements can tell you at which sequence which environment is supposed to create evidence about a target environment. This is called layered attestation here in rats and that there has to be some verifier guidance. How how that makes sense, and how is that?

J

What might not make sense so skipping, uh for example, the bootloader in in this chain would would probably be fatal, uh but but if the verifier doesn't know that, so that has to be informed about that, there's also a profile being created in parallel for coram. That is specific to the rnpsa solution. That sr psa token id in in here in this working group and and the psa endorsements is so to speak. The other side of the coin again as evidence endorsement.

J

So this uh this profiling of the columns back in parallel level uh and and the the use of it in tcg, is our our proof of concept and even running code, and then I can. I can't really tell a lot about this yet, but there is a tpm based evidence project in the enterprise space, but the uh uh reliable party is a responsible party. They did not agree in time that they can disclose anything about it, but stay tuned. That's not a secret.

J

I just couldn't uh refer with them, so so we I think we show uh or as always early on running codes. The reason of our site, of course, is a very prominent part. There, but also the applicability to other domains we can show with other documents. This document, actually, I think, is an embedded team for public review and will be out in I guess next week. Unfortunately, so we can't look at this today, so next slide, please um there is yeah, just basically I spoiled that already.

J

So this is not here yet, but if you want to have a look, uh there's of course not only the uh id we incubate most of the stuff in in github, and uh especially the cdda, is reused and on for different ids. Yet so the one the cddi is used in column and for the profiling of corem and the psa endorsement. So there is a synergy across multiple documents already and that is working out quite well, and the quality increased significantly due to that uh continuous testing next slide. Please.

J

So uh uh yeah these are all the pointers, so uh co-rim is is, is basically the bundle. I think I said that already commit is the heart, via hierarchy, equivalent to code smith. Co suite is a file system. Specific files hashtag results from from its claim here. uh These are typically in fire systems. It was hard to squeeze firmware in hardware components into the file system concept, so that made commit happen. It's a concise module identifier.

J

It's basically the complement here, so uh a firmware that is not located in the file system, but on hardware like the firmware. That's why it's called the bay uh is is, for example, referenced here, and we have of course, support for coastward, as I just highlighted, there's also a command-line tool. Thank you. I think thomas was had deleted on that that you can create uh columns comets and kosovo's respectively, on the user command line uh at home on your system.

J

When you have the right tool chain, uh I think that's really useful to get early hands on again. I'm rushing a little bit through this because we lost a little bit of time here. We want to have an open mic still in the end, so next slide. Please, um there is the uh question of. uh Does this work fit this working group, and um so we read the charter extensively.

J

We stared at it hard, and uh so um I'm not sure if I have to run through all the texts here, but the bolder text is our phrasings from the charter and so uh of course, describing an attester to a verifier is standardizing formats about assertions about the systems, components of a test. Styles, it's directly associated with evidence because you need it in corresponding to evidence.

J

It is, of course, as a requirement in the uh architectures, sorry in the reds uh uh charter, protected and and, uh as essence would be, the evidence and- um and it is intended to be consumed by verifiers, which is a role that is covered in the architecture uh which is and curiously is not covered in the uh charter. So that is uh something that I uh I kind of forgot. To be honest, I thought that the verifier was named explicitly in the charter.

J

It is not, but as we send as we focus on evidence at the center of the verifier, I think it's uh just appropriate to uh to do the compliment. Also, that is the endorsement and the reference values.

J

So so, basically, having said that, uh all the really important things here that is that this is feuding definitions into this work are the supply chain, stakeholders, so everybody who's, building, tes or components for trustworthiness or some some software components that are uh then in the end: a testing environment, for example, running in tes, again uh that these are authors on this this document and and to some extent uh again. I highlighted this.

J

We we have already uh agreement with tcg because they adopted the uh the terminology we introduced here, specifying identifying systems and the key material that we use for that. So uh so that's part of the goals of the chart. That seems seems to us- and this is just our office uh opinion here- to be in line with the charter. The next slide, please.

J

um There are also deliverables defined, and I think it's rather simple to say that we cover deliberate, two, three and four uh three might be arguable, because you would have to check the use cases. I just referenced them by by number here, but I think for all these use cases, you will require a certain supply chain, entity, information about the system, components and um yeah. So uh so maybe I for the interest of time I'm not restating what's in the charter here right now. This is just our let's call it analysis of of.

J

Does this work fit into the current charter's scope or would we have to recharge for this, and our assumption is well. This fits more than we even expected for it to fit, but but again, of course, this is not our decision. This is just our assessment, so that's where we are leaving life with is the next slide?

J

uh Can we do a? uh Can we do a working group called for adoption? Actually, um you can see the ongoing work uh on github how the issues are handled. Everything is very transparently and open there.

J

The document is in a fairly stable state between multiple vendors that uh have quite not always the same requirements. Let's call it that and- and we are they- they all seem to be happy with the current state right now, so that we are comfortable with a call for adoption.

J

There have been thrice weekly design meetings. We hope to dial that down a little bit when this becomes a working group item. But again we are used to this for like a year now, so uh so that is happening and uh yeah. So we are comfortable with doing that. The charter seems to allow for it, and so now I would place that question first to this, uh for the attendance in this session of the group here then maybe to the list, but but maybe some early feedback here would be nice.

L

So, admittedly I don't know uh I haven't been looking at this part of the github hank, um so my first question was to ask who's actually reviewed it, but I'm also looking at the open mic time um and to roman's point the prioritization and importance of this, given all of the other graphs that we need to progress right.

L

Okay, so we had oh, we had people on the queue and then they fell off the queue guy. I'm gonna let this go for two more minutes.

D

L

D

And if we were to.

L

Find I might put it on the list, go ahead. Guy.

D

Yes, thank you. um Hey. Could you help me understand the difference between co rim and post switch for doing software attestation.

D

I mean coast, weight is what we've been saying. Is the reference integrity format fork for rats.

J

That's not software and the korean is the bundle. Coram is the manifest. So it's a bundle of all the items that compose in a hierarchy or maybe even inverse things on your composite devices. They can be rather complex but iot devices. uh Luckily, so not um you need at least a commit that tells you. This is my device and its firmware as soon as you. If you or a file system kicks in, you need to go suit to understand if its layout is fine, and so I think that's the relationship.

J

The program is the umbrella, manifest uh where we are some uh uh it's it's, it's called actually the the the the crater it can be an oem. The oem, for example, could uh re-label other hardware.

J

So it's so opaque identifiers are important, as we already established, for example in and what was it in cheap just now, and so um so yeah, that's, that's the korean part and commit again is the hardware hierarchy, including its firmware and applicability of environment, identification and then in this environment there are very often file systems uh and these file systems are then covered by cosplay. Does that in a nutshell, answer your question.

J

D

Maybe not that's fine. Thank you.

L

Okay hank: I really need the 10 minutes so um yeah.

J

Yeah sure so we can do the call on the list.

L

Yeah all right, um okay, I realized we, we had open mech, but we had some items left um eric. Is it quick.

N

I was trying to get an open mic, so if we want to wait I'll wait for that, oh you're jumping the queue.

L

um So so um we have two open items that we started on whenever it was that we met on monday, um one was we're trying to assess readiness of the eat draft for working group. Last call there was discussion about including the claims needed to satisfy teep.

L

I can report, um but then dave I'd like you to also elaborate.

L

We, the team working group actually met this morning and we discussed the claims that teep needed to assess and I'll just put the broader one, whether they were unique to teep or not, and I believe that in one of the polls the answer was that it was not. But, however,.

L

Teep would like to see it done in the eat draft, but the e draft should consider for and now I can't remember having it be, a preventer extensibility. That's all. I remember dave help me out here.

H

Sure uh so I'd put this on the uh list, so you should have it all in your mailboxes, because I put it in the uh break because teeth met right before rats, and so I put the conclusions and thank you to all of the rats people who are actually there in the teat meeting, but not all of you were, and in particular gary and lawrence were not, and so I tried to represent the views that you play from the list in that meeting, and so the takeaway from uh teep is that uh t uh believes that the concept of a class identifier is not type specific, and the recommendation is specifically that the eat spec would would define a claim but leave the definition of the values of the claim to profiles and to vendors.

H

In other words, the t profile would be responsible for specifying a specific values of that claim. That would be useful for keep and what the meanings of those values are, and also to uh that. The e would be able to specify how a vendor gets a value, in other words, there's a way for profiles to get values and a way for vendors to get values, and so that is the outcome density did polls.

H

There was pretty strong consensus on that, and the only other requirement that was in a separate poll was odd: the values, opaque or structured- and I would say there was a fairly strong consensus across all of the community. All of the rat suit and team members were present.

H

There were zero against of saying that it should be opaque, in other words, that there is no structure, and so there were some that had argued that it would be nice if the format was something like auit just because that helps to ensure opaqueness, but that was a decision left up to rat so again opaque.

H

Please and the request to define a claim but leave the definition of the values and the semantics of the values to uh uh profiles, and it would be fine if rat, says well: okay, here's a claim and the profile in order to have values. Here's the requirements for that profile to define a value and what you have to do for it, um and so that's kind of my summary of what I heard as the outcome of the polls. So thanks.

L

Thanks dave uh lawrence you're in the queue.

O

Yeah, so I there there were comments.

I

On uh github from thomas and jeremy about this that I don't think uh line up with uh other discussion here, so I don't think there is consensus on this particular claim. um So I think- and but that said um in terms of uh working group last call- this is a relatively minor issue.

I

um I mean, I think the bigger issues in terms of working working group last call is uh things we were that we discussed, uh you know uh were about the cddl for uh gwt and cwt, and whether we're really gonna do uh both json and seabor.

I

J

This particular.

I

Issue, I'd like to take the I'd like the design discussion for class, to go to the mailing list and maybe be separate from working group. Last call.

L

Okay, okay, well said lauren, so that said, I'm starting a poll um to see if the group believes the eat draft is ready for working group last call and I believe lawrence you did update the draft. So I'm speaking to the latest.

I

uh We haven't pushed out a dash 12 yet, but we're ready to.

H

Okay, so nancy, your question is on is draft 11 ready for last call correct, that's the correct meaning of the question, so everybody's answering the same question.

L

Yeah, I guess we should put it on draft 11, given that draft 12 isn't out yet.

B

But then but then the answer is clearly no, because uh the draft 12 is already in the pipeline.

C

Draft draft 12 is uh draft 12 on things such as the class claim is awaiting consensus. We're not ready to push that out. We will push out of draft 12 with last call comment resolution as well. We don't need to. We don't need to push it out right now.

C

L

Remember we can always pull a second working group last call right, so we know that we need to yes, yeah.

J

L

It's a pre-last call, but we need to make sure that the other things that we've been discussing in the past are maturing enough, and I know that we well. The group should take note that we need to solidify the claims.

L

So that said, I'm going to give it a few more seconds.

L

I'm gonna count to five one.

L

Okay, so it looks like we have consensus for the minute takers. Please note, since I my laptop's still not well um as an action item, the chairs will do a first working group last call.

L

All right, so one down the second one, roman I'll I'll, need your help here. Since I keep not clarifying my notes too well, um the second one was there's been questions about the status of the architecture draft we went through a working group. Last call I want to say we started that last year we had a whole round of comments they were addressed.

L

um I guess we had a pre and then we had another sort of more official last call earlier this year um in which most of the issues were addressed.

L

We had um the process of going through the shepherding as part of the shepherding.

L

There was some ipr issues that came up, and so I tried to put the the discussion of just the ipr on the mail list to ensure that there was consensus that we could move forward, um given that there were two ipr claims um put out. So as far as I believe, if I can speak on behalf of the chairs um kathleen, you can speak up as well and roman. You can help me here too.

L

um We should be ready to put this out to iesg for publication um if we can get the consensus from the working group that we're fine with the current iprs um that have been posted, that you're fine moving.

E

The drafts or to publication yes, so I agree and I think just making sure we have a time on providing feedback on the ipr statement was all that was needed, and so typically we do two weeks for that type of of call right so um or for any type of call on a list.

E

So if we could just mark it as two weeks from there and then a shepherd, I will work with nancy, because you know ipr is a little more complex, but um so I won't work as shepard in a box on that part and we'll come to agreement on the feelings of the working group and then we'll progress it to um the next step, which is pushing it to the iesg and then for working group last call and then the area reviews can kick off at that point.

E

But they'll want to know what the working group thinks on ipr. So we really can't jump the gun on that. Thank you. Nancy.

L

Yep, so I just wanted to make sure that was clear. Roman, I don't know if you have anything else to add.

M

uh I mean you and you and uh you and kathleen, laid it out exactly right. I mean I would just reiterate to the working group we're through the the technical reviews uh inside the working group. We just tripped over this ipr issue, and so now is the time that the working group should raise objection or provide concurrence that, despite this new information related to the ipr, you are still interested in the document proceeding forward or wait.

M

This is completely new information and this changes your perspective on whether we should be proceeding and depending on how much you know how much harmony there is on that kind of decision, that's perhaps as simple as documenting it and putting in the shepherd right up as kathleen kind of indicated or if we have less less kind of convergence on the way ahead.

M

It's going to be a longer conversation, so this could be as short as advancing the document to me by you know, early early december late november, or you know it could be a longer conversation. uh Let's just sort this out in the next kind of week and I believe with the two week, call we're going to close it next next, at the end of next week, that's correct.

L

Perfect thanks great okay with that said, I'm I'm good at running us over for a minute. So I'm just going to close by saying we did run out of time.

L

We can put on the main list the call for adoption for the the other attestation results and at the station set, so that one we can put on the mail list, um and I think with that we can close the meeting. Thank you everyone and for anything else that you want to take up. Let's continue that on the main list as well.

E

Thank you. Everyone, a big thanks to you, nancy uh handling, most of this because of the other chairs having conflicts. So thank.

A

L

L

Okay, I think we're done happy friday.

L

L

L

Oh yes, go ahead and stop the session. I was just trying to capture all the notes.

L

L