Internet Engineering Task Force Interim Meetings, 27 Sep 2023

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-OPENPGP-20230927-1400

Description

OPENPGP interim meeting session
2023/09/27 1400

https://datatracker.ietf.org/group/openpgp/meetings/

A

You want to volunteer, doesn't have to be a solo gig. Multiple people can do.

B

It I can do it as long as someone else is helping, because I might have something to say and then I like mess up and.

A

That's great, thank you Aron. uh Can we we we we look for at second.

A

Volunteer understood, Michael Michael says he's attending another meeting in parallel, so which does make it hard to take notes again. Anybody is happy to volunteer to help Aon take notes that would be appreciated in the note taking.

C

Tool St Ro go ahead. I see you in the there are. Is that, were you raising your hand to.

D

Volunteer, uh yes, I think so many thanks. Do you hear my video isn't working so.

C

We can hear you just fine, you don't need the video thanks.

A

Thank you uh and for the notak takers, uh we, you know we do.

E

Have recordings.

A

So it's most important to try and just get you know, decisions um outcome of discussion and you don't necessarily need to try and capture all the the blowby.

A

Blow so should we start at the usual 2 or three past the hour.

C

Yeah I'd say we can start I had just crazy audio breakup for you for a minute there, Stephen I, don't know if anybody else had that ifence on.

A

My shall I can mute to solve that problem.

C

No, no, it wasn't a mute issue, it was a. It was just like your words came in all spped up.

A

Oh, that's probably me, then okay I can put in a headset if.

C

Maybe it sounded more like Network interference than like local audio problems. Okay, okay, do you want? You kick off, yep sure, uh welcome everyone to the open, pgp, the uh interim meeting in September 2023, um uh you're I'm, one of your co-chairs, I'm, Daniel and Stephen- is your other co-chair. uh Thank you very much to the folks who volunteered to take minutes um to take notes rather, which is Aon, Whistler and stabos. Anybody else can click on the uh note taking link um and help them out as well. That would be great.

C

This is part of the iotf process. So you have this ETF not well here. um You've probably seen this in other uh iatf contexts looks like everybody here um have has I think been involved with ITF at some point or another, just just a reminder um that you should pay attention to these particular concerns, in particular um concerns about uh intellectual property um and uh being good to one another. um This is an all remote meeting. There's nobody in person!

C

uh Please take your audio and video off unless you're active. uh If you can use a headset, that would be great um and if you want to speak, just add yourself to the queue. The queue is a little hand button um in the upper left of your meet Echo interface. If you press that we'll see that you're.

F

C

Then either Steve or I will call on you. um There is a text chat as well. um You can either see the text chat in a tab here uh to the left, which is where it says, chat panel or you can go to zip. ietf org and join the open, pgp uh channel, uh and it's useful to be able to follow stuff.

B

C

Well, um one more thing: this is a the ITF code of conduct uh be courteous, uh challenge, um challenge ideas, not people communicate, clearly uh use reasoned argument and we're looking for fixes that will help the, inter as a.

D

C

For any particular um uh party- uh and this is a working group- so we are trying to figure out how the working group is going to go our agenda for today, I'll give a brief uh uh reminder of the status of the crypto refresh draft, which is our only chartered work. um And then the main point of this interim meeting is to try to sort out what we want our new Charter to be because we're very close to the end.

C

So to that end, we've got um five presentations uh from four different people about specific work that might be considered for the chartering, we'll take a look through the specific text that's been proposed and if anybody has any comments or wants to point to existing drafts, uh we can handle that EV as well. uh I see Paul, asking me for more volume. Give me a minute and I will try to do that. uh Is that any better.

C

Paul: okay, great.

G

C

um So this is the current agenda, any interest in uh critiquing or adjusting.

C

That not hearing anything I'm gonna um and let me just make sure that we have everybody here who has submitted. We do not have Neil here. um Otherwise we have all the folks who have submitted slides.

G

C

You're you you'll present Neil's web of trust, slides.

G

C

Okay, thanks, if you can raise Neil- and uh he comes in before we get to him- that's also works too um and uh Daniel I. Have you listed there under the rechartering text, because your merge request for the chartering text is probably the most complete, but that doesn't mean that we're.

H

C

Expecting you to present it, although we we do I hope that you'll try and why those suggestions so crypto refresh status. um We we had an area director review did not expose any major flaws, but there were many suggested improvements. uh Paul has been uh diligent about responding to those and submitted a whole and also swept through the out sending Arata. uh There are proposed changes um that are in gitlab and they've all been tagged with the ad review. uh Sorry ad review uh uh tag in gitlab, there's a link there.

C

If you open the formal slides you can click through to that or you can just go to gitlab um for the rfc4 Bas repository um and uh click over to the set of merge requests that have that are, and you can sort them by a tag with area director review. um The goal is to get this thing out the door. So if you see anything in there that you don't like, please speak up, and if you see there that you do like, please also speak up.

C

uh We want to know that the working group is okay. With with these changes um in response to the area director's review, and many thanks to Roman, who is not here today, um but for his work on uh on taking through that uh any questions about the crypto.

A

Refresh so just um wondering what our plan then is to submit a new ID and then give the working group a few days to check Che that that's okay and then discuss with Roman if he thinks it's also okay, to move forward, I guess.

C

I think that's right! um Paul! If I recall correctly, there are also a few outstanding Arata that you mentioned not having dealt with um and you're looking for more people to propose texts to correct those S. You want to speak to that.

I

Yeah that's correct there. There are like um I, think two or three items that um have no text yet um um because I wasn't sure what to propose um other than that. Yes, I um I will wait for a bit more feedback before U merging the current request into the um into um Mainline document and then um I'll cut. A new draft for Roman to look at like most ads, actually prefer not to deal with like the the third party system, because then they're not guaranteed that that actually got into the draft.

I

So I do want to cut a new draft for Roman, and then he can say if we need another one, it doesn't really matter that we're going to ref it twice or not. So um so my plan was to merge it in and if we think we've addressed all the issues then um cut a new draft and give it to Roman.

A

I

A

And and Paul any idea on, what's what's a reasonable timeline for that, just roughly.

I

Well depends a bit on feedback if, if there's a lot of feedback that requires changes, it will take some more time but other other than that um I would say. uh I really want to get this done within one to two weeks like I. Don't want to rush it too fast, so people who happen to be gone this week can give feedback, but I also don't want to wait too long. So does that seem reasonable.

A

Yeah, that's that's that that's great! um So, let's, um let's ask people to to consider any issues: the rising look at the Ming L traffic. Look at the tagged issues in gitlab um o over the next week, if at all possible- um and let's say with the understanding that, if you know if people don't raise issues in the next week or so then we'll we'll move ahead with putting a draft and and giving it to Roman again.

I

A

I

I mean if I don't get any feedback at all I'll I'll I'll try to individually Pok on people to at least have um one more set of eyes to look over things. um I! Don't really want to merge anything that that has only be seen by me, um but I will I will poke. That and I will give a an update like uh on Monday again to see where we are.

A

