Internet Engineering Task Force 109, 18 Nov 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF109-DRIP-20201118-0730

Description

DRIP meeting session at IETF109
2020/11/18 0730

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

A

Darian, if you are talking, nobody is hearing you.

B

Can you hear me now.

A

Yes, loud and clear.

B

Okay, so I I restart yeah, I was explaining to you how how you, how you get into the conversation.

B

So if you did not expect to be in the direct working group, then you are um in the bronx session and um let's start so. I hope it's not the first time you see the not well, but if it is, please take the time to to read it, and if you have any questions, please um check that with um myself or um eric or every director logistic, so see what happens when you don't do it.

B

So when you want to talk just press, the right icon, which is the microphone.

B

And if you want us to see you, you can share the camera. I don't expect you to share the screen, but we have a specific icon for that, and there are also other tools if we would like to hum or if you want to chat, uh you can use that as well as the regular java client.

B

um Do we have a job, a jugger scribe? I think bob is doing.

B

That well I I can't see michael's saying um I was explaining how to unmute, but um bob are you? Are you the job described.

B

Do we have a job described then, oh, okay, bob we can do that um mini taker.

C

Still work is taking the minutes. Okay. Thank you. Steven.

B

So the agenda today um we will um so I mean okay, the milestones so today we're going to be focused on the architecture and then in a solution implementation. We will have a few presentations, implementations, demo and new topics like attestation claims a session and as well as privacy.

B

I mean the privacy has been on the agenda for a while. Now it's gonna be present, hopefully, and um then we will close the session um milestones, so we have the first document being shipped to our area director.

B

So thank you stu for the great work you did, because it was not an easy one, but you managed that, and now the working group has two I mean two work to accomplish. um We hope that the architecture document is gonna be by the end of the year, and why not? The other document.

B

Okay, any comment: any agenda bashing anything so someone would like to raise. Maybe I I can talk about.

B

I can talk about a liaison statement. We just received.

B

Or maybe made you want to to say a few words on that, so we received a liaison statement from itu.

B

I'm printing that on the screen, so that came a few hours ago.

B

um So it's um do you want to say something on it, uh med or.

C

Nothing specific for the moment, yeah so that we are, as you mentioned, we have just received the deletion statement. We also received them a note from from jim raid uh to to have more background. I would say on the on the work of this working group, so yeah, so the the intent will be to discuss how we can deal with this.

C

I would say if we want to um um to to reply to uh to to this uh or not, but this is something I will discuss with the aria director and also the with the working group. So this is this is to be done.

B

Yeah, so the working group uh you have the link here, I can put it on the well, I mean uh it has been sent on the mailing list and the documents are here. So if you have any comment, feel free to make some jim. Do you wanna say something.

B

Yeah, please go ahead.

D

I was about to ask daniel or mohammed: did it's just how we're going to coordinate a response to that liaison statement and will that be discussed on the mailing list? Or is this something the working group chairs are going to do in coordination with the area director and the its i2 liaison.

B

So um is your question: how are we going to proceed or is it a recommendation that.

D

Yeah, it's a question about how to proceed, and is this something that he says to use a loose term is going to be decided by the working group's leadership, or is this something that the working group is going to be involved in either drafting a response or approving the response before it gets sent?.

B

So maybe eric wants to respond on that.

A

Yes, indeed- and thank you jim indeed, that's a good question and the working group will reply so it will be. I mean we will not spend hours and hours on this, but the point is that the working group itself will reply. Of course, the letter or the email will be written by the chair, but content will be based on the working group.

B

Yeah, we will just be the pipe, um so I mean the idea is that if you want to make comments, please provide those comments on the on the mailing list, and we will also make it clear that um this has been discussed internally.

B

E

Oh hi, can you hear me now? Oh yeah, um they often do this while they'll lob liaisons over at us, and ask us to review. Ask a working group to review um their output. It's up to you to decide how much in-depth review you want to provide either individuals, the working group. um So you know approach at you know as you see fit, but I think the the going up and using the existing channels and making sure that it all gets answered in a timely fashion is important.

E

You can literally just thank them for their output document and be done with it. um You don't have to technically enter into any kind of back and forth with them, but it's up to you thanks.

B

Okay, thank you.

