Internet Engineering Task Force Interim Meetings, 6 Apr 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: TEEP WG Interim Meeting, 2020-04-06

Description

TEEP WG Interim Meeting, 2020-04-06

A

All right so good morning, good evening and good afternoon, everyone this is the T or trusted execution and environment provisioning working group. So if you were not expecting to and the teeth call you can drop, I've got my cooked chair Thiru on with me started. This is a virtual intermedia. The note well applies with respect to the policies and procedures list. Everyone on the call has been in t p-- sessions before so I will just leave it here and move forward. So for the agenda.

A

Bashing has helped me get started with the ether pad which I've noted here, but I can really use another note taker and I have a volunteer. Please.

A

B

A

So with that, we needed to bash the agenda here. I didn't have anybody anybody, meaning the authors of the team protocol volunteer to provide an update on that I sent.

B

You an email that I would like to discuss the issues and the beyond.

A

B

Today, Oh yesterday, okay.

A

I, probably I.

B

Added it to the ether pad the link Horsa to the PRS.

A

Good, so I'm using the Acrobat I will update it later, but Hannes. Thank you and we'll use whatever time we have left. So if you're, okay, since I didn't have this at the time that I was posting this, so you must have sent it after 3:00 or 4:00 in the afternoon my time but anyway so from the agenda, I moved it since I didn't know that you would be presenting I moved. You last is that okay or do you want me to move it back up and have the hackathon.

C

A

B

Think we will manage to go through all these items. I think we have enough time. Okay, well,.

A

I left it last just in case anyway, and so you can have the rest of the time.

A

The last presenter.

A

So anything else with respect to the agenda. If not, we can go ahead and get started and you go first with the architecture.

D

You want me to projector, do you have slides I have.

A

Them already go.

D

Into a full-screen I can't.

A

Have a have Acrobat go fullscreen.

D

Okay, that's fine, let's go and get started! Then I'm talking about draft Oh H next slide. You guys can hear me: okay, audios, good, fine, okay, great all right! So our timeline. We had a interim meeting if you remember about two months ago, right before that draft.

D

Oh six was posted and February and the interim meeting we had a number of discussions and a little bit of follow-up on the list that which was about how do we resolve the working group last call comments, and so we resolved the meaning one remaining ones and draft oh seven and Mars, taking into account the feedback from the virtual interim meeting and since then Ben no list discussion, but there have been two new issues filed since draft. Oh seven, so now, okay, previously.

D

The interim meeting this was our proposed timeline. This is the same slide as from February intra meeting. This is not the current next steps right. We, the plant, was that post, oh seven before March 9th, which we did and then the point is we agreed to do. A second working group last call to be discussed at IETF 107, which of course didn't happen, and so work doc and approximately at that point in this timeline. Okay, so remember, our original goal was to progress.

D

The architecture documented iesg for publication by the end of April and, depending on how this goes, we may still be on track because it could have a second group working group last call after this call, so ahead. All.

D

Right so I'm going to walk through the issues that been filed since oh seven, the first one was feedback that came in from a confidential computing consortium. If you remember at last, face-to-face I ATF I gave a short slide deck. The introduction of the confidential computing consortium, which is a body that hosts open source projects that are relevant to UT E's, and there was a piece of feedback that keep me from them and by the way full disclosure I am the chair of the Technical Advisory Council and the confidential competing consortium.

D

So part of my role is to provide feedback for the confidential computing consortium to other technical bodies, like you guys. So this was me as the messenger providing the feedback from that other body, and so this had to do with the definition of a tes. You can see in draft o-72 draft o8.

D

There was a change made in two places in the document, the abstract in the introduction and which had the same text about what the definition of a te was, and you can see this notion that only authorized code can execute within that environment was changed to you. Any code in that environment can be tampered with, and the main point was the draft delete it's really about code integrity rather than allowing her disallowing code.

D

If you think about how something like SGX works right, you can run a bunch of different things, but they're isolated from each other and they're, not tamper herbal, but whether you prevent execution or not, is not really core to the point of there being a te. The point is that you can't tamper with a code, and so we made that change to align it with their recommendations, because the editors also create itself.

D

Unless there's any comment, so we go on to the next slide, just explaining what the change was and why so, next one and the other one. So this is one of our a ist colleagues go off to Bates and you know a sh t. Folks participate and Hackett and our hackathons and so on and ask you know why does the tea protocol need to support devices with no REE?

D

Now you may remember: issue number 139 lumina. You may remember that we discussed the similar thing recently in teak sometime around the time of the last face-to-face at 106 and there and it was I. Then it was 139, which was this contradiction about whether the device has to have a REE to use teat or not different places. In the document that said, one versus the other, there was a contradict the February interim meeting.

D

We then resolved that with an agreed resolution that it should be supported, but the canoe Yasu had asked so I can't figure it out. When would that actually happen? And so the resolution was to add an example, and so that's the text in bold that appeared in draft. Oh seven right example is a microcontroller blah blah blah.

D

This is any comments we can go on to the next slide. It's.

B

D

Go ahead, uh I.

B

Think that maybe maybe the the boarding isn't I but I think the issue. The case is like. While we have sort of focused on the case where we have to broker and it resides like, we have to speak between a broker and a re and and a client side in a tea.

B

But of course it you could not have the broken. It basically resides inside the trusted execution environment as well. I think that would be another possibility, but I think I think the next is is good. Thank you. Any.

D

Other comments and next slide.

D

Okay, so this is another issue that was filed recently, and so this was who I pointed out on a mission that we had added a bunch of text about the security model and the trust model and the privacy issues and so on, and it covered DOS in some cases, but it did not mention that the broker or the rich execution environment or you know whatever could do das by dropping messages in between the T pagent in the town, okay, and so that was just that was never mentioned.

D

It covered lots of other cases, but this case was not actually mentioned, so the text and bulls was added into two sections to do that, so in 9.1, which is the overall broker trust model where it talks about what the broker can and can't do and what its what it still can do, because it's not trusted right. That's the whole point of re e. The key can still conduct off the tax is discussed in nine point three right.

D

Nine point three is the one that covered different types of attacks forward reference there and then in nine point three you can see in the middle there of the compromised re may terminate the chief broker. So after the transaction, it's not greasy te or it might drop or delay messages between at a manatee pages. Okay. So that was the knob that says: yep, that's another one in the list and then the discussion after that is the same across the set of das attacks.

D

Okay, so that was in draft, oh eight, so before the ones were in draft. Oh seven now are the ones that were addressed in draft. Oh eight, so keep going unless there's.

E

D

D

That came up with well roughly for the first time at the February interim meeting was often the TAM or the attestation service should be checked right. So what's the frequency, how long our results valid and so on. So we had this long discussion which you can find in the minutes, and the you know can find notes about in the February intermediate minutes, and so the bottom two lines here are on the slide of the snippet from those actual minutes.

D

Neither pad right, which was the outcome of that discussion, was that we should file an issue in the rats architecture document about how long an attestation results would be used and Hank had pointed out during the interim here that we should you know talk about. There was always be some delay and the evidence may have changed during the evaluation right.

D

There's no way around that, but we should point that out, but it's a dual issue between the tea parka texture and the rats architecture document, and so we need to coordinate between those two and so continue on, because this is slide one of three in this topic.

D

So, by the way, Ming took the actual item, Thank You Ming of actually filing the issue as a result of the inter meeting, so the issue 148 is it was a Ming posting at active meeting that the discussion all right, so the facto seven partly addressed this I mean they had the first time you stuff, the first half of stuff is the part that coordinated with the rats architecture. So the section in question here talks about malicious TAS right, because the whole topic was what happens when you're. You know out of compliance.

D

Something is bad, whether it's malicious or policy has changed or whatever, and so for the malicious case. You want to minimize how long you can be malicious for, and so the text in bold was added there, which talked about some. This is summarizing the point that Hank and others had made in the intermedia right. There is a. There is, however, a time window during which a malicious ta might be able to operate successfully, which is the validity time of the previous attestation result.

D

For example, if the verifier in figure 5 is updated to treat a previously valid, ta ting as no longer trustworthy, any stationers old that previously generated saying that the te is valid will continue to be used until the attestation result expires. Such the Tam's verifier should take into account the acceptable time window when generating attestation results. The rats architecture preferred the discussion. So the point is the generic discussion should be in the rats architecture document and the text here in bold is that keeps listen.