Great and feel free to ask I, guess myself or dkg to to have a look over any.

C

Changes I'm I'm, specifically committing myself to looking over those changes this week um before the before the week is up that Paul is given I happy to have that in the notes um and I will also and I noted that Daniel in the chat U is volunteering to look over the the last AATA and we'll do so. I'm also going to look over the last outstanding AATA and see if I can proposed text so I. Don't think that Daniel or I would end up in any serious conflict.

C

There U, but you'll have at least something to choose from either M or Daniel's to deal with fin, rather their.

A

Great, and our goal, of course, is not to add anything that you know gratuitously requires those loads of iterations of chatting.

C

So right we are not looking at substantive changes and we're mainly looking at clarifications.

I

And sorry, one more thing: um I I did talk to um the isg and um Ayana about where they would like to see a list of erata entries that this document fixes um I wasn't sure what the common practice was. But it seems that, because this list is so huge, um Ayana specifically said they would really like that to be a list in documents. I I'll, add some appendix or we list all of them.

C

Okay, maybe like as a sub, okay yeah. That sounds good where, wherever you think makes sense, I don't know if it's in I considerations or elsewhere.

A

Right, okay, so I think. The summary, then, is uh if you care about this, go look at it in the next week. um Meanwhile, Paul dkg and Daniel will be working on it and we'll produce something to give for ran in the next one or two weeks and then hopefully we'll all proceed happily towards becoming an RFC in the months ahead.

A

Yep great, thank you thanks Paul for for all the ort.

C

H DK I just had.

A

um Just as a kind of level set on the on the chartering, um I think our goal today is to have a good understanding of what we want to have in the new Charter and then to Wordsmith Charter text. um Subsequently uh with a view to hopefully having a charter to present to the to our ad and the isg before thef in November.

C

That a good I think, that's I, think that's correct Stephen. So the goal here is to get people on the same page understanding what people are interested in um here if there are concerns about things and also I, would like, during this meeting to think a little bit about Milestones, um because that's one of the things that Roman specifically asked. uh If we're proposing a charter text, do we have any idea about specific Milestones that we might want to include so.

A

And and I think yeah, and for that I think most Milestone dates are fiction, as we all know, but the sequencing is actually more interesting right. You know there's pieces of work that people think need to be in a certain order or are more interesting to try to get done. First, then, that's that's the useful thing for now and we can. We can assign fictional dates to those later right.

C

Right thanks, okay, so uh I think we're going to jump into the presentations now hearing no other feedback, uh so ustus. If you want to jump in your camera's working.

G

Yes, thank you, um yeah, let's uh Jump Right In next slide.

G

G

So as my observation that the current uh status, um the status quo, is that the standard provides mechanism and uh is quite vague on semantics, and we didn't change that in the crypto refresh because we felt like that was out of scope mostly and while some may think that this is a good thing for a standards document I think that's wrong or it's holding us back and as a motivating example, I have included um a random uh result from the interop test suite, and the test is asking a quite simple question: I think is a signature valid.

G

It's a binary signature. There is nothing funky going on with the certificate um here is some data, here's the signature. Is it valid or not, and what it mostly does is play around with the signature subpackets, and we can see that the uh results uh very widely and I. Don't think. That's a good thing. Next slide.

G

Please so I went through the open issues in the uh in our buck tracker and went through all the issues that have been labeled as as Uncharted and put them in like three categories, and surprisingly, messages are the uh least worst understood, object and I don't want to go into details. um There is lots of discussion going on in the buug tracker and I think we should uh pick that up next slide.

G

G

Certificates are more interesting, a way more complex, compound uh structure of packets and I feel like here. It really shows that the the text lacks guidance um and again I went through the the issue, tracker and added added a lot of points and then, in the end, I added, uh like my pet peeves with it that I feel like we're not represented in the issues, um notably, the question is or like a top level question is under what C circumstances is the certificate valid and how? How does it work?

G

You know, how do you canonicalize a certificate and reason about it, and notably, um there is a matter of revocations which uh I think dkg will also talk about, um and what we think should happen is that we introduce two classes of revocations hard revocations like key material is compromised and you know no signature May ever be trusted again right, but then again there are some software revocations that could possibly be undone, but implementation is currently um handle this. You know in a variety of ways, and that makes revocation uh a brittle um mechanism.

G

Finally, on certificates, there's a point of what do you do if a certificate has multiple encryption, sub keys and there are different answers for that, but I feel like we should come up with some guidance on that next slide.

G

Please finally, signatures: um there was actually a nice essay from uh Paul uh from PG painless who, who has a long essay blog post about what he does or what he thinks should be done to uh check whether a signature is valid and it goes into some detail on. You know uh what do I have to do with the uh issuing certificate.

G

um How do I canonicalize it at which point in time and stuff and then a lot of complexity and signatures seems to re revolve around subpackets and again, there is a lots of um open issues in the issue. Tracker and again, I'll say a few things about my pet piece.

G

um There I feel like there should be more guidance about how many subpackets should um we expect and what should happen if there's more or fewer than the expected number of subpackets, and then you know there is a confusion, maybe about uh What uh sub packets, on the direct key signatures should cover. That's also issue 100 70, and notably there is a question. You know what do subkey bindings need, key flex or not, and I think they should have key flex mandatory.

G

um Likewise, the reason for revocation should be mandatory on revocation signatures um and then there's the regular expression subpacket, which is not not the favorite subpacket of our I guess that should be replaced and finally um trust signatures or the delegations they can be scoped. The the length of the chain can be restricted, but we feel like the maximum value, should mean infinite, not like 255 all right. That's uh my my presentation, I think these are open questions that the working group should.

A

Address thanks, Justice um yeah, so.

A

E

Hice um you were, you were saying that you wanted um a definite finite, parsing, depth, rn1 and then at the bottom here you're saying that uh there should be an indefinite t Sig depth. Do they not kind of pull against each other me if we're worried about exhausting resources, you.

G

Know in general.

A

Yeah yeah just.

E

Just just in general, you know, you know, is it really? You know a good idea to allow for an infinite depth of trust signatures.

G

Yeah, that's a good question: I mean um the the evaluator could still decide to constrain the the search right.

E

Yes, but then does that not become um implementation specific and then we we end up having you know things will, will you know some trust signatures will work in some circumstances and not in others.

G

um Yeah that that's a good point, we should take that offline, I, guess: okay,.

A

Thanks so just I, just added myself to the queue to ask um I mean: how would you see this kind of work being done? Is it you know a bbas document, uh or is it possible to kind of do this kind of work with separate documents, or do you think you could start with a separate document and then see how to progress from there? And what's the kind of idea about how you you? How would this kind of happen in terms of um producing outputs from the working.

G

Group, that's that's a good question. So I.

A

G

I haven't figured that out. I hope you can figure that out as a.

A

H

A

The now I guess for now, then what we I guess, what we could envisage if this, if this work was part of the charter, would be to that. You know you or somebody would write an internet draft proposing a whole bunch of fixes and then we'd have to figure out how to dispose of those in terms of updating documents or new RC's or whatever, okay yeah good. Anyone else want to join the queue to ask questions or comments on this. This set of.