B

Yeah I haven't had time to to go through the document. I must say yet, but um I hope it's not too or forgotten to um what we're doing.

B

Okay. So, let's start.

B

Eric you want to say something.

B

Otherwise, too, please think the floor is yours,.

F

Actually, I thought that the architecture update was coming from schwei.

B

Oh okay, right I took the the first, uh so I yeah.

B

G

B

I mean at least me: I have problem hearing you.

H

He's very quiet.

B

It looks you're not speaking to your mic.

B

Now to me it sounds completely quiet.

G

Okay, one two three, but now.

B

Yeah, that's better to me.

G

Okay, all right all right just take off my speaker, so I want to say thanks to for uh making the effort already. um Hopefully we can make this out together on time uh next slide, please so we're sending out the uh zero five version just trying to address the previous issues from the uh I would say: 10 reviewers already uh we have a github to list other issues which is not a shared to the other person except the author.

G

Yet so we also try to analyze the issues we're trying to improve um at the end of the presentation, um just to keep in mind that we have not addressed all the comments.

G

Yet, uh I will specify what comment has been addressed in uh following slide, but we haven't got the time and the the I will see um the first thing we want to try to organize the context a little bit based on the comment and we needed to figure out what goes where and what really needed this draft once we figured that out, um so the the rest just filled out the details, uh hopefully under the working group logical, we can get a solution on that next slide, please!

G

So the reason I put this office slide here just to remind people who are not a family or the I uh drip drafts. I called the drip architecture drafter a drip ecosystem.

G

Correct me. If I'm wrong, this is my understanding so yeah I mean, I think the drip architecture driver should describe ecosystems, including um read, which is called remote id design emphasize on why we use um um issued id and instead of how so the details, of course, gonna go to the specific draft.

G

um Then we also refer to the requirement itself, and that's also some of the comments from the previous already and the architecture should also explain um the relationships among all the drip entities such as the uav ground control station operator registry and security, trustworthy. All these entities and the current arc draft, including uh all of them so and stu, has already shared offline, a list of the entities which we needed to. um I think we needed to cherry pick and discuss and hash out all the details. What should be including this architecture?

G

So, as far as I can tell from the list, we have most entities covered in solution draft in in separate draft. We just need to explain how it's going to be used and the relationship in between different entities in the architecture graph. I think that's the most. The comment and some of the comments from previous is kind of overlapping, but that's the main concerns to explain the english. uh The connections between each of entities uh next slide.

G

Next slide, please yeah!

G

Thank you all right. uh You can skip this one, just basically summarize what I said from last slide, so uh you can. You can skip with this one.

G

Okay, so this is one of the uh summary we have tried to address on the new version. Some of the comments are the same with from others such as lack of a broadcast read introduction, so we added section 1.1 1.2.2, which is borrowed from the requirement uh documents. I think one of the comments from daniel from you is actually trying to make sure the architectural draft is self-contained.

G

So that's one of the things we taking actions on it and we also added section three to explore all the um acronyms. That's the michael's comment. There's too many tl is, and it's hard to understand, so we we try to edit uh as much as we can on the section three. So there's a new section on section four: um this is it for us id.

G

um I expect the most in this section will resolve lots of existing comments such as like uh why hdit is a perfect design, I'll call it perfect design for a read and what perk pro what's the problem it will solve. um So it's current format. We put lots of notes in there um because michael has has comment. I think it's pretty common to list the issues.

G

uh We're trying to address this issue in this section um and also the comments regarding inform to language usage that will be. We will be gradually fix it once we put all the details in there, so that's shouldn't be a big deal next slide. Please.

G

So more comments regarding the hybrid remote id subsection. We remove that, and I've discussed with bob. I think that's not to be used useful anymore. uh Hopefully, everybody agrees that again we added the broadcast id figure and we will put more explanations for the comments regarding how a broadcast study would be used without networking or with networking.

G

We also planning to address the safety and the security issues. uh I would assume gonna be in section 10 security considerations, but there's I think there are three people comment on that constantly and amelia think that we need to make distinction right. What is safety and security in in in the architecture? Draft?

G