D

You know how it applies to tea right, what the what the mapping is between you know, tas and Tam's, and so on, and the generic discussion the rats architecture. This is the first half, because this only talked about how the how long the validity was and how how long the window lasted of vulnerability. Okay, and so you can see a pointer to the rats architecture document issue that tracks the same issue on the rat side next slide. So that was draft, oh seven, which solved half of the issue.

D

We think the other half was in draft. Oh eight, so Meghan pointed out the question wasn't about how long an excitation Zoli data, the original question was how often some entity reaches out to retest so draft o age and is the one that talked about appended to the same one that is to recover. The chief agent must be able to reach out to the TAM, for example, went over the request policy check API, which is already in section 61, is invoked by a timer or other event.

D

The point here is to say, the time window is actually bound. You know the time window from the security purpose is bound by the duration of the attestation results. Okay, after that, you just can't do the authorized operations, because your time window has expired for say so. Haughton you reach out depends on how how fast you want to recover right. You want to recover as soon as it expires. You want to recover more or less frequency.

D

The point is the request policy check, API and 61 already talks about having a timer associated with it, and so this just says by reference is probably that timer, but you could do something different. That's the euler event. You can see the the quote from was in 6.0.1.

D

There already said the eg, based on a time where my belief as editor as the the two things together and bold, do incorporate the discussion we had at the February meeting the extent that it needs to be covered in the t, p-- document, as opposed to the rats architecture document, I'd love to hear anybody else's comments on how well you think we did here and if there's other things, we should keep into a keep in mind in the rats architecture or in the tea party. Texture on this I.

D

Don't hear anything then we can go and I will assume silences consent.

D

We can go back for Nietzsche.

D

Okay, I think Hannes didn't couldn't make the February interim meeting, and so I carried this slide over from February to make sure that we have consensus, although we did make a change interactive eight.

D

This little question was about whether personalization data requires confidentiality or whether there is anything that only needs integrity but might be device specific by using specific meaning. You have two different devices with tes and the information you send to one is different from the information sent to the other right: that's sort of the definition of personalization data personalized to a particular device.

D

Originally before the February interim meeting, the text said: personalization data must be encrypted, that there's no limitations and so Honus fall. This TPR about will make there's things. They only need integrity, so maybe masha me may need to you right. So that was what the issue was filed, the slide other than the one over three in the title. It was the slide from the february meeting, which we discussed but honest. Wasn't there so continue on and we'll talk about what we did next slide two or three okay.

D

This was some of the comments that went up to the discussion about, and we talked about this one a little bit in the february meeting as well, which was encryption, support is needed and that may be encrypted doesn't enforce the recommendation to implement encryption right. As you can see as a requirement, the protocol must be able to support personalization data encryption. We then discussed that at the February inch room and you see comments in the ether pad from the February amendment minutes like this one Russ had said.

D

Implementations must support encryption to allow for loading a sensitive, personalization data right. So the consensus in the February interim meeting was that the important point was to say that encryption support is mandatory to implement write. Encryption implementations must support encryption. Then the rest can be left up to the T protocol document to say whether any particular message is actually encrypted or not. That doesn't have to be in the architecture per se that could be in the T protocol.

D

So taking Russell's point their language here about implementations must support encryption and ming's just above that leads us to the last slide here. Next, one on this topic is what we didn't know. It used to say: the personalization must be encrypted, and it now says roughly based on Russia's language. Implementations must support encryption of personalization data at to blahblah. Now the must be encrypted is replaced with must support encryption and again much.

B

D

Me I think if they were to move the rest of the discussion to the T protocol document and just call up the security impact here and.

B

I think that's them something still for us to think about like when we we. We talked about the personalization data in the past and what we didn't said. What we would do is we put it at the same. It's sort of data that also comes along with the manifest and that's great. The confidentiality protection is supported here, so so the new language fits India.

B

However, I still think that there is something for us to think about in on the architecture side, not necessarily in the architecture document, but for the implementation of this in the protocol, because imagine if you, if the protocol runs an implementation in in that's an ordinary trusted application that may be where the endpoint is inside the TE and.

B

This is different from the actual application that we then use that data. So like it, the notion of end-to-end security, and specifically, if you worry about who gets access to personal days, personalization data I think makes me believe that in some cases it may be more inside desirable to actually have the trusted application then do whatever it needs to do to date or do something about it without involving the implementation of the of the implicit endpoint. Does that make sense or do I need to sort of post, drawing or.

D

So sounds like you have thoughts on what might go into the chief protocol document, but what I I also thought I heard from you that you were fine, was in the architecture document and then continued discussion. The chief protocol document, which was the intent of this issue.

B

Yeah sounds good, so.

D

Since you have time for the tea protocol document feel free to come up with something by the time you you're up later.

E

Comment that this is like a implementation notation in time side and eighty per agent side active agent side support different Cartier's. Some tears may not need personal data, some met, and so then, as a a provided, TV agent, a happens capability.

E

B

Would like to point out in and and clearly this is a discussion for later is like: where are the endpoints for that encryption? This is.

F

B

In the de is not like the DS, a multiple different places where things can be encrypted.

D

For the cheap architecture, at the assumption would be the t, p-- agents and that's let be the end points. The encryption yeah we've previously talked about cases where you might also have something with a payload itself was encrypted and secret from the Tam, and that's not what this is talking about. But that is also actually no I think we did add something somewhere else about that.

D

Maybe in the same section here, because the we had this point about how you can have two different tabs, one for personalization data and one for say the regular ta binary, for example. So I thought we added some text in a different issue somewhere, but.

B

For example, daivam in your implementation, you rerun the code as a regular ta, not a TA above special special privileges that implement the deep agent under on the te side in there.

B

If, for example, if you do is an update of another trusted application, then that update will be verified by code, that is by keys that is elsewhere in in the te typically coat. That resides, runs at a much higher privileges in the TE so and so I think even they are believe. There's a security, qualitative difference. I think that also carries over to the personalization data.

G

B

D

If followed that, but if you're talking about.

H

D

Create a draw, a picture, but.

D

Sounds like everybody that's spoken up so far, is it's really? The question is: can we consider 132? As being you know, issue and the architecture document is being done and move the discussion to the T protocols so far it would have spoken up has been in favor of that, even though there's more to scottish on the critical document is that's really.

D

The question I've asked is is: is the changes that are made here sufficient that we've now addressed all the issues right, that's what I'm trying to do and that the goal this slide deck is to verify whether draft '08 solves all the issues close enough to be done with it and move the other discussions, the other documents or other changes that we still want in addition to what's in direct OAH right, that's the that's the main goal of this particular presentation. So please speak up.

D

If you think that you want more Changez than what we've done in the architecture document itself,.

D

Alright, so I think this discussion will continue and we have time to talk about protocol stuff, whether it's in this call or after this call so next slide Nancy. Unless anybody else wants to speak up okay, so, as you recall, the next steps after the interim meeting was to address those comments and then do a second second working group last call so based on the feedback that I've heard in this call. So far.

D

My my personal conclusion as an editor is that we are ready for a second working group last call and so I'll hand that back to the chairs to decide whether they want to do that.

A

Yeah I think we we are I mean I, haven't heard a lot of discussions. I also wanted to take a pause, because that's the any note of the discussion that just ensued in the ether pad.

A

G

Writing in a notepad yeah.

A

Okay, yeah I was expecting to see things going on the ether pad.

A

That said, I think what I'd like to do is solicit volunteers to actually review the architecture document, because if I recall, we only had Nikolai and Dena provides feedback, so can I get at least another volunteer, hopefully to to help review this and ensure that we we have more comments coming in the second last call. Oh.

A

A

A

Daniel mr. McCaul.

A

Okay, well, do that.

A

Will issue a working group last call for that as well.

A

Move on to the next one, so Dave, that's you! On the transport side, that's.

D

The transport document- okay, great, so now we're on the heap over HTTP document. The file name still has OTR P in it, but that's because we did not want to change the file name at this point because that'll go away once we eventually have an RFC's.

D

This is tip over HTTP, okay, so the timeline on this one was we needed working group last cause oh yeah, IETF 106 was to do the changes talked about an IETF 106 then started working with less call. That was then dawn in February, which the working group last call ended on February 26th, and we got two reviews. Thank you to Russ and thiru in particular for those two reviews. Those were great so in April, mark Nottingham did a recheck for conformance with the BCP 56 bist. That's how to do protocols over HTTP document.