A

E

Can I get a yeah Andrew go ahead? Sorry for jumping back in um there were a. There were a couple of other things um discussed on uh the list about um the semantics of signatures.

E

So maybe we could roll kind of um semantics of signatures into a a larger document and then have a uh like a semantics of signatures document that could be read alongside um the the crypto refresh, rather than being something that would replace it. Obviously, um I, don't think anybody has any appetite for.

F

A b best document.

E

I think that's probably going too.

A

A

uh Dkg I guess what what we can do is um when we get to the you we get at the end of the presentations. We can maybe ask some kind of poll questions as to whether people are keen on tackling these topics like this or any other thought on how to organize.

A

B

Aon these initiatives should have like an owner or like someone who is willing to make sure that they happen and then some people that are interested to working into this feature, let's say or into this documents as authors or contributors, and then someone who is willing to um to review so I, would split these three categories of people, owners, contributors and.

A

Reviewers sure, uh just to point out I mean that that that could be something that happens in the process of rechartering or we could recharter to enable that to be done in the working group uh under the new Charter.

A

So you know we don't necessarily have to it's nice if we know who's going to do what for sure U, but we don't have to have that a fine gra view of that necessarily yeah before rechartering, okay, okay, so I I, unless dkg objects, I think what we'll do is um get through the presentations and then ask the you know. Maybe set do some polls later on when people have seen all the presentations as to what they feel good about or what they want to argue against.

A

So I guess, if there Aron I, presume you're no longer in the queue or.

A

um Gl, okay, so I guess we we could move on to the next. Oneg is doing that now.

J

Great yeah, so for the pqc rechartering, we have proposed this um short text to cover the integration of post Quant cryptography into the open pgb protocol. As we've stated uh quite a few times already, we have a draft. The draft is uh version two it's published and we have a repository um where one anyone can make comments public comments, which already happened. So there has been a bit of discussion and yeah. Of course, our um hope is that the draft will be adopted by the working.

J

Group yeah I think there's not not to much to say because we uh multiple times we have uh talked about this topic in the working group. So if there are any questions or comments, I think it makes sense to discuss them. But from our side we don't see the need to go into the details.

B

Again, we also have running code implementations of the.

A

J

A

J

Yeah, that is true. We have also already committed code to um have code merged into um the r&p uh library, and um this is not fully not yet fully supporting the V6 code because we only implemented what we need for pqc, but yeah. We have based on r&p and Bon. We have a running code on our side and proton also has some running code. I know, but Aaron could say more uh to that of.

B

Course, an implementation in go that supports V6 and PTC in an experimental Branch. It's not deployed, uh but it it. It works with version Z. One of the draft, though.

A

Okay and then so I think there's the I think there's been pretty clear uh agreement that addressing pqc is a is, is a good topic for rechartering uh and just to just so so, I can understand.

A

There's there's some separation between um you know. Let's say wanting to address the record now: decrypt later attacks versus having a full Suite of uh including, let's say, possibly even hybrid sign schemes, um I I, I. Think the reading of this suggestion for the recharter text I assume that that means you know the working group would decide those kind of issues um during the process of let's say you know a discussion on adoption of the.

J

Draft yeah this.

A

J

Intention to keep it completely open, whatever the working group then really wants. But uh we think we should. That should be discussed in detail and uh with enough time for anyone to work into the topic and review all the use cases and the.

A

Arguments great okay, so I mean I. Think on that basis, I I I suspect this one is relatively straightforward. Anybody else want to join the cute comment on on.

A

This not seeing anyone, okay, again, we'll we'll we'll we can do some kind of polls about these topics toward later on in the meeting, um so I think thanks Falco and we can probably jump to the next.

G

Presentation, that's me again. Next slide.

G

G

So you observed that in in open pgp implementations or in the in the spec, there is only one single interchange format defined can I get the next slide. Please for exchanging certificates and keys, and that's key rings, and indeed Thunderbird and gy G can use key rings to to store their certificates and the problem with that is that it, it doesn't scale, um and that's really apparent if, if you're working with g g and have a large number of keys, it's it's really slow and there have been some improvements.

G

For example, GG has key box, um which also is still uh expensive to access and modify, and newer versions have a key demon which I think uses SQL I, um which is better, but we moved from a standard uh open uh protocol to a proprietary format. um There is an extension mechanism in the form of trust, packets and the the content of the trust packets is uh implementation defined. So it's no suitable way to to exchange information, and then there are some uh other storage uh solutions for um authentication information.

G

For example, Thunderbird has this um acceptance table in sqlite and GG has the trustb and those are also proprietary, and you can't exchange information using these mechanisms and all of that leads to poor performance and poor interoperability.

G

And if you look at x509, in contrast, there's been uh quite a bit of effort uh to change, implementations, to use a common certificate store and the the nice thing about. That is that you can expect applications to behave consistently, even if they use different implementations and I'd like to see that for open pgp next slide.

G

Please can I get the next slide.

G

Please so our proposed solution is to have a uh a storage directory inspired by Ma deer. This is what uh my certificate looks in my certificate directory. Notably there is a default location, and you can you know you don't need to synchronize if you just read it, but if you modify the store, you need to synchronize and it's indexed by primary key fingerprint, and there is an extension mechanism for building indices. For example, you need to do efficient, lookups by subkey thing, print or subkey.

G

uh Key ID, and currently our proposed uh text doesn't include that. But there is an extension mechanism and notably there is one distinguished certificate and in fact, potentially also key.

J

G

And that's the trust route and with the trust rout. You can uh take your web of trust engine and uh you know you can authenticate uh user IDs on certificates. You can add your own local pet names to certificates. Like you know, this is the key I use for mom.

G

um You can use local signatures to record Provence information and in theory you know if you can share this information, because it's all open, PTP data and you can reason about it with the V of trust calculus engine, then you can have applications using different op pgp implementations behaving consistently next slide.

G

Please so we actually have a an.

J

G

Draft, it's expired by now, but I think it's a good starting point. We have two implementations, one um implemented by Paul and it's based um on PG, painless and one is based on zya and in fact you know you have you see two links for every implementation, there's like a uh a low level and a high level interface for that and the lowlevel interface doesn't necessarily you know, depend on the PTP implementation itself and I'd like this.

G

uh This work to be adopted by the working group and I hope this will lead to better interoperability and better performance and more consistent, behavior of PTP implementations and applications built on top of that. Thank.

A

You so again yeah any questions for justice on this topic. uh Please join the queue.

C

Usus I I asked in the um text chat whether you're, willing to have the working group uh have change control over the document um like are. Are you asking? Are you proposing this that the working group would explicitely.

G

C

I think so makes sense. I mean it sounds like you there's. We have two um implementations already from folks who are active in the working group, so that seemed reasonable to me. Would you be up for proposing a little bit of text uh into uh the charter. MD over in the working group, admin, repo.

G

Yes, I can do that.

C

A

You, since no one else in the I, had a question just as on the the previous slide, I.