uh Okay, next slide, please so this is uh um this slide lists the things at least. I think we need to focus on uh for next one or two revisions, so mostly existing comments. uh uh Maybe it's solved. You will fill out all the details in the list items um for the others like alex, and I think and uh um his comment we have. I haven't got enough time to look at it, but uh his comment is more regarding why it is not perfect.

G

I mean it's perfect, I mean, so we need to explain that in section four uh also, as I already mentioned, that we have done in section one and the detail of the section 1.4, which is uh the drip architecture overview and that still needs some work to explain, drip ecosystems plus the stews of uh recommend, uh sorry um uh at least over the uh entities, will probably need to put the some of the entities there. uh Try to make connections um um then section five um comments regarding adding a ds registry section.

G

I think this is great comment. uh Then we can use that session to explain why reid uh should be using reverse dns lookup, and I think that's one of daniel yours, commenting you and also stu. Also, um uh I mean, as I mentioned, still stress the list of uh uh and youtube sorry the entities that will be also explained in section five.

G

Currently there are only two or threes, I think a product source and a registry is in there, but the other is not. I think I think it's important. We explain what other entities are, then in section, 6 is more about how us id can be used in the real world of project or solve practical problems.

G

uh Things like http naming collisions and that's one of the comments. We need to explain and why hrit has a better encryption than the others like x509.

G

So um I think that's that's that's my last slide. That's a that's a summary uh I have done and the the things I in my mind things. We need to improve with this draft, so any comments. I think this goes faster than I expected, but that's all I want to say.

B

Okay, good, thank you. Do we have any comments or from the audience? So when do you expect them.

B

The next version, or do.

G

Well, I'm guessing in one or two weeks we should have a new version to get the architecture. We want the the structure we want it uh right at least one or two weeks. I think we need to. We need to hash all the details. um All right, I mean I only took it over like two or three weeks, so I need to understand the the the other draft uh to understand what I mean.

G

I think the first thing in this meeting we understand, if, because I keep seeing the drip uh ecosystem um when we're talking about the architecture, it's this, the same concept that you guys have or the working group has like it- is the architecture's job to explain the ecosystem inside the group, not outside the group, right whatever we have currently in our working group repository.

G

So I think that's uh that's the things we need to agree on, uh because previous comments is to keep explaining that and droop architecture. I mean we don't have architecture, but in my mind we do have architecture but should be focusing inside the group that that's my understanding. So I think, when you hash out the architecture, the structure first in one or two weeks, then the rest will be fitting details and I think everybody can chip in for that.

G

Okay, the original deadline milestone we had should work out, um but they consider this holiday season on december and also the thanksgivings, um but you know expect some delays as well.

B

Okay right, so um I I I I expect that the next version uh people should commit to to get some reviews.

G

Right, I I would I would let people wait uh for next revision, because we have so many notes in there uh just wait a little bit and then we will call out people. Then things are ready to for uh deep reviews.

B

Okay, great andre.

I

Just getting ready for the next presentation, can you hear me yeah? We.

E

I

Can you just repeat what you said: no, I'm just getting ready for my presentation, testing. If video works and stuff.

B

Okay, okay, good! So let's move on to the next presentation.

B

Thank you very much.

I

Bye, okay, uh so my name is andre guerto from linchpin university, sweden and I'm going to describe process for making open source implementation of drip next slide.

I

Please. So it's a joint effort by the nine students and me in the in the course in the university, and we have two components to to develop so. First openhip open source version which have been updating for for few years and the new crypto protocols that bob is submitting in that draft and we also took open source open drone id as a starting point for for develop observer app and also a broadcast study.

I

Next slide, please.

I

So for hip, we need to update that code because it's used in uh at least part of uh solutions in indrip.

I

So first we needed to make better signature algorithm for for signing messages, so edward digital's, initial algorithm, then the structure of new arcades, which describe how the host identity tag is made and finally they're introducing hierarchy into the heat so that, for example, it's not like plain text, 128 string, but it's also include some data like who issued this hit. Next, one.

I

So this orchid actually now is a little bit outdated because it's describes the first version of um remote id draft, but, as you see the traditional orchid, they had the reserved prefix and for for new orchid, where we have hierarchy, we need like a special hash function, called c shake uh definable output and uh it's also inco includes the id of organization that issued it. So it's a new change. Next, one.