D

He had done a review early on and he did a review in April. So technically, we've had three reviews since working released call started. So that's fine.

D

Okay, so the pop lists are things that were discussed: the IETF 106 right, so one two and four were things that were addressed then before then, and just verify that they could be closed. Five was one that we believed was done and and wanted to get settle. Actually, five was when we had questions to the workgroup as to what to do you at the outcome of that was to remove discussion that remove the t p-- over OTR key discussion from the document.

D

Okay, so that was the outcome of the IGF 106 discussion and then, since working group last call, history was for new issues that came in plus various pieces of editorial feedback for us interior. They didn't have that didn't get issues. Issues were following all the main technical points and if we miss some, the last slide. I'm here calls out a couple other questions about how they actually technical issues or things that you want to bring up so Russ into your.

D

Please keep in mind if there's something that I don't call out here, please feel free to bring it up after the call. After the the end of the other issues here, so we're gonna walk through the ones that are on here and then I got a slot, an editorial feedback so go ahead. Next slide. Okay,.

D

So number eight was filed where Acura sent this question, but then in the issue itself a cure and I have commented. We said that this should be noted, a tea protocol rather than the transports back and so I think both of us meaning the filer and the editor both agree that this one can be closed, but I didn't go ahead and close it. We probably can because there's now a tea protocol issues, so I, don't think, is anything discuss here.

D

Given that everybody agrees that this was found on our web document number eleven is the hall, but the cherries put out about you, know JSON verses, Sieber or support and t p-- and our understanding as the working room consensus was to use Seaborg and not based on, but all the examples in the product in the transport spec used, T, plus JSON and so number eleven was we updated the examples to use before now? The actual content doesn't actually appear of the examples. It's just.

D

The media type appears in the HTTP header, and so the HT header, that's the content type and accept header was changed from JSON to seaboard, to match that consensus and by the way the actual value of the media type is normative, and the T protocol document right. That's where the IANA considerations are, and it actually defines that the transport document just says, use the media type defined by your bot that you're using out of the out of the protocol document, and so it's just an informative here.

D

You don't have to do any ini considerations, changes just using examples because it points to the trip to the yeah protocol speculum that one was pretty easy. Next slide. Okay,.

D

So this one is a interesting discussion to see. Are we on the right track? Did I do the right thing or not?

D

Originally the questioned thiru and his review said what kind of guidance do you have and what are the privacy implications if you do say because it didn't say what version it to you less or what requirements are around? Which versions of TLS you support, or you don't support or whatever he said well, what about, if you're, using TLS 1.2? What are the issues because you know TLS left like 3 fixes saw and so do you need to call those out and so on.

D

So I asked mark nottingham what they did with pcp 56 bits right, which is in the document that says how to write protocol documents over that use. Http transport, and I noticed that that document also didn't have such guidance, and so I asked him so why is that? And he said in his email he said well, we in 56 bits avoided this issue, since it's not HTTP specific right, it was our job up on our layer to give that guidance either right, and so that didn't really answer my question.

D

So, however, what we found is that the security considerations, I think the types of things that you're is looking for, are actually covered and be CP 195 right where a PCP 195 is the RFC that gives their recommendations for what you should do around TLS and DTLS. But the question here is TLS right. So what are the recommendations? Parished he lists versions and and what you should and shouldn't do and all that stuff, and so it already does that in a way, that's not HP specific right.

D

The what I've done in the transport spec is to add the bolded text right, which is, after the point that it talks about TLS. For the first time right, the TLS certificates must be checked to see BCP 195 for additional TLS recommendations. Right to say all of that applies as a BCP rationale.

F

D

Why I thought this might give good resolution is that that document already has IETF consent, so we'd have to spend lots of time arguing about what it might say, but then you can still say well what about all the cheap specific stuff? Well, he was secured end-to-end inside of HTTP right. So in theory, there shouldn't be really anything significant, that's teep specific to say right, because it's any any cheap, specific security issue. It's the T protocols job to solve, not TLS jobs, protocol.

D

Only the TLS considerations shouldn't actually be T specific, at least that's the that's the claim, and so the belief is because t p-- a-- secured in to end. Then all that's necessary, in my opinion, is to reference, be CP 195 as the best current practice for what to do about us. So that's why I did that. So, if anybody disagrees are things we need to say more in a way, that's teep specific. Now is your time to speak up and give some recommendations.

B

There's this other RLC that talks about use of TLS for IOT devices, and maybe you could add reference to that to.

D

The TLS profile from Elliot.

G

Hey: hey Dave, a text you're referring to in RFC two eight one, eight I think it's pointing to an old mechanism for doing PKS validation. So I think you need to point to the right document for doing certificate, chicks.

D

This text is largely taken directly from BCP 56, and so, if you believe that that reference is not correct, you should also follow up with mark nodding hat, because when he did his recheck I asked him. Do you believe that this is still saying the right thing and he said yep still looks good to me or still looks okay, I think, which is that quote.

G

D

If that one changed as well I'm happy to make an equivalent change into here, but right now it says you know document should say the following and I'm saying the following, and so if I change it then I'm out of conformance of that, unless it changes also.

G

D

We can start a thread with at least the three of us, if not the list or whatever. They just gave him to confirm that. But since this is a change for the HB bist working group, they changed their recommendation as to what we should say and I would like him to buy off on that. I. Don't disagree with you I'm just saying. I want to keep in sync with other document, because.

G

Be case is discussed in six one to five, which is an latest update and I, don't see to it when it can is not referring to that. So.

D

If you like to propose a change either to here or 256 bits, because the language is almost the same as long as they should be this as long as the editor of 56 bits, which is mark as long as you incorporates it in a BCP 56 bits, then I'm happy to make exactly the same change here.

D

Okay, so you have an XM to follow up on and I will happily go along as soon as Mark at least acknowledges that he will put it into there if he pushes back in any reason, then I think we should hold off and figure it out. I, don't imagine the pushback, but we'll say.

A

That again, rush I think.

F

Both documents should be referenced here, 2880 and 6125. That.

D

Might be the simplest baked has just rush.

F

Your suggestions, ready to.

D

Say and RFC whatever I don't know, is that your suggestion.

B

And what we, what we could use, we could use reference to the 6125 I think that would be better replacing the reference to two eight one. Eight.

F

You want them both. That's.

B

Fine, for me, too,.

D

So I, if I remember, right HT, this working group owns the particular pcp 56 bits and they are not under the security area. So if we have a recommendation they're not on this career area, if we have a recommendation, they ought to go along with it. So like, if say, you know, Ross and tier. When all of us had this conversation, the interim meeting feel free to check our minutes here, but our recommendation is to change your six following then that would be a security working group recommendation, twin security working group.

D

Okay, well I didn't. Hopefully somebody can capture that the RFC number in the ether pad, because I've not forgotten what it was so I've.

G

Captured it okay.

D

Great. Thank you all right.

G

Abby one comment was that RFC 6 1 2 Phi just talks about PK X base certificate, validation, I, think the our teacher dropped draft talks about self-signed certificates and others. So do you want to refer to some of the specification for those TLS certificates to be valuation?

G

6 1 to 5 does not cover ourselves and certificates of private CA 2018.

D

G

Don't think so because HTTP does not typically discuss private CA.

B

Really matters right.

D

I, don't think what's typical is important, I think, since the 56 bits is talking about guidance for people using HTTPS of transport, it doesn't mean people, typically, they use HTTP as a transport in typical situations. I'm saying 56 bit should cover. You know the wide range of stuff, including you know, IOT, and so on.

D

Okay, so it sounds like Thiru. You currently have the action item on this. One and I will happily make a change as soon as we can get to it. So I just want to make sure we have agreement on who's got the next step here and I will wait for you, but if we get that done quickly, that would be awesome.

A

Technically you're out of time, but I'll give you a few minutes given that are.

D

We actually pressed for time on the call I thought. You told me that we were not as pressed for time but I'm happy to tell you well.

A

That's cuz, we didn't have the tea protocol, but I think we're gonna be fine. So.

G

I see so is the conditional use of HTTP I think even then had the same comment that I had posted in.

D

There so I'm gonna get to that so Nancy time check. My understanding is: we've gone for 45 minutes and I thought that the invitation was two hours. Is that not correct yeah.

A