A

Think uh the yeah, so the just on the trust route is the is that envisaged to be something that the you know, the owner of a search store has a key PA just for doing this kind of management, or is that also envisaging, let's say, an operating system Distributing? uh You know a public trust rout along with a bunch of uh other key information or both.

G

Yeah, that's that's a good question. I mean the original intent is for the owner of the uh the store to to have a a certificate and key to issue um local certifications with the idea that you know with with the web of trust as a calculus. You can reason about that. There is no no special thing like the the trust, DB or anything um and It just fits nicely into that, and then in indeed the question is um what about like a systemwide store, or you know what about trust.

G

You know your employer Provisions a laptop, and it comes with the with the trust. Rout pre-installed I mean that's conceivable.

A

Okay, that's that's a that's a topic, for you know: consideration post adoption, that kind of thing.

G

A

Then but the current implementations do have that kind of local key pair for for individuals to manage their own stores. I guess.

J

A

A

Thanks: okay, any other questions for justice on this topic. I, don't see anyone in the.

A

Queue Jonathan was that a question for jce or are we on to the next thing.

H

No, no just just um it. It feels like this is very much about interoperability at a machine level between multiple pgp applications, rather than interoperability, between implementations on different machines. Given that it's a file structure which presumbly would have to be tarred up or the transferring between machines is different. Is that the intention that we a shared store for multiple applications on the same machine? Or do you see it as more generic than that? um Also in terms of scalability? What happens if you have a large key store?

H

It looks like you're, a flat directory, rather than any form of nested thing and I assume, there's more details in the documents about indices right because things like user ID, lookups, subkey lookups all seem to be important things to improve performance of.

G

Yes, indeed um so yeah it's about interoperability between between between programs, it's about um reducing vendor lockin and you know enabling.

G

More competition in a good way, um and indeed uh there there should be indices for you know, subkey uh handles or user IDs, and that's currently or the the current spec says it's out of scope. But there is this extension mechanism, so we hope that people will experiment with that and then specify an I, don't know an sqlite schema or something, and then we will potentially later on adopt.

H

That, okay, it it it.

G

Seems like it moves.

H

The working group into the realm of much more application, Level discussions rather than protocol level discussions I, don't think that's necessarily a bad thing, but I think it is a shift between some of the stuff we're discussing in terms of how things interoperate over the wire to you know how things should be implemented.

G

Right and in terms of scalability, so we looked at what git does um and we split off the first two hex uh digits and use that as a subdirectory index, and we we figured if it if it's scales for git, then it will probably scale for us I.

H

Think you have a typo in your slide. There you've got CB and CD, which didn't make it obvious that it was a split.

C

Height thanks, so uh just as a as a note, um maybe other folks would more iatf.

C

Experience can weigh in on this, but um I agree Jonathan that it looks like it takes it a little bit more out of the realm of sort of networked interoperability, um but open pgp is also a store and forward uh thing and and if you consider a key ring as an openpgp object, it's not entirely unreasonable to ask about how we construct these things to be interruptable within the machine or even within, like AAR ball as part of a backup or something like that.

C

um So I, don't I, don't think that it's impossible to imagine the ITF working on something like this. Although I agree with you, it would.

C

G

All right- that's also me so unfortunately, Neil cannot be here today. um So I will do my very best to present his slides, um so open pgp defines mechanism for doing authentication, notably if, if you have a key that has the certification capability, then you can use that to um create third party certifications, um which is a a signature with the same kind of syntax as The Binding signature. uh But what you do is you you bind uh or you certify a binding between a primary key and the user ID, and then there are delegation.

G

So you can mark your your certification as a trust signature, and there are are two constraints with that. You can constrain the the length of the chain that you're are willing to use to authenticate a Target binding, and then you can constrain the amount of trust um that that you're willing to um derive from this delegation.

G

And finally, there is a scoping mechanism, and currently the scoping mechanism uses regular Expressions on the on the target domain, and that's not not the nicest mechanism, but it's there, um notably. What these n does not do is to actually Define how to authenticate the user, ID and um or The Binding between a key and a user ID, and there are web of trust implementations. You know, classic pgp had one and GG has one, but while there is some documentation targeted at users, the exact semantics are um not well defined. Next slide.

G

Please and I think an interesting observation is that um open pgp is a a very expressive calculus and it you can express um a variety of ways to uh to authenticate bindings with it and when we look at x509 you have this hierarchical um way of doing things and that's actually a subset of what what open, PTP, open, ptps web of trust can do, and the most obvious use case um is: you know to incre increase security by authenticating these bindings, but a very important and often overlooked uh use case is to increase usability, um two fault actually.

G

First, um if you're doing key Discovery and you can authenticate the the key and the user ID or your target person, then you can be sure that if you send a message, the target person can uh decrypt it, or at least you didn't use the wrong key right and that's also usability aspect.

G

And second, if you have a key and it has multiple user IDs- and you can authenticate one of those, then you can show this one to the user and the reasoning behind that is that the user ID that I can authenticate is most likely also one that is most useful for me to provide context or to provide.

G

You know uh tell me who the owner is in in in my context, because I was able to authenticate it next slide, please so traditionally or what most people associate with the web of trust are key signing parties, which is it's peer-to peer. We come together, grass, throughs way of creating authent um certifications and a lot of people have made. uh You know, have tried that and failed or have seen the process fail, and so I think this is where um a lot of the better reputation comes from.

G

um But there are other ways to to do that. For example, you can try to implement a Federated way. You can have a CA in your organization, be it's small or big. um You can have huge, centralized public CA and there's precedence for that. So there's the pgp global directory, and nowadays we also have the proton CA, which is not for everyone, I think, but is for all the proton customers.

G

And finally, you can express different trust models using the web of trust calculus. For example, if you record, um when you use the certificate using local certifications, then you can Implement tofu on top of that, and likewise, if you uh record provenance information for example, if you get um a certificate via wkd, you can create a a local certification saying you know. I I got this key on on this day and you can associate a tiny bit amount of trust with with the fact that you got this key over wky next slide, please.

G

So what we like to see is to see the semantics of web of trust in open pgp, properly defined, and our preferred model is to see uh the the authentication problem as a maximum flow problem, so imagine trust being like water flowing through a network of pipes and the amount of water you can transport from from you to your target. U binding is uh the amount of trust that you're willing to put into that binding, and that leads both to a good mental model on how to reason about that right.

G

If you have two pipes or two paths through the network, then that kind of combines- and it also leads to an efficient implementation and Neil- want to ask for specifics about the implementation.

G

But in essence you, you use stra to find candidats, and then you use those to um to solve the maximum flow problem on the candidates and it's a little bit T tricky, because you need to uh honor the constraints like um scoping, regular expressions and uh the chain length, and you need to be a bit mindful about not only combining um independent um assertions, but it leads to very efficient implementation. So our implementation scales very well. We don't have a cach or anything, it's just fast enough and next slide.

G

Please we we, we have a draft, it's not submitted to the uh data tracker, but it has the it uses the same kind of templates and there are two independent implementations, one made by power from PG painless and one is uh done by Neil and we'd like to see the working group adopt our or this kind of.