I

So for new crypto we have uh currently implemented kiock cipher um because it's light weight and more efficient than ies, but it has not been selected for next nist route. So maybe we are switching to hudiak. Also a key generation function based on it and the edwards curve. Digital signature algorithm that I already mentioned for efficient small signatures. Next.

I

So uh to test all this, we are using the open source core network emulator that we also have updated to include latest version of python test suits, so that we can check that all the new features are working and the base exchange works and in general code is operational.

I

I

Please, in this picture, for example, you can see the heap version 2 base exchange completing with new crypto um yuck cipher.

I

So this is like prerequisite to have this feature when we start adding trust into the remote id or provide transport for network id next, please so for the drip implementation. We want to start with uh implementation of broadcast drone id using bluetooth orifi, where we just assign this post identity tag in hierarchical way and for development platform.

I

It's a raspberry pi 304 with gps receiver, a very limited space, something like 20 bytes to include into the broadcast messages and to develop android application that people can can see which are drones, offline nearby and maybe in future use as a gateway for network id, and we started with this us redraft zero one, which explains why our uh orchid version is a bit outdated.

I

I

So for android application um for open drone id, it supported only bluetooth so far, uh but we wanted to try wi-fi first, because we didn't have like bluetooth dongle, and we took this wi-fi analyzer as like open source application to start with, and um it proved to be a bit challenging because actually uh to get some data from the drone, you need to connect to it as access point and then like try to figure out what is it broadcasting. So it's uh as uh next slide will show it's a bit tricky in practice.

I

I

So um currently we are reading this ssids of wi-fi drones and try to identify them this way in future, maybe using wi-fi, neighbor neighborhood aware networking mode would will be like more practical, because uh in current mode you basically need to root your android device and it it's not uh corresponding to the model when a user just installs something from up uh play, store and see. Let's see the drone, so it's, uh uh but on the other hand, this nine mode. It requires hardware, support from wi-fi chip and also maybe updating the android version.

I

So maybe it's also a bit challenging, at least in the short slide.

I

So in this slide you can see a prototype of wi-fi listening and displaying access points which are like flying drones in in this our current prototype, but since it's kind of hard and implement without rooting, so maybe wi-fi is not the best option for using this broadcast remote id, and that might be explains also why open drone id and the adams prototype has not been using it. So now we are switching to bluetooth because it seems to be easier and does not require this rooting problem next slide.

I

So currently we started to look at the back performance in bluetooth and there are different versions, so this is even like bluetooth, low energy, but I think for for drones. It makes sense to use regular bluetooth because we need the bigger range and also it's uh not so critical. On the battery I mean drones operate max few hours. So it's not like a sensor that needs to save battery, for, for, for I don't know, weeks or years so maybe it'll switch to the standard next slide.

I

But so far we found bluetooth much better to and easier to work with than than wifi. So there are already several applications available that we are working to to improve on and uh bluetooth flow. Energy range is not that big around 50 meters, but uh I think in adams experiments they reached about 100 meters total to 4 and 500 4.25. So we are looking also to achieve this kind of ranges slide.

I

So that's basically it so we are aiming to complete complete, like a full version of um uh remote broadcast id with uh bluetooth and wi-fi by end of this year. So now we are working to update their kit. Implementation of hit to 2.5 also uh take hodjak latest cipher and update to the latest air id04 implementation.

I

Hopefully we also have uh time to to try on a real flying platform like attach some raspberry pi and gps to uh phantom four tron and in future, I'm already defining for the spring terms, some physics topics and projects also for remote id and maybe bringing implementing claims and having trust into the hit.

I

So that's it any questions.

B

Well, thank you. That's um that's very nice to see things flying. I would say.

B

Any comment any questions.

B

Hearing none, I think we can move to the next presentation.

F

So um perhaps adam you could take over um note taking for the moment, while I present the next few slides.

F

So we've had some activity beyond writing drafts is my audio going out uh clearly yeah, okay, great oh astm, the the overall uh uas committee f-38 met in the first week of november, um but the uas remote id working group within f38 did not meet as part of the big plenary meetings, because the agreement remains that the f-3411 updates will wait until the faa publishes their final rule.

F