Which is why I said I think we've got time so now we've got an hour and 15 minutes. Oh okay did not account for Honus, so yeah.

D

Okay, great so the next one was about ham certificate. Caching, the OTR piece: the history was the co-chair piece: Beck did have text in there that talks about caching, the TAM certificate, so the T agent could learn the TAM certificate a and so when it needed to reach out to the TAM, I could immediately encrypt with the town's public key without having to ask for a roundtrip to actually go and fetch it again right. That was the what the caching was for the teeps, but it's not yet have any discussion about.

D

Caching right does the cheap spec as much newer it rather than passing the certificate directly again. This is my understanding of how Oh CFP data work. Somebody will correct me if I have this right now the chief spec uses OCSP data. No CSP data contains certs. One of those certs would be the Thames at cert, but it doesn't mention, get caching yet right. That's issue, 17 that was filed on the T protocol. So here's the change that I made and hopefully I, didn't get this, but somebody I'm sure will correct me if I did so.

D

If it's already had a cashed ham data that it trusts based on a previous query, request: okay, so it basically without being able to reference a section, yet it references what the actual field is that would carry the stuff and what the message that would be, and that's the closest that I can do right now without having that discussion in the T protocol spectrum.

D

So again, the intent is that you should be able to cache the Tam's OCSP data so that you have its public key so that you can encrypt a message to the TAM by sending a query response without having received a query request for this is the very first query request career response exchange. You can skip the initial connect, get back. The same career request would send to everybody and just immediately send the query response that you would have sent had that happen.

D

There's no questions. I will assume I, got it right and go on.

D

The only change that I would make if there was a T protocol discussion is to add actually a reference to a section number in that T protocols back wish. We could do once we have a T protocol, but I don't think it's necessary. I think would be helpful all right. So here's the over.

D

That are not sort of open questions. These are the trivial editorial ones. I have one more slide after this one, so we added a note about user agent strings being implementation, specific that was in response, their process about the foo and bar and what the meaning of those are.

D

The second one was to add an informative reference for quick, because it's used in a diagram to illustrate where the broker boundary can be between the REE and the TE and T hrough pointed out about the notes in there about firewalls would also apply to Nats, and so he said and nasan. So those are all editorial I, don't think they need to be discussed and less rust or tear thing want to reopen them, because I think those are just editorial. So, let's go into the last slide.

D

I think I put them all this and hey here's the three possibly open questions. These are things that were asked that I gave an answer for, but I don't know whether we have consensus on there, and so the first one is about the use of the discussion around that using ACP as a post, HBS.

D

Okay- and so we had a bunch of description about this in the past, the main technical answer for allowing HDPE, not age without TLS is, if you have constrained devices that use tea since that's into insecure inside, by using cosy right and if they don't have the code space or whatever else to put in a TLS implementation, then they could still use tea right because it's already secured inside it introduced a couple of extra daus and so on issues, but is still the tea part itself is secondary.

D

Answer is for debugging and I heard a couple people been and who else has said? Well, you know. Maybe we should remove the discussion of debugging because it's in there in a sentence, and so what do you guys think on this? One.

G

Yeah I think if it's just for debugging I, think I, don't think it shouldn't. It should be discussed in the protocol specification. Debugging people can do whatever they want, but it does not make sense in the specification document. I.

E

Think, maybe we don't have to mention it so I think is good right. So you get to be soft. The final product I would agree. So Trust for security is not that mandatory, so I.

D

Understand the proposal from thiru and seconded by Ben is to just remove the phrase that talks about end for debugging, and only we mentioned the first case.

E

D

And unless there's any other counterproposals I'm going to assume that as direction to the editors, if you'd like to speak up to say you want some other direction, let me know, but otherwise I will take that as as the direction to the editor.

D

D

Question raised was I think this came out of a tea, were your review was? Should we actually specify what the HTTP error codes are right right now the Texas basically says use an appropriate HTTP error code. So you know you're 200 level for another level, whatever use an appropriate one and figure it out, and so I'd asked in mark Nottingham hey if you're 56 bit stuff. What do you think the protocol should do with respect to specifying HB error codes right and his response was well, as response was what you don't want.

D

Is you don't want the receiver to have like a switch statement, a particular code? You know to rely on there being yo, a 404 verses. You know 5 or whatever, so the receiver should only based behavior on whether it's 200 level, 400 level or 500 levels. You have to be careful to not over specify things in a way that would come as receivers most. The actual error codes themselves within the 200 for 5.0 level might vary greatly by implementation, okay and so marked comment list.

D

He thought that the text looked okay as it was, but I didn't put that as a result here, I want to ask that and get any discussion here is now that forwarded marks response to the list right. So, with his permission, the question is: is there anything more specific? We want to do here, or are we okay with it? With the current answer to the question, because it wasn't a request for change, it was a question. I hear Oh.

D

First, you heard this and seemed that mark said: do you believe we should do something, or was your question sufficiently answered? Yeah.

G

I, like the marks addition of returning the records from the server, but not specific, the client behavior. That seems like a good way of at least saying what the server should do. There's.

D

No specific things we can say use the specific error in response to this particular thing: right: the 200, a success and the 400 500 have specific meanings about internal server, error or temporary or whatever, but yeah I couldn't think of anything. We could say that implementations would need to do or anything that was taught.

B

D

B

Think one important aspect is that most of the error codes when they happen at the deep-level they actually don't populate down, so it may be. If you have an error deep level, it's still, it may still be a 200 okay, but then it's an error at the tip level. I think that's also what an important point the HTTP it's or the HTTP PCP document says that you are not supposed to dictate the error code that the application from the application down to the HTTP layer right.

D

B

D

Now my proposal is to do nothing here, other than maybe you know keep discussing it whatever, but I can't think of any change that actually makes sense that document. Yet somebody else I'd like to propose one feel free, but right now, I thought about this and after my discussion with mark and so on, I don't think there's any change that I could make. That would make sense so.

D

Well, people think about that one. The last question that I have on my slides here is and I don't remember who asked this and if it was a hero or fan or somebody. Why is 56 bits and informative reference and the short version is well: it's not used in a normative statement right. It's used in security considerations where it says for other security considerations, C 56 bits right.

D

The security considerations are extremely irrelevant, so I can only imagine three possibilities and right now my opinion is we're taking the right one, which is don't reference 56 bits at all: okay, where I think that would be a problem because we'd have to copy and all the security considerations that are in 56 bits.

D

There is do what we're doing now is informative reference and these make it be normative and then I'd have to have in the normative statement that references it and right now my opinion is we're doing the right thing of making it be informative. So that was a question and I'm hoping I didn't file an issue, because it was the question so- and this is my last slide so I think not on here- that you rustic-y brought up in your review that we have not talked about that. You want to talk about.

D

This is your last chance on the call here. Otherwise it would have been the list.

F

Okay, thank you. I.

G

Think this pretty much covers all my comments. Thanks great.

D

Then so next steps question on here was that slide: Nancy?

D

Okay, so the next steps I got direction on the debugging one and if here, who gets a change on the tos considerations, one that I can do that and so right now I'm expecting it right now that I would push another one, although if we can get a alignment 56-bit soon, then I'd like to get both of those changes in the same document and then I will leave it at the chairs as to whether we need another working group last call or not after that, given that we had what three reviews since working the class class target yeah.

A

I mean admittedly, I had not counted mark as an official review.

A

Ming on the spot, Ning would you mind reviewing it and.

B

And I submitted the BR for the TLS issue a few minutes ago.

A

You guys can do that and provide feedback, I guess if you can, because Dave you might need to do some of the smaller edit editorial notes too. For another read.

D

And I can do another rep as soon as we can close any other ones, whether it's you know this week or whatever. So it's it's.

A

Anyway, if we can get that done, then what I would want to do is just confirm that everybody's okay, with that latest version after Ming and Hannes, have also provided comments or reviewed, and then hopefully we can go to publication. Do.

D

You want Ming and Hannes to review the draft. Oh six, it's out right now or do you want to wait for some okay, just making sure you do that? Yes,.

D

A

Clear Megan Thomas just wait until I.

E

Wait: the FIR! Oh, you know Wade Davis a little update.

D

You wanted them to review. Oh six, it's out right now or an a future one that hasn't been posted yet, which was the one Raskin interview the.

A

Future one that had and then posted yet.

A

A

C

It's my mic working. Yes,.

C