G

B

A

Please join the queue if you've got specific questions or comments on.

C

This you a sort of same question as earlier um I, don't see any uh uh proposed text for the charter. Would you or Neil be willing to propose Charter text for this? You can.

G

C

To it also, since he's not here,.

G

C

Will great thank.

A

You, okay, I, don't see anyone in the queue so thanks, Justice I think dkg is next.

H

C

Hopefully, you can hear me now um I'm, going to present a bit of a grab bag of open, pgp related things that uh were due for cleanup. Some of these were already mentioned by usus in his pgb semantic slide um uh slide deck uh and I just want to point out that I have created drafts. That could be starting points for many of these I'll point to them in the specific slides. I am not in any way committed to being uh the sole author, editor or even.

F

An ongoing author.

C

Editor, if anybody else um is interested in um in in stepping up to uh take control of this I I, all of the drafts that are mentioned here, I would be happy to have under working group. Control and I would very be very uh honored to have somebody else uh take over Ed torial roles, onia, so uh without further Ado. um This is a draft about open, ptb replication, um so it started off with me trying to Define this delegated revoker mechanism.

C

uh That would be an improvement over the old revocation key um and, as I started, to outline why this was necessary. uh It grew to be a chunk of problem statement about what reputation is and why it doesn't work very well in open pgp generally. uh This draft actually tries to uh narrow the range of revocations that are possible: uh deprecating uh user, revocation of user IDs and certifications, because it appears that there are other things that can perform those effects. uh With the same, um we would only two ways to do it.

C

If you can, if you can, for instance, expire your user ID, uh then that might be sufficient, um maybe the maybe this reasoning is wrong, uh but I would be happy to have the working group at least tackle it, tackle it and and decide you know. Yes, we can do this or no, we can't do it and here's why we need to keep those things. um The goal of the draft, uh the only wire format change is this delegated Roker mechanism U, which embeds a full key.

C

uh That is a full cryptographic key, not a full open, PP certificate, um all the rest of it is either deprecation or you know, of existing pieces or uh explicit description of workflows for how a normal user would go about doing this stuff. um The goal is that it would include some death vectors for ration um and try to sort of standardize how we think about reputation in the ecosystem. um There's this other work that also was out of out of scope.

C

Prior prior to this, um which is first party, we've been calling it attestations of third party, certifications and I think we got some push back from ory, steel and others. That attestation means other things I'm trying to move in the direction of calling it approval instead of attestation. Although the first version of this draft, doesn't it still says, attested, um the basic problem this tries to solve is uh that their certificate can accumulate third party certifications and can then grow without bound.

C

That's a flooding attack it's difficult to redistribute and you would like to be able to take a um a certificate and say: okay, all the certifications that are on this have been approved by the key holder. So how do we do that? um It's a pretty well defined mechanism. There's already some implementations that produce it. I believe that the keys at open.org uh key server actually consumes it as well and will publish uh thirdparty attested. A first party uh approved third partyy certifications, um and we already have some reserved code points.

C

So I think this would be a reasonable thing uh for the to take up. We just push this out the door. We have it pretty much well defined. We've got some implementations, I think we understand what it means. We know how to do it just knock it out uh user ID conventions again. Another thing that was deemed out of scope: uh we don't all of our existing documentation, going back to rc2 2440, maybe even 1991 uh lies uh claims that the user ID is by convention.

C

Rfc 22 2822 uh May matter, um but there are lots of reasons why it isn't exactly that dumb nitpicky reasons, uh this draft exists, um I copied it out of the merge request, 23, which we've declined to include in the crypto refresh, and it basically says here's what we think the convention actually is um has a simple set of uh regular expressions in a abnf form uh for describing it uh and I think it actually has some python pseudo code U. If you want to pull from there. This seems like.

A

A reasonable thing.

C

For the community, finally, like correct uh long, longstanding misrepresentation, um this I do not have a uh uh proposed draft for um I just wanted to flag that we don't actually have a way to do a one pass: verification of an open, pgp signature uh in a pgp, mind message. um The way that we did one pass uh verification of V4 signatures is that in the um multipart my multipart signed extension.

C

We say this is the digest you're going to use, and that way, as you read the message you can do the digesting and then you can uh verify at the end, uh but now that we have assault and V6 signatures, that's not possible. um This seems analogous to the hash salt issue that we ran into with the clear Tech signing framework uh and what we resolved with that one was uh you can't do one pass verification of clear Tech signing Frameworks, because the hash salt was in conflict with other things.

C

I, don't think we'll have that constraint in pgp mind messages we could add assault, uh uh parameter to the content type for pgp, mind multipart, sign messages if we wanted to I, don't know whether it's necessary, whether people care about it. If nobody cares about it, we can just ignore it, but people want to be able to do one pass. Verification of multiart signed of pgp uh pgp, mind messages um and we need to write it down how to do it.

C

um So uh yeah I, don't know if people think that's important, uh but if they.

D

C

It would be good to have it in the charger and then finally, uh the stateless, open, pgp interface. This is an attempt to define a u an API, that programs could potentially use um and, at the very least, that defines sort of the semantics, the very high level semantics that we expect um open, pgp implementors um uh to handle um at the moment. It's very much focused on the message bits, there's key generation and revocation in it right now, um but it's mainly focused on signing verification, encryption and decryption.

C

We actually had several solid implementations, which is great. um The draft at the moment has also sprouted a new uh C library API, um in addition to the command line interface. uh The idea behind the C library API is that it's an API that should be possible to build the command line interface from um and also be something that you could uh sort of staple other language Bings on top of um the C library, is in complete. It doesn't handle encryption and decryption um and we don't have any implementations of it yet.

C

uh But it's the idea here. This is a way that we can. You know another way that we can try to think about how applications should use it. The goal of the stus interface is to be minimalist, while still providing all of the high Lev semetic. We expect people to use. um It is the basis of the interoperability test, Suite, as folks probably know, and there's a handful of proposals that are out there to extend it further. um I think there's Community interest.

C

I would love to have this be group document and not just my own. uh You know kicking it on down the road, so those are five possible implementations um and five possible things to to actually work on so I see Stephen your comment in the chat um that this is way too much work.

A

That no I don't mean I, don't mean your slides. I mean.

C

Overall, no no I I understand.

A

I mean t yeah I, think that's the next topic flow. So not this.

C

Topic um yeah, so I would be happy to hear any uh feedback on any of these uh uh pieces. If there are things that people think that the working group shouldn't work on, for instance, I see Daniel in the chat saying, does anyone do one pass processing of pgp Mind messages? I want to point out that it's actually not this pgp MIM question is not just it's not pgp. M. Generally, it's actually pgp p m multiart signed in particular a PG.

C

An encrypted pgpm message doesn't have this problem because you, the any embedded signature, can be done with a one pass signature framing within the encrypted envelope. um So you actually can do one pass signature verification for encrypted messages. It's only multi-part time. That's the.

C