The uh uas redworking group did have an interim meeting they're very friendly to our few small requests, but all mods, not just ours, are in the backlog, iko's trust framework people are also um accepting our inputs in a very friendly way. They've made some substantial revisions to their documents based upon our inputs.

F

um I've mostly been working lately with the the people who are doing the use cases, that's the tron working group and then that gets um turned into identity standards by the di working group and then a network by the grain working group and bob has been more active in in those. But he indicated to me uh earlier today that that that's been a little bit quiet. In the last few weeks, we've had a number of interactions with various us agencies, starting with uh faa. Of course, all the other agencies.

F

Besides the faa, are waiting to see what the faa publishes in december and the faa claims that they are on track to publish in december and the the rumor is that they're flipping from network remote id to broadcast remote id as the baseline, and that would be fairly disruptive to what a lot of people have been assuming.

F

There was a lot of interest in what's variously called blue force, tracking or iff, which leads to interest in resilience against spoofing, which drip provides in the utm pilot project. 2, we showed multi-vendor uss, uss interoperability with you know, key functions, including both forms of remote id, uh remain range of the broadcast. Remote id remains a concern and the faa in their nprm said, don't use um unmanned aircraft registration numbers as the uas id type, and they gave their reasoning for not wanting to do that.

F

But in upp, two, the faa said: do correlation queries into our database and what you must use as a key is the ua registration number. So the faa needs to sort some things out internally and I want to quickly flip through the next four slides very quickly.

F

So you've all seen this before. I just wanted you to see what we said to the federal agencies and how we set it, and I don't see any point in drilling into it right now. People can look at this slide later if they want to next slide, and we had a lot of slides like this that you've seen before now, you see the fine print under the red cannot be spoofed.

F

Of course, there is no such thing as a system that can't be spoofed, but we think that to spoof this you need to have a little tiny quantum computer, and this was very popular with the federal agencies, and the point is that this is the first thing that we do above and beyond. Astm f3411 next slide.

F

So this is what it looked like. We did a. We did a scenario where we had operators alice bob and carol, and we had observers doug and eve, and there was a several step scenario and we showed that if the sender has only baseline astm or if the observer, the receiver has only baseline astm, then you cannot disambiguate between spoofers and real folks. But if both the sender and the observer's receiver have our trustworthy extensions, then yay verily, you can disambiguate a spoofer from the real deal next slide.

F

Oh the the picture in the middle is adam's app, yep, okay, so it's really nifty so way forward. uh Registries, big open area. uh This really needs to be hit hard. um We have talked about crowdsourced grid, feeding, broadcast into network. We need to start prototyping that and then we need to start leveraging um drip to enable the things beyond you know id as an end itself, things where id is instead a means to various ends, and so you know making the sender trustworthy, not just the communications, trustworthy, but the origin of the communications.

F

Trustworthy would be um an obvious next step and then we need to start thinking about what happens. You know on beyond that with intermittently networked autonomous uas, and I believe that was my last slide so anyway, a lot of interest from u.s federal agencies. I can't say what the europeans or anybody else may be thinking at this point. We kind of need some champions to you know to put this forward to easa and other caas around the world. Other regulators and- and um you know not just the faa thanks- I'm done.

B

Okay, so what you're saying what you said in the beginning was um that the broadcast mode is um is prioritized or they completely get rid of the network mode.

F

They're just well okay, so this is all rumor, because the faa rule writers are not allowed to talk to anybody else. Even other federal agencies, while they're writing a rule, but the rumor is that they are abandoning the concept of network remote id. Now I've gone on record with the federal agencies as saying that's not going to happen, because even if there's no network remote id by name, there will nonetheless within the scope of utm, be functions that are essentially the equivalent of network remote id.

B

Okay, any question.

B

So one last question for me, but does it mean that the drone and a provider will not establish a tls or ipsec session.

F

Right uh broadcast remote id is um a link layer phenomenon that is not udp, but very udp. Like.

B

Okay, okay, right! Thank you good to know. um I suggest we move to the next presentation. um Let me try, which is.

B

Adam yes, and and and is that the certificate at the station.

H