The report about having a virtual hackathon and all the reason of it having a hackathon was makeup feedback, reflecting from the implementation to the draft.

C

And initially we were planning to just to have a go hackathon in Japan when the announcement was decided. The chancel I give $1 seven later.

C

Even in Japan meeting in face to face in the meeting room was started to be prohibited in many organizations, so we end up having a virtual hackathon in Japan timezone next page. Please.

C

Yeah, so we have a virtual hackathon in Japan time.

C

Pretty much that's what it is here.

C

Yes, next page, please I, don't think I could I'm going to spend 25 minutes.

C

C

Hackathon in Berlin is going to have only seaboard, represented format, query response and trust a trusted application store a trusted application to each sequence is the same. We wanted to have at least all three working, and we also want start see. Poor implementation, starting and and also my initial prototype was on our. He should have been working on risk five, but not much yet and was always wanted to work on this GX.

C

C

It's deep, deep Dreyfus is able to up the cobble if C X, so we just wanted to confirm its it's going to be fine or not next page. Please.

C

Yes, end up Tintin attendees even from day further from like worse, yes from.

C

Cielo yeah time zone, nobody was 11 o'clock midnight in his time.

C

Most of the other member is people have been attending to dip in the path or burden.

C

Thank you for over 10 people in this I. That was this was my first time to hosting hackathon and her first time to be coming as a virtual house. Also, yes, thank you and next page. Please.

C

Hackathon Thank You force to come to hosting video conference system. The cube is almost identical as a web WebEx and.

C

Also we ice robot provided a router, so I set up the l2tp IPSec, so ham, server and device will be able to connect inside that they bien and not to harm any public internet with the bugging me I guess and it work or work perfectly.

C

Finally have a disk disconnection on VPN button, yeah other than that it worked perfectly.

C

C

This is what happened at the hackathon, so we we never really finished, even the three sequences in Jason format, so we we've finished. It confirm it was working, but the so based on Stan surfer and my device and and now from the virtual hackathon. Until today, I was able to focus on Zeebo format. That was did help a lot and support format during the virtual hackathon didn't finish, implement making a message in support format. We started to prepare the library in the hips description of the binary decoding and binary presented station.

C

Code and touch the song was already working on the ABC suit library was really helpful from him. His expertise.

C

Teaching other people about the Seaboard message. Thank you next page, please.

C

And another team was much: people was able to build a time missing stamps of her by Dave's, so boy song was only the person who was able to build a time server in the device so and everybody else how to do the same.

C

And then we started to connecting times of and device inside a VPN.

C

They figure thing up: you're late for hosting your time, server.

C

Or representation or what he calls a DDL format in the draft?

C

Yes, we when we implementation, we we saw some places. We could use tickets or binary strings inside a message which is the size, because seaboard meant to be smaller, binary format, data, asn.1 or other formats, and that's what I've been what I've been working after virtual hackathon until today and and few on the mailing list today, and probably that's going to be the discussion on the next topic from honest and also yes, people in Japan was was calm down, yeah tip good work on the CX. Yes, that was that was I was personally yes,.

C

C

Yes, yeah also works on virtually yes and also it helps a lot I'm having a VIP video take his chat and he DPN and one thing I know this was face to face. Hackathon is directly talking each other, but a virtual one. We use a lot of texture. We use one one of the chapters we.

C

F

C

And it was studies also do technical discussion is able to read in copy and paste on your machine which which, which is good, which is nice. Yes,.

C

It's in next page, please.

C

Yeah, this is the summary, so thank you and yeah, and then we I have a after the virtual hackers of not pretty much have a clear idea how the Seaboard format in.

F

C

Binary file works, yes, I, going to start more pull requests on the github for the Seaboard message and also I have before making a simple motivic.

C

Discussion and maybe mix I was half doing converting.

C

Xml file to marked fr, but I didn't finish it so I might finish it sometime, not tomorrow, but maybe next week for yes sometime and for me editing, markdown files easier than XML file.

C

Okay, that's about it!.

H

Yeah, where they have room for doing the xml to mark down conversions, whether you can just send me the hexavalent I drew it for you.

C

Pretty much finished on only a few things remaining is the chart. It was written still written in Excel inside yes,.

A

Sounds pretty cool so um issues, lessons learned that came out from the hecka.

D

Thought that the survey VPN actually worked well, so that we can test things that might want to be able, that's and so on was really not a problem. So I thought the using VPN was great.

C

Will provide having all the time and devices for all the hackathon attendees machine in the same segment problem is the VPN is going, is Inc encrypted with IP six, so it's.

C

Conference packet through VPN is won't work well, so most of the people end up having to machine in one format, development, machine and one for posting video conferencing, yeah.

D

That's true I think that had to do with how the routing was set up so that when because all that would have been necessary minimally, if we're to do it again in the future, is if the VPN has no default route right, because because we were always using unlink addresses to talk to each other right, and so that meant that whenever we're trying to get to the internet, then the default route was going across. There. I think that was the real problem.

D

If I was doing this in the future, I would try to set up a VPN, a figure out a way to configure it. So there's no default route.

C

And also ip6 l2tp IPSec works well with all different machines, Windows Mac, look into Linux or fade or whatever.

C

My setup was using that to have everybody in the same segment and had to change one line in the resistor in Windows, so if Windows and in the future, if they, if it falls back to nap traversal mode, it will be nice for them.

A

So, do you have another hackathon planned akhira.

C

So, yes, we, we have a discussion having a hackathon locally physically in Japan right now, situation is getting more intense in Tokyo properly. It might have a lockdown in Tokyo and in this this or next week. But um after that, if things comes down yes,.

C

A

Cuz I think we.

B

um We had this plan for the IDF hackathon, which unfortunately was demolished by by Charles and so on, but because we spent some time setting that one up so I think it would be worthwhile to schedule another virtual hackathon, whether some people are grouped together locally, physically or not. The dam I think that should be refining, persuade.

A

Yeah I mean chance was willing to do the virtual by the way it was just I'm.

B

Not blaming him, but it was just unfortunate because.

C

Her to her cousin, orchid and support for my great achievement was I was able to use my old expertise when I was junior high school high school reading, the documentation of the and writing down how the binary should work by reading and then changing the battle for the converting city. Their format took me all week, class.

A

A

Well, let me know if you guys want to host another virtual hackathon. You can see, we could do all right, Thank, You, Akira, okay. So with that, let's see we have I think 48 minutes. If my math is right, I might be 10 minutes off Hannes.

A

B

Could you that you open the pull requests and share.

A

B

B

D

Posted the link in the WebEx chat in case anybody wants to open it themselves.

A

Okay, which one did you want me to oh, it helps if I share.

A

Okay, can you see my browser sharing the networks, issues toggle back and forth between the issues and the pull requests? I see through all requests? Yeah start.

B

With the boy because I think that's easier, then we jump over to the issues so I the first one number 14, which was actually came out. We have a discussion, maybe on the list, when we had that one on the on the list, the intention for the token and there the issue was initially that there was this.

B

This question about the nuns which we used in context of their work, turning rats with the entity attestation token, which allows the dam to as a demonstration of lightness been announced over to the UM to the device in his device returns the dope compacted the e token, which includes then the nuns. So we clarified that on the list that this nuns needs to be relatively long. So there's some indications on how long that's supposed to be in there each specification and if we just use the same lens, then we won't have any issues.

B

But then the topic of like what about the dope and the token is used and that's a different element in protocol is used to match the reek against the response response. And so that's that's an think. It was previously a pied string.

B

The suggestion was to make it an integer. I was actually wondering what why an integer we could actually make in an unsigned integer, but in general, like an integer, is the right thing to do, and I was a stumbled about it. When, when I converted, my JSON based implementation to see what I think.

D

Nancy, can you increase the? Can you zoom it all in your browser window cuz, the font is a little small.

D

Honus, can you refresh our memories? What's the difference between the use of the token versus the non Center words, given that you have announced, what is it, what does the book used for the denounced doesn't really provide if you can refresh our memory.

B

The nonce is purely for the attestation. Information goes into the attestation, then, and if you don't request at the station, which is actually an option as well, then you wouldn't send the nonce. The dokkan is used to house generated by the Tam.

B

Yes, so the dam creates the token as well as the non suppose cases, and but in case of the token, it sends the token and puts a number in there and the nonce.

D

In a teep message, as opposed to inside a rat's formatted.

D