Isue so I mean I would be happy to drop this and say you know you can't get there from here uh uh for mul part time. The way that we did with the clear teex signing framework, um because, as Stephen said, there is a lot of other things that we could work on um anyway. If people have any thoughts about the other pieces or this one I'm happy to hear now.

B

Er, that's so we we use it a lot and it's very useful, especially for the for interrupt test s. So it's it's one of those arguments. I have most a hard of.

C

This can you say a little bit about how you imagine stop working within within uh the working group as a working group.

B

Draft it's it's.

J

Quite difficult to.

B

Say if it would be like a living draft that we just keep on extending but never really publish it or whether we want to publish a so now and then extensions further, but I could see. um Basically it becoming part of the community work that that we do to keep open pgp.

C

Running I also don't know: process-wise um I can also Imagine um with sop uh and actually I. Have this I think in the.

C

uh I think it's in the revocation draft I have a little stub in that draft saying.

C

How would you extend stop to do this so one of the ways that I think this could be useful is, if we said, look, here's the Baseline for soop and when you define some new mechanism that provides some new semantics for open pgp, you should think about how you would extend stop to make that work um uh and again I, don't know process-wise how that fits in, uh but I think it's a it's a useful check on interesting ideas um to be able to say like okay, here's a proposal, we think it'll work.

C

Well, if we were to merge into stop here's here's what.

B

It but I would still make the so document instead of like having a billion little pieces into every standard. Saying here is how it would work into so I would rather have the authors of the open, pgp, revocation going or the authors of open, pgp, postquantum and going and saying here how I would imagine it working to S into the soft.

C

Draft makes sense to me: uh Jonathan asks. Are there any sop implementations at present that can use a hardware backed key I am not sure that there are, um but that would be an example of something that the working group could push on to say. You know: here's how you identify a hardware back key um soft has car outs for special identifiers um for things like Keys loaded from a file, descriptor um keys, loing from an environment variable. So it's not hard to imagine something like.

H

That just to provide context, um I, actually thought earlier this week about trying to implement sop as a back end for various Dean. Related flows like Dean package shining um on the bottleneck I hit was because my key is on a hardware back token, and while there are a number of implementations packaged in Debian, there is no Hardware back version. So I think that soop is a great interface.

H

I would like to generically move a bunch of Debian tooling over to it as much as possible, but there are actually missing pieces of the implementation, not in the specification, but in implementations. That means that's not possible at the minute and and just to throw in in a related way about it again.

H

Why you're saying it's supposed to support most of the common flows in pgp um in terms of uses, I think that one of the main reasons I care about pgp is the thing that should continue to exist is the web of trust and our tooling, for that is very poor, I'm, quite interested in Justice's um proposal from earlier, but perhaps not as part of salt, but perhaps a different tool. That was a common way of interacting with certifications might be worth considering as well.

A

Okay, so we got about 22 minutes left and I'm I'm, not hearing any objections. I just put in the chat, a suggestion for a poll, uh basically to kind of just get an overall reaction from the people present at the meeting to the set of things discussed today in particular to the set of things discussed today that weren't already discussed and essentially to get a sense of.

A

Should we add the new things discussed today into the pile of things already in the draft, Charter One, Way or Another, and then have to think about prioritizing um so is, is that is that, okay, as a poll DK you right with that.

C

If I can just reframe what I think you're saying I think you're asking uh are uh I have no objections to any of the proposed topics raised today.

A

Right, but without prejudice that what which you think is most important or less.

C

Important right, but what you're really saying is like you know, could do we have a a rough? Can we get look for a show of a rough consensus in the room that none of the things that were mentioned today are are unimaginable for the W grou.

A

Right so I'm I'm just going to use the text I put in the chat, um it's essentially looking for a positive sense. So if you feel positive towards the set of topics today being kind of added to the pile, that's already in the draft Charter text uh in a kind of a union operation, please raise your hand if you feel negative towards that or one particular thing. um Please click the do not raise your hand button.

A

So if you feel positive towards adding these to the pile of things to figure out how to prioritize, then raise your hand if you feel that we should not do that for whatever reason uh then, please hit the do not raise hand if you, if no opinion that then click nothing and we have 13 in the room and nine raised hands so far. We give it like a another second or two in case somebody's searching for a.

A

Mess, okay, so Daniel uh is skeptical of the one pass, processing, stuff and I I. Think that's noted. Okay, so I think we can call it there. We have. We have nine raised hands. Zero, clicked do not raise hand and uh out of 13 in the room. So that's that's a good thing to put in the notes with the.

A

Numbers: okay, so uh dkj you were going to pop up the C. Some version of the current Charter text again, given 20 minutes left now, um I think May would would it be best to try and give a quick overview of what's already in in Charter text and then ask for discussion as to how we prioritize. That seems to be the trickiest thing to.

C

Me yeah, so uh I was gonna. The way I was going to do. It was to look at uh Daniel's, uh merge, request, number three, which is sort of the most comprehensive merge request. It doesn't cover everything uh and obviously doesn't cover the stuff that um uh that us was committed to proposing text for as well U, but it actually touches basically the whole Charter I'm just sliding through it here. Hopefully, folks can see my screen share.

C

um It basically replaces the existing Charter with with new text um and enumerates a set of uh of improvements.

A

C

Mean I think that's.

A

Worth to, if we can do that quickly and then allow some discussion of Prior how to prioritize I, think that would be good.

C

Yep, so he basically saying.

A

B

Main goal: click on the three dots and then you can do view the current version. It it's going to show up much better than the diff. No.

E

B

Other you file at it's very delayed.

C

I'm sorry I, don't know which one.

B

The orig dots you clicked on and then uh there's view file ads function and that's going to be much.

C

Clear so this is the the proposed. uh This is the proposed replacement right, um so the the charter The Proposal, is that the charter becomes this um and obviously we can continue to words. Mo.

F

You're still sharing the old tab, you need to share the new tab for to see it.

D

A

Also in the in the.

F

A

Okay, that's much.

B

Clearer, can you.

A

Make a little larger.

A

Yeah, better more.

C

A

That's fine for my screen. Okay, so again we have we're down to 70 minutes. uh So, let's flick through this. We had some discussion this before: let's flick through this fairly quickly and then think about how to figure out what to do when and and so on, dkg go.

C

Ahead, okay, yep, so the main goal is working on improvements and additions to the openpgp format and ecosystem to address issues that have been identified by the community. uh It's broken down into uh some top level: sections security, improvements, new functionality, specifications of and improvements to, network-based, key Discovery mechanisms, uh key verification mechanisms and cleanup work. uh Security improvements are PQ, QC forward secrecy, domain separation for signing in or encryption uh new functionality is automatic, forwarding, persistent, symmet symmetric, Keys uh designated revoker, which might be delegated revoker um to replace applicated mechanisms.

C

Activation signatures also should fly, be appr first party approved, uh certifications, um uh superseded keys to facilitate transition between Keys the interface um and then this possible uh pgp mind thing that might get dropped, uh I haven't heard anybody speak for it yet um and then Network mechanisms um now these are all these by adopting are, for example, doesn't mean that we have to adopt them, but hkp um or wkd, or maybe we have some alternate uh network based key Discovery mechanism, um key verification mechanism.