Yes, oh there it is there we go pardon the cheeky name. I worked. I worked, it's 3 10 a.m. For me, so I've been working on this the past couple days, so my mind turned to mush. uh So I'm going to just talk about claims, assertions, attestations and certificates. Oh my next slide, please so small recap. This was first off the draft that this is pulling from was rewritten massively. It got switched from xml to markdown.

H

I've started to call it drip proofs, but that's kind of me talking out of wherever I'm talking but uh stu started a conversation on the list uh because he was realizing that there was a lot of people getting confused because we were throwing the term certificate around. We were throwing the term claim around and then the word attestation started getting thrown around and he started a email chain in the list to be like. What do we mean by these terms?

H

There were some great responses from carsten, michael richardson, hank, bob and michael pelage, but it was clear just from the conversation that we needed to put a stake in the ground and we needed to define these terms. How drip was going to use them and give some examples.

H

So this presentation's kind of me after reading the emails about 7 000 times what I saw and how it fits into what drip is doing. So this is my proposed way of going forward with it, because it's important it touches the claims draft. It touches the auth formats draft. It touches the registry draft which hasn't been written yet, but is going to be, and is the next thing on my list, along with bob and michael pelage, and also the uas draft next slide.

H

Okay, so we'll start simple, there's claims and there's assertions. Claims are a predicate consisting of two elements. This comes from a definition I think stew um put into the list. um There are some examples there x owns y x is y x, belongs to y um and a little hints of what it looks like in drip and an assertion is a grouping of one or more claims uh by a given entity.

H

Next slide, please.

H

So here's an example of a claim. This was something that bob pointed out in his email. A hierarchical host, identity tag is an assertion. Slash claim I'd, argue it's an assertion. It has a bunch of claims in it, as you can see in the color-coded portion at the bottom. We have a claim of. I have a unique identity or a unique hash that points to a key pair, and I have a unique registry that I belong to. That's a pairing of a rra and an h, an raa and an hda.

H

You could also extend the claims to be oh well, I'm using this prefix and I'm using this oga id, and these are the claims that the hit asserts.

H

But that's all it is it's just an assertion of I'm I'm in this registry, and I have this identity, which is 64 bits of entropy next slide. Please.

H

So we move to the next piece attestation and certificate. An attestation is a signed assertion. It can be signed by anybody uh in drip scenario. It would most likely be signed by the party that owns or claims to own said assertion, so they have the uh associated private key pair public private key pair that the hit points to and you sign against it or anything else that you want and use the hit as a key to get in um the minimum is a hierarchical hit. Hi pairing the host identity, pairing.

H

You can also use it to bind relationships between different parties using other pieces. The second thing is certificates, so a certificate is by stu's definition that I kind of took- and I think is a generalization of what carsten and hank and michael were going after is it is signed by a third party and that's the critical thing. A certificate is something that a third party is attesting to and for drip. It is mostly identities.

H

um We could narrow this further to be a trusted. Third party aka. The registry, though I think that gets us in a very weird situation where we're saying. Oh, it's a trusted third party, but then how do you trust it? I don't wanna go down that rabbit hole, so it's a thought, but I don't think we need to go there unless the working group thinks we do next slide please.

H

So this is I'm sorry if it's small, the slides are available. So you can blow this up to see it a little bit better. These are the um examples of attestations and certificates, the structures that are defined in the identity claims draft.

H

So a typical attestation is a hierarchical host identity tag, it's a corresponding higher host identity, a expiration, timestamp signing timestamp and the 64 byte signature. That's at the max. The minimum would be the hierarchical host identity, tag, an expiration time stamp and a signature certificates embed these attestations, so c, x, x, c, x, x and c y y in these examples is wrong.

H

It should be a x and a y y because it would use the things on the left in those place marks and a third party would sign against those to assert and to attest to the entities owning it with time, stamps and expiration time stamps and there's varying forms of this, making it shorter changing the fields, removing fields etc.

H

Next slide, please.

H

So this is the proposed flow in drip using the provisioning process as a guide. So the registry, the aircraft and the operator would create attestations on themselves. uh I'm going to be root and say these are r ah and o, but it's a-r-r-a-a-a and a-o-o. The operator creates a certificate for the relationship between itself and an aircraft. This would be coa, so the term doesn't actually change.

H