There's no rats formatted message: okay, so as long as the nonce is in the teet message, why do you need both a nonce and the token, as opposed to only using one of the two, because.

B

Because they are used for different purpose and the nonce shows up only in one message and the token shows up in every message. I.

D

Guess the question is: why not put the nonce in every message? It's really the question I'm asking in get rid of token. That's what I'm was the difference in purpose, the.

B

Difference the nonce is for the is in a query, request: I'm, the damn sends it to the client and if it wants to get and wants to get an attestation entity attestation, token pack and then, and that nuns would in response would not show up in the in the people. Search buddy would instead be included in the eat message. As one of the claims that's.

B

C

Of token, in the tape protocol is very handy for the implementation, because token is able to use as a sequence of the message. So if one message from time- and they reply is going to be from device it and it's just going to have to keep incrementing the token number- probably the most use cases and that will be easy to track. If, when have lost or it's the packets not received we're just waiting for just the next packet. For.

B

The device has my table, our DES and you send out my trade credits. You need to match the requests or correlate the response to requests. That's why their son I was.

E

Like acoustic here so comment on a sequence number I: what is that I think you times I'm an issue about you want to people case it there's.

B

No sequence, number are the token it just the device, the beam sequence.

B

D

And the token is used because you're gonna have multiple outstanding requests at the same time, is there it's all over a right now, anyway, it's all over a a transport session that provides serialization. So it's so you only need this. If you actually have multiple outstanding query requests.

B

But remember that we also support devices with multiple T's there's, no reason why you wouldn't send multiple requests. At the same time, different teen years, great yeah, yeah.

B

Like lengthwise, that's also a huge difference, so I I recommended to use unsigned integers I, saw cosmos sort of in the belief that this is a better understanding.

C

Yes, easier for computer language to match match in binary integer than the string I.

B

I think what I recommend is to sort of change this pull request from into unsigned in, but and then merge it into the protocol. I think that's good, but there will be more changes later with in one of the issues that Akira raised on sort of fine-tuning the CD DL so we'll we can talk more about this aspect. What is these type of changes in? There would be some work.

D

Yeah I would still like I think you answered my question earlier about. Why is there both I'd like to see some text in the document and I know that you added me as a as a co-author, and so I may help to author that text? But when I was talking about rets formatted, you actually entered that by saying the dances and the rents formatted, which is each right just for I.

D

Didn't not if running the call necessarily knows that it's eat, but when you say rents for a minute, I just mean eat right, so the nonce comes back and the curry responds to eat and I think we just need some text in there to explain that why both of them are in there, so I.

B

I thought that I added some text but I'm sure there's room for improvement here. Yeah I, don't.

A

Think I came across Hana so apparently.

B

Not I'm, sorry yeah I need to I need to improve that yeah and I will make it proposal and see how you guys like it and.

C

E

Coming here remember, I saw the email to come, announced right what they should be integer on, or it's a how many four bars secrecy yeah.

D

It's not the poor request, I think it's in the issue in the issues list.

B

Probably Chris no yeah, okay next word request.

A

Adding text yeah.

B

Yeah, that's why I um since I was working on on the implementation and I thought that we need a little bit more text about creating and verifying the deep messages and so I I created a boom request to do that. So if you go to the files changed um that.

B

Whatever it is, yeah scroll down a little bit, so it's um made some changes here, not so relevant yeah. Actually, um that's something I want to bring up so previously. I am. This is goes back a little bit to work where we actually allowed in signing and digital signatures and Max and but so far,.

B

That we only had talked about in the architecture document, at least the talked about digital signatures are not not Mac in so iiep I sort of stripped that out um in specifically to focus only on cosine one on its cozy sign. One signature, which is, um as you know, for one signer um I think we should be very explicit about what functionality one we want to support, because cozy is kind of a broad toolbox and we shouldn't just wrap everything in because, after all, this code will go into the trusted computing base.

B

So we better be a little bit selective.

B

F

B

Has some some thoughts about this? Maybe you guys have some use cases, for example, for the regular cozy sign which allows you to include multiple signatures, for example. Would allow you to sign with multiple algorithms but I? Don't see that that's a that's a an issue here of.

C

The even in the suit manifest it has the same member called.

C

All this fourth different tact.

D

Yeah cases suit does have cases where you have counter signings right, because the author of the suit manifest and the TAM and marry other entities besides just those two. But here if messages are just coming from the time of the t, p-- agent, then maybe you don't need counter something which is I, think what Han is assessing. Yes,.

C

And what I want was trying to say is even if the suit manifests its how to present this and binary format was not clear in the suit manifesto see court yeah. This for tag was wasn't, it was defined yes, baby so doesn't know what which point to be binary string by string or number or yes,.

C

Yeah deleting from the voice so.

D

Accurate, if you have any feedback on the suit manifest document, can I ask that use either sent it to Brendan or posting the suit list. Okay,.

C

Yes, great thanks yeah.

B

F

Hannes, this is Russ I, agree, I, think the signature makes a lot more sense, since you expect the same code to be delivered to multiple T's. You.

B

Think that the cosine cozy sign one is good I.

F

Don't care between side and side, one Jim was really the person to comment on that I'm saying I like the signature more than the Mac okay.

B

Yeah and I think, if that's that's my proposal, of course, maybe there's someone else has some specific use case and some ideas and we should discuss it or maybe have it a new version or so.

B

Okay, anyway, if you scroll down a little bit.

A

That's what you added right, sagen, the green, is what you're trying to add.

B

Exactly so so I added text for both I'm, adding and verifying, and it's kind of obvious in some sense, but what it? What it essentially says is that you talks about the cosy sign. It talks about populating the headers according to the cosa specification and.

F

B

Of course, the content of the message are not obvious, but the content of the message goes into the sign payload. There are different options that cause the office and I'm, basically choosing one here and and there's also I'm, using a seaboard tag to indicate that this is a deep message. There is also possibility to use that indication elsewhere, but that's kind of a sensible approach. What.

D

Is one 262 me when it says if the teep message is signed.

B

So so the I was a little unclear whether, for example, an error message. I, wasn't quite sure how to best treat the error message or whether the error message there could be cases where that EEP message is not an error. Message is not signed, I think.

D

We disallow that and force all messages to be signed. I think we talked about this in the context of the Oh charity protocol and that was the conclusion. I don't think we should be any weaker in the T protocol. Okay,.

B

Okay, then I would change that yeah I.

D

Think at the Berlin hackathon I think there was also a question that we answered during the hackathon about that I, Kira and folks asked, which was our t p-- messages when they put in too close there, they sign and then encrypted or encrypted and then signed and I think it is answered, but I think in the section here and creating a teep message. I think the wording could be clearer about what the relationship is to encryption. What that happens just in terms of the text.

B

So um at the moment, like there's only signatures- and there is no encryption here- that's since at this level, I'm.

D

Sorry, encryption at some level right.

B

D

The personalization data discussion that.

B

Would be at the at least that's what we said previously. Of course we can always change our mind, but it was at the level of what the does to manifest and they the sort of data that comes along with it, would be there so that that's the place where the encryption would go. But um currently the text doesn't talk about this and and I think. Obviously it should I think.

D

It has to you one of the OTR P, so Ming help me out here, but one of the discussions that I believe that we had around OT RP. Was that say the query response equivalent that comes back. It gets encrypted with the Tam's public key such that the information coming out of the TE can't be decrypted about anybody other than the Tam right, that's the type of stuff. We want to use the cozy objects, encryption.

B

F

B

Need to do at that, so so, but this this at the moment just talks about those sort of basic, deep message, processing and doesn't cover yet the other things that which is talking.

D

If you, what ever I'm you're saying that's what.

B

I see this is this: is the.

D

Section on creating a teep message that I think would have such a discussion so.

E

My you can be using public key there.

B

Okay, so if you guys have some comment on this, I will change make the comments that were previously brought up into account on the on the signing.

C

E

Yes, more kind of look here. I didn't know too, that a use of work with a lowercase e EP, maybe crowbar do you saw up case. Do we do we always after case yeah, others, maybe they've.

A

E

I love it a new terminology, class, okay,.

B

I, can I yeah I align that to yeah.

E

B

I didn't pay that okay, okay, next via.

A

I lost track of where I was.

B

Yeah right I noticed that that's a little bit embarrassing. Of course, I noticed when working.

B