C

Presumably the web of trust stuff would go into here um and then uh cleanup work, properly. Document user, ID inventions uh produce a number of specifications that are adjacent to the open.

C

Pgp specification and provide guidance to open, pgp libraries and applications to achieve before mentioned improvements, um and this uh the process acknowledges um uh Daniel mentions that the inext that the pgp M might be things like uh storing drafts in multiple parts, for example, um so for uh and then basically we're we're saying uh we need, uh we will work both on the mailing list and face Toof face sessions. Interim calls iotf meetings.

C

um We need uh rough consensus on the mailing list and interoperable support by at least two implementations before submitting a draft to the iesg, um and we won't even adopt an internet uh draft as working ride them unless there's two uninterested parties, uh it's not clear what uninterested parties means to me, but seems uh generally not unreasonable. uh Do folks want to comment on the proposed text here. Like is this a reasonable place to start from? It doesn't include any.

A

Prioritization so yeah, so I, I I think that close to the other set of things we discussed today that are not already. There um is a good to start from, but has a a problem in that. It's way too much work to be feasible, I think that's the that's the big problem, I think all the work presented proposed seems totally rational, uh but I, don't know how you end up finishing in the next uh 100.

A

Years, all right.

F

Please join the queue.

A

And we really would like to get input on this as to how we down select or do something. So please join the queue. If you want to talk about this and Aon go ahead,.

B

If, if I look at the things that were proposed, I, let's say like most of them, I would work on a subset of them. I would be willing to review so I basically say a voting mechanism could be by seeing who's willing to work on what and who's willing to review.

B

And basically everyone just sends an email onto the mailing list and someone just collects uh I say who, like the the working consensus and then sort by the one who has the most people, who's willing to work on them to the one who has the least people who's willing to work on.

A

Them: okay, that's a suggestion. Other thoughts on the.

C

Topic I'm also curious. If folks noticed particular dependencies between uh between topics. Daniel Daniel go.

F

Ahead so I mean some of them. There is already drafts for them right, so I think that's pretty strong evidence that people are willing to work on it. um Then the the two items under security improvements um that don't have a draft I would be willing to work on them and then the others I I try to vaguely order them in.

F

In terms of you know, my subjective uh idea on on the uh you know importance, but so you know um if it's too much stuff, we could, uh you know, got some of the end, especially the ones that there aren't drafts for right and then maybe, if, if someone is still willing to um propose a draft or write a draft, we could add them back later. I imagine um but.

A

Yeah so I guess um the existence of drafts is very good. The existence of implementation is even better. um The. Challenge, though, is if you want. If you want a draft, that's going to get finished, if you, if you have like 20 drafts uh the time to finishing any one of those, is significantly extended by having the other 19, because people don't have review Cycles um discuss you don't have you know a focus on discussions on one thing, as opposed to 20 things so.

D

I think that's a challenge.

B

Aaron question about having like 20 in the working group or a person that has 20.

A

Drafts H, so if you have you know, if you have a working group at 20 drafts, they all go much slower than if you have a working group with two drafts.

B

Yeah. Okay, that's that's! What's my present thank.

A

You I'm not hearing any inspired ideas to cut the guardian knot here so far. uh um How about okay Aron go ahead.

B

As long as we have a sorting mechanism, then we can cut wherever we wish. We say: okay, the first five and then we just do those we just chart it for those.

A

So so I think I think we can have a a broad Charter, like the current text. um I think that's quite defensible because there's a lot of things, people want to do at some point. uh I think the challenge would be to to figure out a way of prioritizing which work to do when that doesn't get you stuck with 20 drafts that are not moving forward.

A

G

So my understanding is that um we are collecting things that we like to work on, but that doesn't mean that they necessarily have to stall one AG one another right I mean they can proceed at their own pace.

A

They can but the but the the my experience is that the more drafts you have, the slower they all go. So if you know if, if we don't have a way of prioritizing that will also impact on whatever you think is the favorite thing to get done, because if there's 20 other drafts, everything slows.

A

C

I think part of the issue here is that we we've have sort of a backlog right. We had an a working group, The working group folded, um and then we had the crypto refresh and we blocked other work on the crypto refresh. But meanwhile the community kind of um came back to life here, and so what we're looking at is the result of this backlog, which is why there is so there are so many things.

A

Yeah I think that's fair and, and you know it's a good problem to have it's a it's a much worse problem to uh not have anybody want to do so. Kai suggests having a poll for each topic on the mailing list. It sounds to me, like I, think, having a having a broad, broadly scoped. Charter text is kind of right, because there's a bunch of things people are want to work on.

A

People are discovering new things they want to work on and we don't want to have the CH have to recharter every time something gets you know up up the priority list. Would it be a? Would it be possible to sort of say that the working group will only will generally only work on N topics at a given time? Where n is two or three or something, and then you know try and Stage them through that way, we could try and figure a way of approaching things that.

A

B

I, like the idea.

A

I, like the idea.

G

B

Saying? Okay: these are the topics that came up during our discussions and we will work at three at a time and that's it or four I. Don't.

A

Know so that would imply trying to poll the the mailing list for uh people's top three or top four topics from those that have been discussed so far and then working through those. As you know, as one gets towards completion going to the next.

D

Stos yeah thanks um just uh to put something into perspective, uh so uh um I'm, one of the co-authors of the pqc draft, and uh it's it's a funded BSI project, so Falco is getting paid for doing this, uh but the problem with BSI projects. Are they end at some point, so I think our project ends in one and a half years.

D

My intention is not to push you and to say put please pqc on the top of the list, but just to remind you that we have some kind of a time schedule there, and we would really like uh to support you with this project, but it would have to fit uh into this timeline.

D

um Doesn't isn't really a showstopper there, because I think I would continue work on that, uh but I guess the the work on the PC draft would slow down a little when the project ends.

A

Sure yeah yeah I'm.

D

A

Used to funding that that that terminates.

D

Yeah yeah, so uh I don't want to uh put you under pressure or push you or anything. I just wanted to uh um say that yeah.

A

Yeah no I think that's a useful input.

A

Yeah so dkg, would you be happy with the idea of having a broad like a broadly scoped bit of Charter text and then having a kind of a process where we uh in the next short, while ask for people's top three or four and then as work proceeds and continue to see? What's the next thing, people want to work.

C

On uh that makes sense to me, uh are you? Are you proposing Stephen, then that we would take, for example, the The Proposal from Daniel that we're looking at on the screen here and uh actually remove some of the specifics.

A

I'm proposing we add to we add more examples, but that everything becomes an example okay and that then we PLL the working group to see of all those things that are credible, all of which are credible. What's your top three or four and see does consensus emerge as to you know the top three or four things to start with, and then we also propose that going forward. The working group would kind of rerun that process periodically.

C

I I I think that makes sense. um We also want to ask like who's willing to be the drivers for the drafts right. It's not just everybody thinks this draft should get done, but nobody's willing to. Actually you know be the editor.