It's still a certificate and the registry would use aoo to create a certificate between itself and the operator with cro, um and the registry would at least use coa a certificate on the certificate regis operator on aircraft to create croa and what we've been calling cra for a long time now, which bob is now starting to call the offline attestation certificate and this actually changes a little bit. So, let's go to the next slide.

H

So we had a discussion me and bob, because bob realized that there was a timing attack or there was a replay attack on the certificate that we were actually using and that we've been demonstrating for the past couple months, and that is that it can just be replayed, and this is his proposed fix to it. I see where he's coming from. I think it's a good idea, um so the top portion uh is created by the registry. It uses coa to glean the pieces and create this attestation structure of the identity of the registry.

H

The identity of the aircraft, the hi of the aircraft and the timing and expiration time stamp over being signed over to be like the registry approves that this aircraft uses this id and this hi to do whatever it's doing and then live on the aircraft, with every authentication message being sent, which is a cert message.

H

Well, what we call a certain message right now: the aircraft would add in another timestamp assigning, timestamp or current or expiration timestamp and another 64 bytes worth of signature, which is created by signing the entire uh upper structure and the four byte new timestamp the question.

H

um Well, uh can you go back daniel sorry, so I believe that the upper portion will be defined in the identity claims it might get defined in the registry draft that has yet been written. I do not know for now it will be in the identity claims draft the lower portion is going to be defined in the auth formats draft. I know that for certain, so that will we have to make some amendments there. um I have an open question: is this a certificate or an attestation?

H

The whole structure? I know that upper bid is an attestation, definitely because it fits with the definition. But what's the whole thing is the whole thing a certificate or is it an attestation because it's the aircraft signing, I'm not sure. So I think it's an attestation- and I think bob is right in saying it's an attestation as well, but I'd like some feedback on the work from the working group on this, because I'm not a hundred percent sure how it what bin it falls under.

H

It doesn't matter to me it's just the text of what I use uh next slide daniel.

H

Okay, so what needs to change so in the identity claims draft, specifically, what needs to change is section 1.1 1.1 is where currently I defined all four terms, I need to make sure that they line up with what I've just discussed here and with examples as needed.

H

um I need to change all the terms around to say, search change certificate to attestation, where it needs to and attestation to certificate where it needs to um and change some of these short names or friendly names to some of the structures. um I believe the offline form is a good name. It might just be called offline attestation to match with what bob was going with, and I need to prefix the provisioning section so that all the naming conventions flow through the whole document.

H

H

So other to-do's- this is kind of overarching for me, so that the working group kind of knows where I'm going with a lot of the work I'm doing um so first off, is the authentication formats draft. Obviously I need to update that. If I update the identity claims, I need to update the structures there to make sure that everything aligns and isn't being fragmented.

H

um I need to start working on a registry drive for bob we've been discussing this I'm getting in touch with michael polage me and bob and michael will be sitting down. Hopefully in a week or two to discuss some things, I have to continue the ax implementation, which is still unfortunately closed source.

H

I'm working on that fingers crossed, um I still haven't, switched to the newer off style. It's still on the old off style. um It got frozen due to the many demos that stu actually briefed. I didn't want to change anything too suddenly and make um things explode in front of a customer's face uh next slide.

H

I think that's it yeah that is it so here's a nice little xkcd comic, which is becoming a growing trend with me. Any questions, comments or concerns either raise them on the list, bring them here. I'd be more than happy to answer anything I need to.

B

J

Hi, could you go to slide four? Please.

J

So in uh in claim one you say: uh enzione's unique id, um yes, yeah unique, I'm not quite sure what this can't be claimed or sorry. Uniqueness can be cleaned. Uniqueness can't be proven.

J

So it seems like strange thing to define.

H

So I think this ties into a little bit what the registry does, because the registry would get it an age hit and then check in the listing of eight hits that are available of. Oh, is this unique within my scope, the hda scope and then the sign and the certificate come in to claim uh this is a unique id. So the wording I I agree with you is wrong here: that's not the right term.

H

I don't remember exactly what I was going for. Thank you for pointing that out it comes. It comes down to the the dance with the registry. Wow, the you know, the ua creates a hierarchical hit for itself.

H