Okay, so those are Nazi boy attacks, but the or keys or whatever you want to call them, but they they end up. So the protocol sort of a tea protocol messages are currently defined.

B

It's it's using a map and and for each of the keys in a map you have to essentially define a number for them on or whatever you want on, so that it maps to the value, and so far that was missing from the document, so um it seems that maybe I should maybe the term key is the right term name key and then there's also the data type related to that item. If you can again go to files change, you will see what what actually mean by this.

B

H

Key is is definitely the right term in a civil context, of course, in the content security context that can be very confusing, so cozy, for instance, uses the term label for that. Okay,.

B

Okay, then change it to label on if you go down, is another change that I probably should have made shouldn't not have made here, but it's okay. um This is the real item. So, for example, you see there's a pipe um sort of filled in the message that we talked about token requests, etc.

B

Nuns in India's and each of them needs to have is it's filled in this map, and so so we can associate that and I'm obviously suggesting to add that to the to the document to make the hoard specification, implementable and I I think I looked at, it was the CWG on what we did there at sort of kind of where I copied it and yeah. We.

C

Don't use number it's going to be byte string, so the long label name is going to be consumed.

C

Instead of one byte number yeah.

B

That was definitely not my intention that I don't think that makes any sense at all. Yeah.

D

So I'm, not the super expert, but I thought that so I'm looking at line five five, eight, the type isn't that person in every possible message. Why does that have to be inside the map.

B

So so you can choose whether you want to whether you use an array um or you can use a map. Of course you can combine things if you want, if you think that that's there's a benefit, and so the way it's currently written is that the whole thing is a is a map I.

B

This is quite useful when you have many optional elements in a or if you have many optional elements in a message, and so that's what I.

D

Am asked is if there are fields that are not optional and, like type is when it jumps out at me, then could it be an array with two elements with the first element as the type and the second element is the map of stuff or something like that? I don't know I'm, not the super expert is what the most efficient coding is.

D

But the point is: if type is not optional and will always appear in every possible message, then you don't have to include the label inside the message and you can get more points out of it.

D

You you, you could do that. What is if it increases your code size to do parsing, which way is better so to.

B

Me it looked easier to just use the map and do it that way, but you've been implementing this as well. So what's actually Dave, you did not start it. That's what I did.

D

Too, but when I did my implementation at the Berlin hackathon I was just using an array of fields in a particular sequence, because there was no labels right and so I was using. I was assuming that everything was Amanda. It was mandatory in the first implementation. I was doing so. I didn't have enough information, so I just did an array with no window labels. Okay,.

H

Yeah so conventionally it's it's easier to to an implementation to take monitor, feeds out of an array, because in a map they may be anywhere, so somebody so I could send the type last, and so you cannot really process anything else of the message before you I've seen that type think Dave's approach is actually a good one. The other observation I have is that the the content of that table particular the third column really is in this CD DL, so I'm not sure how much we win from having it in the table here.

H

But but I haven't, really read the document and detail yet so that comment may be mistaken.

B

Yeah yeah I took it from as I said, like from the CWT um support.

C

B

Approach, yes,.

C

Third column, I agree it it's it's good to have the third column information in the city, dealer format right now in the tea protocol, the type for.

A

C

Name is not in the it's not written in the CDD or for up message. So that's why probably it's in this chart should.

H

C

C

Optimized version of the tip message suggestion in the many news today is I wrote the type insider tip message as a video format. Actually.

B

We can um it's probably a good time to switch over to that issue, I'm to just see how that look, because uh I think there's a lot of good stuff in here. If you switch over to the issues on the edit that the topmost 1:21.

B

Yeah Akeelah, maybe maybe you don't want to talk about your proposal to say if I think it looks.

A

In it all in one page,.

C

Yes, there's no sentence just City. The description here is just my reverse from my binary writing my um my notes from the hackathon. So from the vine. Every format is meant to be compact and doesn't have all the information like a label name is disappearing, reversing to the tickets format, and the city took me a while, but I'm. So one of the changes is I wanted to for the implementation perspective. Wanted to note each member in the map or array wanted to know what is the type so I wrote.

C

I add the type inside of the description, and then next thing I wrote was the what?

C

If it's going to be the member, a label name is not going to be a bike straight and I would like to use the number and integer, and if it's most of the message, the member is it's not going to exceed 255 I'm number, so it's one byte should be sufficient, so I try to put the number in one bite even for the query message: query response, a career, equestrian response, install and respond, the replies, successful area and stuff, and and yes so, what it's more like a clarify for the implement, implement implementation perspective and also it will reducing the size eliminating any of the having unnecessary byte stream from the tip, of course, like announced, we discussed earlier going to be bite straight from 8 by 2, 64 byte, that's going to be biting, but other than that yes, try to use regular in integer 4, which is for the computer.

C

Cb is easier to compare and match. So that's the summary I think.

B

Thanks a lot Kayla for putting that together, I think that's very good thing. We should fold that into the specification like taking modifying the table that we talked about earlier and then I'm taking the data types are here, I think it's more compact.

C

Specifying the size of the type you.

B

Have seen that I like that, so if you scroll down a little bit I think we can see that yeah. So, for example, here and the type is a you end, size, woman I think that's good.

B

Doctor talked about the token already and and the nine you copy that over from what we talked on the mailing list about to eat and stuff, and so on so I think to me that this looks very good.

C

And with and after this, without going to hit the now a binary straight, it's it's before! If we don't, if, before the encryption assigning, then it's less than 32 spydra 40, nice 245.

C

Before the jason, it was sometime.

F

B

More than 1,500.

B

Okay, I'm that issued done. I think we can. We should then look at some of the other issues and obviously lots of them Dave, who is MCD 500? Who is that.

C

B

Do you want to talk about select something from the S word since you fight a couple of issues, I.

C

Don't remember what.

D

I remember the two that I filed and.

B

When maybe we stopped if toastin.

D

Okay, good a number to you that the very bottom.

A

D

Components requested components.

D

So this one came up at the Berlin hackathon because we had previously added this into the OT RP spec, but had not been added into the T protocol spec and so the t p-- architecture talks about passing the list of requested tas. So you have say install our program is. I would like to install or I have a dependency on the following team, and so the Tim may have a whole bunch of you know, authorized ones, but whatever something needs to be installed may depend on whether there's some dependency or not so I might have.

D

You know a hundred. That would be okay, but it only wants to take the space of installing the ones that are actually needed, and so this would be a way of passing a set of things that are potentially needed. Then the team can decide whether it's authorized, and so that's what's going on here in the architecture document. In the query response that comes back from the device.

D

There was no field for passing in the set of requested to use only the set of ones that are installed, and so, as I mentioned, we'd added it into ot RP, and so this to say, we need the same thing in the T protocol, so another field in the list of OTA is just like. You have a list of TAS installed. We need another thing in there to add the list of TAS desired.

D

There's not proposal to an event, but that would go into that same CDL that we were just looking at and next to where the list of installed TAS would be as another field.

B

So Dave, are you saying like? Would that go into the trusted app, install message and saying? Okay.

D

This is in the query response, so the response in accuracy DDL that we just we're looking at right. There was like the query, request and so on. So this is here. Ya know that the dam says: hey, please t p-- agent, please give me your state, so the t p-- agent gives it back, oh and by the way, here's my state, here's the tas I've installed and then here's the TA said list of TAS that I don't have installed that I have dependencies on that things would use them if you would install them. Okay,.

B

Yeah yeah, we don't have that yeah and.

D

So this is just noting that we need to add that, in for consistency with what we did in Oh TRP, okay yeah, wasn't there an initial in OTR P either like I? Don't think it's in there in a global platform version, but we did put it in based on the discussions that Ming and I had had previous hackathons and so on. So.

D

That's what that one is the other one then this is you know, comments on that. One.

A

D

That's the one. This is the one that I mentioned, that we filed from the transport spec to say the transport had this change, but the t p-- expectancy protocol itself is missing the same discussion. So this is to say that the t p-- agent can cache. You know the OCSP data such that.

D

So this is the protocol changes you have to allow for the case that you can send a query response without having received the initial query request right, in other words, pretend that you've got a query request with all the bits set for things that you might want, and you can just go ahead and send that query response in the very first message: okay- and doesn't allow for that right now in the T protocol spec and that's what we did an OT RP is to allow for that which gets rid of an extra round trip.

D