A

Yeah yeah we'd have.

C

A

Some way to ask the question sensibly, but yeah.

B

Aron yeah: this makes it hard with the Milestones. So uh if we want to put a large CH to text and then say, okay, uh we limit to work to five. We might still want to at least for some of the items say: okay, p2c. We want to work it in the next year or a year and a half and then I don't know uh forward secrecy in the next two years or.

A

So well so I I'm, not sure I, agree, I, think I think what we the priority here is to identify the things that people want to do now. That's what needs to be in the milestones and- and the dates will be fictional.

B

Okay, so basically the idea would be we Define a broadly broad, uh broad, broadly scope, uh Charter, we add into it what is going to be picked up straight away, and for that we say okay. This is this is the priority among the things that we decided to pick up now,.

A

Yes, the priority is the list of Milestones. You know eventually, when we get to when we get that that polling done. If, if a consensus emerges, Andrew.

E

Andrew yeah, um just um I I I'm, just worried that um doing something as simple as count the number of votes um for for certain things, um May block other stuff that people could be beavering away with now, I'm speaking purely on my own behalf here, um like I, would I am very willing to work on the key Discovery parts of this um and I'm I'm quite happy to work away at those in the background, while everybody else gets on with other things,.

F

E

I I I, I I, wouldn't you know I I wouldn't want to block people from doing things, if say, for example, like I, wouldn't necessarily be comfortable taking the lead on some. You know on on some of the like the postquantum algorithms, or anything like like that. So I, I I, don't think it's a case that the entire group needs to work on specific things.

E

You know we can split off into you, know individual areas and individual people can work on some things and other people can work on others as their strengths and interests lie, and then we can kind of gather up and uh uh and review later so um I I I just like to leave to leave I I wouldn't like to have something that was that's. That's really rigid in terms of sequencing. That's all I'm, saying.

A

Sure understood, yeah, I and and so just to clarify, if we're polling the working group to look. This is their consensus, for you know a credible, small or a list of topics that doesn't mean just counting votes. That's that's looking for rough consensus, um so it's a little bit different than counting votes um and secondly, it's it's for sure the case that Nothing Stops people collaborating on progressing individual work. That's documented in individual drafts that then, would be picked up formally by the working group later.

A

um So this doesn't preclude any anybody doing anything I mean we can't stop you doing stuff. um It's just a question of what can we come up with a credibly doable list of things for the working group within the next few years? That makes sense that that that, because we have so much stuff here that it's 20 years worth of work.

E

Yeah, um just Ju Ju Just quickly before let let Daniel talk um just I I, just don't want to discourage people from working on things. If it's never, you.

D

E

If they do all the work and then it.

D

Never gets reviewed.

E

That's you know, I suppose. That's, that's that's my other worry, but.

A

Sure yeah I mean okay. We could certainly put in some language about. You know that this doesn't preclude discussion of other topics related to pgp, sure yeah, Daniel.

F

Yeah, um to be honest, I think, if you ask the, if you ask everyone for their, let's say three uh favorite topics, I to be honest, I think everybody will say something different, because you know everybody has their sort of betet topics right that they're interested in and uh so do I and I think so, maybe, rather than trying to find a consensus on uh the priority and sort of the ordering in which things should be done, uh maybe we could try to make an ordering of when we think can be finished so saying like Okay, the the PQ see work is already very far along you know.

F

Maybe we can finish that by you know: X dat instead forward secrecy, there's no draft yet so you know we put fictional dates far into the future and just try to order everything that way. So that then, um like the the work of reviewing finished drafts, let's say should still be some um staggered right, not not everything at the same time, but the work of actually um working on drafts- and you know, writing text and so on could still uh go on in parallel for for all of these topics, potentially right.

A

Sure I mean I, I, I suspect, maybe I don't know. Paul is still in the meeting and if he has an opinion, but I suspect the isg might kind of. We might suffer a credibility problem with the isg. If we propose Milestones that go five or six years in future and that have 20 different topics.

F

Sure I mean I guess then we could just put only the ones that are that we think are in the near future. Right.

A

Sure, and- and we certainly when we as we pull the working group, we can make that part of the requested inputs.

C

And to clarify, uh we can change the Milestones without changing the charter right. Yes, so, as.

B

Long as you produce.

C

A set a set of new term Milestones that you know I, think that will give the area directors a better sense that we know what we're aiming.

A

For so Paul I saw you pop on the Q and then out so I don't know if you wanted to do that again. If you want to talk or not, but.

C

A

Think that, given that we have to wrap up I, so thanks for all the discussion, I think uh it's clear bunch of people want to do a bunch of things which is great.

A

um Dkg and I will try and figure out a way of polling the uh the working group to see if we can figure out some you initial list of of higher priority things to include as specific milestones for the next uh two or three years or something that's credible um and we'll send a mail to the list trying to kick that off in the next week or so.

C

Dkg uh yeah I think that makes sense.

A

Okay and um and then we'll probably we'll, probably ask people to try to respond within a couple of weeks um and then meanwhile, word smithing of the chart. The broad Charter text that goes above the set of Milestones is is kind of Welcome um and I.

C

Please don't forget to propose additional, don't forget to if you have uh committed to proposing a couple of additional example line items for the charter text. Please do that uh and if, if you have an opportunity to review the out sending merge requests that are marked ad review, please do that uh and if you want to take a look at the remaining um atata also and propose text to resolve them. That's also a welcome contribution.

C

A

Yeah, great and and again thanks everybody for for the positive discussion and for the interest in doing work and we'll try and organize so that we can uh have the working group proceed to allow people to do the they want to do and unless there's any other business I think we're out of time and the room. May, close and I think one minute. Okay,.

F

A

Other business I think we'll declare Victory and uh we'll send the notes to the list. Thank you to the not takers, thank you for everybody for participating, uh we'll, hopefully get this sorted out in in the next shsh while and uh talk to you on the mailing list. So thanks all thank.

A

Thanks uh so dkg, just before you drop I, I'm I, um we we should probably organize to have a chat. The next, maybe Monday or so. Is that suit you just to see how we can kind of.

C

That would work for me. Let me let me just pull out my account.

C

While everyone else is listening.

A

um My Monday is pretty.

C

Clear give me a second I close my calendar, trying to to straighten out the the uh weird noise I was getting on the streams got it back up.

C

Now uh Monday October.

C

2Nd um yeah I could do.

C

um You want to do the same time. I could do uh uh 14 o'clock UTC.

A

Yep that works for me.

C

Okay, I'll, send you a note with the uh imagine it for the proposed channel the chat.

A

Yeah, because those jitsy feckers require accounts now I know well, they require One account anyway yeah, but it's sucky, though you can't just make up a URL, and then you anyway.

C

D

C

I'll I'll send you a link to one that that will work uh without accounts.

A

Cool okay, great I, I'll, talk to you, then Monday. All right. Thanks, Stephen.

C

Cheers and thanks again for doing.

A

The chair, slides and stuff today that was great yep no problem.

B

A