It creates a key pair and then it hashes it and then creates the hierarchical hit, and then it asks the registry, the hda. I have this new 128 byte thing. Can I use this to be who I am? Can I use this as my name as my identifier and the registry gets the final say of saying no someone's already taken that that's already in my list or yeah? That's yours!

H

Now, here's a certificate claiming or an attestation how, whatever the term we use to say yup this is yours, you can have it so wording needs to be worked out. Thank you for pointing that out. I'd be happy to get some wording from you. If you have an idea of what needs to be there for the wording.

J

I'll see you all right thanks. Thank you.

H

B

Any other question comment.

C

Med to move to the next slot because we are running out of time, so uh bob can jump in.

H

Thanks everyone, hello.

K

Hope I'm coming through.

B

K

Okay, because it's just reloaded okay, I'm gonna have to go fast here. So let's go on the next slide and this draft has been around for a while. This is from the drip charter. Why we're doing this? Let's go on.

K

Privacy, to whom- and that is to the observer, what whether they should know or not. No, let's go on um the problem statement is that in the standard messages there is uas operator pai and uh something needs to be done about that to fight to meet pai regulations go on um who should have access pai, the uss for the ua authorized entities, um no whom and so forth others, but we do need to protect. We do need to encrypt the api. That's coming with the broadcast, go on.

K

um So how to encrypt the pei? um The us should have business relations with some uss. In fact that's basic requirement. Thus they can establish a symmetric key for encrypting, the pai with authorized entities able to access, ask the uss for either the pi directly or for the key for ongoing real-time access to the information and so on. um So let's go next slide here, so the symmetric cipher must encrypt without expanding clear text. That's hard no bites to spare.

K

They would encrypt multiple messages. The operator id message operator, location in multiple system messages. Obviously, that operator can move a foot and all of a sudden their location changes so be able to do this in the high constraints.

K

I think michael st johnson will point me to a solution going on michael st john's is very simple ascfb, uh with a small uh with this, with whatever your block is, in this case, cfv 32 with the hidden iv and this metric key derived by a hybrid ecis scheme handled by when the operation is registered and key duration function is now included in this last graph using kmac.

K

So this is using in many ways, standard components. Asc, fb 32 is well defined and how to handle the ib and the rest of it, the the key duration. Yes, I am using kmac, but again this is all standard pieces going on.

K

um The uh I said this: the cypher feedback allows for variable length, block sizes like 32 bits. I chose 32 bits because that's a size that fits with the fields and smaller size might lead to crypto tag against small location changes.

K

The unique id is not needed for each application of cfp. So again it's it's just a good cryptographic fit. I did get a couple bruises on the cfrg list coming to this conclusion now when to encrypt um behind this, the the pi must be conditional um only when allowed by the uss um only when the uas has connection to the uss, um and otherwise, uh if you have don't mean, let's, uh let's do the encryption, but there are limitations to this and that must be put into the protocol and the recognition.

K

All that is it text is in the draft continue.

K

um I did look at alternative cfp there's a fiso scheme, it's slow, but pretty neat, um probably asctrs. We needed two bytes in the message for a counter and there's no two bytes available, um and I've spent quite a bit of time in the cfrg list. On this, um there might be an alternative coming from the nist lightweight crypto, but that's not for another year yet. So that's why I'm staying with cfbs 32 for now continue um so again. Carmen's met is privacy, one and two confidential handling and encrypted transport.

K

Can you and read the draft? It's been out there and I'd like to see a drop adapted adopted by the work group for for this. This is currently the only pai in the estm messages that may change with the final making and and changes to it. For instance, the operator location does not save the operators. Elevation is that the guy on the third floor balcony or the fourth floor balcony, um but that's that's easily handled, um because that would just be handling eight um eight bytes in and works in this model.

K

So uh I like to see this adopted, um and uh so let's go I'm out of time um and so I'll take questions offline. I think jonathan's up there.

J

J

I'm just a hangover from the last cube.

B

Okay, so are we done now.

K

That's it. I have that's all. I have.

B

Okay, we don't have much time for questions so because I I am tempted to adjourn that meeting um unless we have a last minute question last minute comment.

B

In any case, please um provide your comment, questions on the mailing list and we will plan some interim meetings. Thank you, everyone and see you at the.

B

B