If you already have a cache right, so the very first time, if you have the cold cash or that your certificate is expired or whatever else, then are you flushed your cashed and, of course you can just reach out and do the normal thing and connect wait for it to send you the query request. Then you've got the TAM certificate. You can encrypt your security, your query response with right, but if you can cache the thing that you don't have to wait for that certificate, this.

E

Is related to that tee page, you may be sure to call right there, discussion with second award to contact time first agent, local, but as there we don't want to send data. You were doing the Tamil can trust. How do you know that? So that is more for future run? A team already have that one then loco, lovely installer, whatever constitutive agent can initiate from there.

D

Exactly so, I think we at least Ming and I know what needs to be said in the document, and this just distract that we need to write that text and put it in for a consistency with what we want. Stuff sounds cool, yeah, I, think there's anything else have to discuss on that one. So that's the end of the two issues by far are.

B

You are you going to create to be honest, that not one for this and one for the error topic.

B

Do you want to discuss one of your issues? Yes,.

C

One one one is very easy one from the second one from the bottom: the tid device have to match or member. This is I, think it's already resolved. This is also I think it was discussed at over trp when matching from sending the TA ID from the Pam to the device or it or it will be vintner ID in class, ID device, ID and I think this was end up over only having some byte string only which will be called the TA ID and not with all this vendor ID class ID in the device.

C

Id I think this will be in the suit manifest, but I'm in the tea protocol. I think it was end up having discussion some some in some some hackathon, where I dip in the path.

B

B

D

We talked about this at the Berlin, hackathon and and I think you're to carry that this was already resolved, as that was what should be done. I don't know if the current graph does it, but I think it was all agreement at the brilliant economists. What the answer owes I think.

B

We back then, we said that the device ID would indeed be something that we we don't necessarily need. The class ID is something we talked about this in the context of the octi, which uses the UID um yeah.

D

So I'm thinking accurate because you did the hackathon report at the February interim from that meeting and I thought that you actually add a slide on this than we talked about in the temporary interim. Is your hackathon artwork.

C

D

I did or something I don't remember, but I know isn't that time frame did it was a February injury.

C

Using something 16 by.

C

D

We said we wanted to match exactly what ot RPE already had and that one had that ta ID and we said we were just gonna match what was in the Oh charity spec.

C

B

Name, um I think we have to look at what the existing.

B

Operating systems in in the t's actually do and okay.

D

Refresh my memory as I recall the discussion, and this is from memory which you've not had enough keywords: I, remember that there was a unique identifier that was outside of the suit manifest and like a TA ID, which could be a UUID or whatever it was she's had to be some unique identifier, not three of them like not vendor class device, but just one one thing that was unique and then all the other details like where to put it and so on. That's whatever is in the suit manifest, because suit had already solve that file.

D

Name, we're discussion that all that is part of suit manifest, not something we deal with in teeth.

B

Yeah I think we still need to sort of look at how we map this appropriately, because, for example, if the suit manifest says it depends on another ta, then that information needs to be in the manifest itself.

B

D

Because that was, if you remember a while back, we had a list of teep requirements on suit that the t p-- working group prepared and that I presented over into suit on behalf of the chief working group and the suit working group went through them and Brandon said yep already done yep already there yep party. There will add that will add that okay.

D

Maybe if they had been added yet I'd have to check, but the point was that Brendan and the suit working group in general agreed that yep we will accommodate teach requirements for those. Yes,.

B

I think we need to double check and put some text into, but I don't think I've addressed this issue yet in the inner current B Protocol draft. So we need to double check that as well.

C

B

We have to do that.

E

This look, you need more discussion, 25 TN. We upgrade it right. Well, 34 that will have new version, come in and say on 25 PI Heidi unique that you find.

E

Not a unique well may not be unique, define that.

B

Okay should be good to another. Another poor request issue.

A

You've got five and a half minutes left well.

B

Maybe maybe you do.

G

B

Planning for the next yeah.

A

Well so the next call is tomorrow, so we can continue tomorrow. I didn't cancel it just in case, so we can continue the discussion of these comments tomorrow or you could do it over the list and we get set up another interim. You know at some later point in time.

A

To the group I.

D

Think the question is whether there's any issues on here that need directions from the working group for public, with a proposal on how to address, because the proposal is would be a better question. Is there anything that would need direction before somebody can come up with the plural request.

A

We have not looked at these comments, so I'm.

D

Asking accurate because most of them are his yeah.

C

One is the east or delete wish from sending Billy Thoreau delete list from the client app to the pack. I agree.

D

That's a good one for us to discuss. That would be worth at least two minutes on now.

C

Third, one from the top.

C

Currently, in the message from query response from the device to the tab does not have a member to say, client Apple is expecting to person, have the same, initiate East or delete so, but some time device have a client app installed by the vendor or pre install or they it's the client app installed by other store or whatever it's called, and it wants to have the particular to hate buying into the client app to the yes. We have disobeyed from The Associated.

D

So this one, the the list of things that would be in the install, which is the same as the issue that I talked about what's different here, is this notion of? Can you can the teep agent pass a list of TAS for which you would like to delete? That's what's new in this issue beyond what was then the other issue, and that's not something the working with was ever discussed even in the old Sharpie context is: should we actually allow the teeth agent to passive things, for it that no longer has a dependency?

D

Maybe you've now deleted their rich apps that would used to depend on it, and so that's not just kind of hanging out there with with nothing that depends on it. It she's consuming space and it might like to reclaim space and passing that knowledge from the chief agent Tamm would allow the tamna says: okay, if there's no dependencies, then I'm, okay, with going ahead and pushing a delete message on that one, and so that's new, and that's why I said it would be useful to bring this up.

D

You never discussed this, but personally I think this is a good idea, so.

D

Things, that's not a good idea, because otherwise, since I was gonna, do a per request on how to pass a list of requests and stuff and Acura has a little CDL snippet. Then at least between Acura and I I think we have enough information to generate a pull request. But since we've never talked about the reason to do this, I just wanted to take a second to elaborate that on the list here and the on the call here. Yeah.

B

I think I think it would be um to think a little bit more I think it would be nice to have more context on about use about the use case that you have in mind because, like, for example, I'm I'm having a hard time seeing on how just another um filled with unsigned integer provides you that information. It.

D

Doesn't what you need is they need the list of ta IDs and so in the other issue that I filed its here's, the list of ta IDs. That I would like to install that I have dependencies on, but they're not installed right now, I I being the teep agent right thank you're, suggesting we might want the same thing of here's out of my I, say: here's a list of TAS that are installed that I have right.

D

Well, here's a list of the TAS that are installed that I no longer have dependencies on so it'd be okay to remove them. If you want right and so he's saying, we should actually have a field in there, which is a different list, or maybe it's another way of including the same list, and so unless anybody objects then akira and I we can go ahead and come up with the pull request. That does that. But we just wanted surface this notion that the kara came up with which I said I.

D

B

D

I think we're just about at time. So unless there's anything else, you want to say a cure. That's why I thought it was a good idea.

C

A

Steve said we are just about at a time, so the question for the group is: do you believe we need to meet tomorrow? I.

B

Don't think so, I think we need to work on the items and we could schedule another call in let's say a month from now and see what the status is and how we make progress with the implementations. That's what I.

D

Don't see a reason to me: Tora, okay,.

A

So I'll cancelation and then um maybe I'll, put a question to the group. Maybe have the meeting five weeks out something like that.

D

Sounds good I think it partly depends on if you're gonna start a working group last call on one of the documents or a second working request called and then would that complete, and so we should line that up with that timeline. So if you don't decide right now, you might want to decide like shortly thereafter. Let.

A

Me decide that, based on on the working group last calls well the results, so we're kind of gated on on Tyrian a couple of other items so, but in the interest of time, I will cancel tomorrow's and then we'll set up. Another interim, whenever we think is, is about the right window, but.

B

For that monkey picture document, I think the decision today was to start. The second working group last call it like anytime now like today, was correct.

D

To the one on the transport, we said what the time anyway, I'll give that to the chairs to figure out so yeah.

A

Not one we're gated, okay, so we'll get together, we'll send out the email for the action items. I think just make it all clear.

A

The thing that is clear, there's no call tomorrow I'll try and send out right away all right thanks.

G

A

With that you, everyone.

G

A

Last mention for those who didn't: please put your name, so if you haven't already on the virtual blue sheets, which is at the bottom of the ether pad alright, okay, thank you.