Internet Engineering Task Force Interim Meetings, 26 Aug 2020

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: COSE WG Interim Meeting, 2020-08-26

Description

COSE WG Interim Meeting, 2020-08-26

A

So welcome everybody to uh the first first series of interims uh after ietf108. This is just to clarify this. Is the cozy working group not drip, not ace, not core.

A

This is still an interim, so we do have a note well, um as as we would for other itf meetings. So please please, uh please take that into account um for administrative stuff, so we have blue sheets. We put a special section in the minutes. If you could um add your name there we'll make sure that we we include that in the um in the meeting materials after the session, we did not arrange for any um scribing or note taking ahead of time um it at least taking a glance at the job per room.

A

It's a subset of everybody in the meeting. So I don't know if there's value in the jabber is anybody willing to help with um notes? The biggest thing we're concerned about is: um is action, items.

A

Thank you francesca again. Okay,.

A

And um so for the agenda that we have put up, um it's really to talk about uh we're going to do a very quick recap on where we're at with existing counter signatures, and then jim will walk us through both the documents and what the uh and a little bit on the counter signature proposal and then um we'll go over a wrap up for this session.

A

Is there any changes desired to this agenda.

A

All right I'll take that as no so, for recap, really quick. um So what we have today for counter signatures, is we protect a couple of things.

A

Which works out fine for a couple of our structures, but doesn't actually do a counter signature for most of them. What we really want is something that does act as a counter signature rather than a parallel. Signature is what we've got today.

A

So there's jim has pushed out an email going over uh one possible approach um that we can go into some more depth, um but also to recap from our last meeting- and we had at least mentioned that put this on the list is we definitely want to fix the problem?

A

um There was a strong consensus to deprecate the old one and define a new algorithm and to be as inclusive as possible, which was at least from uh the sign. There was better support for that, but it was still kind of weak virtually. um I think what we're going to next talk about um well before I move on is: are there any questions on this so far?.

A

Okay, so we will now switch to gem.

A

Let me know we want to change.

B

B

Choose your own venture that this is. This is a a story: format that appeared in the 70s that may or may not have made it out of the u.s next slide.

B

B

Decision that we really need to make is, are we doing one document or multiple documents? I've pushed up a one document version that has the new the proposed new v2 counter signature proposal in it. So what's up, there is, is kind of what I would envision. A one document version to look like um arguments for doing one document is, is having a single document means you find everything.

B

But the time to get to full standard is going to be potentially substantially slower. I don't know what we consider to be a little bit slower. I mean in some respects, 18 months in the ietf is, is not very long, which is what I'm guessing is. Is the sort of time delay we're looking at to get the full standard?

B

If we have multiple documents, then the base document can move forward. Much earlier is going to be easier to focus on the question of counter signature support in terms of moving just a separate counter signature document to full standard.

B

I'm a little bit worried about what level of interop we're going to have.

B

If we're saying what we want to do is future proofing, because it's kind of hard to test the algorithm which is future proofing without have for that producing a future document, a future cozy structure to actually run the tests on, um and even if we do, one dot document, we can still basically do a single std number.

B

So I went back and actually re-listened to the the last ietf meeting um from the people who just who, who expressed opinions.

B

Most of them seem to be in favor of doing a single document.

B

uh I am weakly in favor of doing separate documents.

B

So I guess the first question is: do people want to express opinions about what we should, how we should do this, and one of the questions is: do we do? Is the default a single document if we don't get, if we can't make a decision.

C

I have a question yeah, you said 18 months. Is that a reasonable guess of what delay would be um if we went with one document.

B

um I think so, if we go with one document, we're gonna have to pull the structure document back into the working group.

B

My guess is, is we won't be ready to? Is we won't be ready to do a working group last call before the middle to end of october? We do that. Then we go to the all right we go to the ad. Then we do an I an ietf y last call.

B

Then we do a go through the iesg.

B

At that point, I think we're looking at march in order to get into the rfc editor queue um after that we're looking at probably at it. I believe that it's currently six months to get out of the rfc editor queue, but that is, it should be decreasing at at this point, because they've gotten through most of the big backlog, um so we're basically looking at a new rfc, comes out a proposed standard next july, and then it's six months to a year after that, before we can move the document to full standard.

C

C

I I don't have a strong opinion. um Obviously, yes,.

D

Jim, I thought that some of the 18 months was because, if we have a year um to where we have to before, we can uh advance.

B

Yes, that is correct.

D

Okay, so so it's not.

B

All that's the period for that's the period from july 2021 to july 2022.

D

Right so that that's that that's because we've added or changed things, if we don't, we only subtract things and we can count our previous experience.

B

Yes, if we only subtract things, we can be in the rsc editor queue by the end of september.

D

B

And, and that would be, and that and that document go to full standard.

B

A

Any other any other opinions or questions from anybody.

A

Okay, um well speaking for myself, this is matthew miller. I I also have a preference for um for two documents um again, partly because we we know what the shape of what we've got minus the counter signatures, and I think it would be. I think it would be beneficial for us to take to take the the time on that without pausing everything else.

C

Would you then have a reference to this new document in a struct document.

B

No, I would not want a normative reference.

C

No not a normative, because that would slow things down. Obviously, but um because.

E

C

Were saying that they they, like? I agree with that that it's good to have uh to be able to find that document from the existing cozy. One.

B

Yeah, I mean part of what would be in the the pared down document would be a description of why we removed the counter signature and an informative reference to the new counter signature document.

C

Okay yeah, so there will be a reference to that.

B

Yeah, I don't think that's a problem for going to full standard.

C

And I I saw in the mailing list, there was some one possibility was to keep the counter signature and then have a counter signature too.

E

C

B

Yeah that that's the next slide: okay, okay, sorry, no problems.

B

So I'm not I'm not hearing a strong preference either direction.

A

F

A

C

So do we know who would be affected by this change because of core and groupon's core is not affected. I checked a doc and it's not affected because they don't use counter signature with cozy, sign and uh mac.

C

If I'm not. Okay,.

B

Well, counters our oscar group oscar would be affected only in that.

B

It would end up having to point to the std dock. It would end up having to keep the point here right now to 8152 for what is doing for well either. That will point to the new counter signature document for its counter signatures.

B

So it would basically have to match.

C

B

C

C

But we also expect this to be done. Probably before the old score, I mean that that's not a problem.

B

Yeah I expect I expect that that we should be able to get this new document out of the working group towards the end of the year.

B

C

B

Be able to reference it yeah.

C

And then what would be the plan, and uh so that would be proposed standard and then do the whole process again or.

B

We'll just do the whole process on that. One document.

C

On one document.

B

Yeah, so we basically at some point in the future would say: yes, we have implementation experience on the counter signed document and then go through and and push it to full standard, and it would end up with the same standard number. So the the standard xxx would have two documents in it.

C

I I think that most people have a strong opinion, because, as long as you can find this uh counter signature new uh new counter signature from the current document, it doesn't really matter where it is as long as you can find it. Of course, if you don't reference it or then it, then it's a different story.

B

B

Okay chairs: how do we go about wording, a request to the mail list for what we do.

A

um So I think what we'll want since, since it really is nothing here, uh there's no there's no consensus here and there's at least of those that have commented on the list, there's no consensus there. um I think what would want to do is phrase a couple of um questions. Oh uh jonathan, you have a question.

E

Yeah, uh yes, can you hear me yes uh just to clarify um so if you're gonna go to multiple documents, that would be removing section five from the current draft. Is that right, the version two counter signatures, or am I wrong on that.

B

The version one and version two counter signatures will both be removed.

E

Okay, thank you for the clarification.

A

And that's referencing the latest. um The latest struct draft that jim uh published on monday correct.

A

Yeah I mean compared to 8152 will be it would be removing that section. It would effectively be removing that section from 8152.

A

So I think what we can do for chairs is we can we can work on a we can work on a question or a set of quests a couple of questions um just looking for strong objections from there.

A

um I think the question to me. If nobody else then to the document author is, um I mean you're the author, we're we're leaving a little bit of the trust on structuring here up to you. If we don't get a clear signal, um you jim had indicated a slight preference for two documents: would that be an okay, better state, then to you or a default state.

B

That would be an acceptable default state. Okay,.

A

So we'll make sure we make that clear in a statement to the working group, um but we'll be asking whether and we'll be laying out these arguments here um and I think what will be more important. Is that we'll need to do some uncharacter uncarrick uncharacteristic prodding of the working group to try to get some some responses.

B

I'd also like to see a reasonably fast deadline on the question sure.

A

um My thinking, my personal thinking right now is, is give give people a.

B

Week yeah I mean if, if we have the answer by labor day, I'm happy, I think that's right.

D

Yes, um I think that jim should pick a preference and uh then we should ask for objections to that that uh that direction. I don't think it's useful to ask the working group again. What do they prefer.

A

Okay, that's fair, um I think jim's already made it. I think jim's made it clear that his preference is for two. um We could certainly ask that way and see about um requiring like if anybody has subjections.

A

Please please speak now or accept the fate.

A

A

um Given that jim, should we move to slide five, I.

B

B

Okay, so the next question is: what do we want to do with counter sign version? One.

B

Do do we put. It is main text in the new document. Do we put his appendix in the new document, or do we just leave it behind in 8152, because it's deprecated and say it's deprecated, I have a I. I have a preference to do the last one because I think it makes more sense not to continue to document just just to document. Basically, what would what we're doing and to say if you want to know what the old one did you go? Look there.

C

Jim did barry say during the meeting that doing so would um stop it from going to internet stand.

C

B

Document from progress, adding new stuff stops it from going to internet standard full standard.

D

We tried x, it didn't work, we're not standardizing it.

B

And, and what we're talking about here is a new counter sign document, not the not not the the structure.

C

B

The document the document we're talking about on this slide is the new document to be written. That says, this is how you do counter signatures in cozy.

C

B

Okay, that's going to document the version 2 counter signature, the question is: does it document the version? One counter signature as well and explicitly say, is deprecated or do we just say it is deprecated and if you want the details, go look at 81.52.

C

That would be my preference to leave behind option three, but then again we don't use it. So I think people who have implemented it and use it.

C

um Would have more more weight on this decision.

B

Well, the number of people who have implemented it and use it and are going to end up carrying should be relatively small.

F

So my understanding is that the option you uh into prefer is uh to I mean: do we do this? A small comment in the.

F

8150 to this document and say that we deprecated it because of this and that and go to the uh a before 8152 document, or we just just completed this section and have that reference. Only in the new document that will be.

B

Written both documents are going to refer to the old counter. Signature and say is that essay is deprecated.

F

Okay, that sounds good to me speaking as individual.

A

um This is matthew miller. Again uh speaking for myself, I I think I said I think I I said this on the list myself. I would prefer at most what we do is we say it's deprecated and here are the reasons why and go look at rfc 8152. If you really still want to implement that.

B

B

Okay, so in and among the people who have spoken so far, I don't know that michael's spoken yet I'm hearing that that leaving it behind is the preferred answer.

A

F

E

Hearing this is jonathan. I also agree with leaving it behind.

B

Okay, so that's question two: to go into the chair's mail um with the default again being leave it behind.

A

I think what we'll what we'll do is similar to the other one. um We will phrase this as there. There was consensus in the meeting to leave it behind. If there are any strong objections, speak them now and we'll give it another. um I think this one we can also give another um one week: deadline.

B

Right, okay slide: four: what was slide four here. We go.

C

So, okay never mind. I think it's in this slide go ahead. Jim.

B

So the next question is: we've defined structure, names.

B

And the structure of a counter signature in terms of what the cddl looks like does not change whether it's a v1 or v2 counter signature.

B

But do we want to produce a new name so that people who refer to the cddl is obvious which one they want to pick up.

C

I would say yes, new name.

B

B

Currently, in the document there's a standalone tag, cbor tag which is being defined for the v1. I don't see any reason to define a standalone tag for v1. We should just define it for v2 um and I don't know if there's anybody.

B

I think that I think that's an uncontroversial statement.

C

D

um If some community from the uh av, uh um the the rabbit uh automotive society, turns out to have been using the old code and really needs a tag, they could just ask for one, I think, is correct. Yeah yeah.

A

Speaking for myself, I agree, I don't think provisioning. One now is worthwhile.

F

Okay, anyone awesome why we would want to have the same name for this structure or so far, I'm hearing that we want to have different names and have only the attack for the big version.

C

If people do implement the deprecated version, uh that's lasts.

C

That's less of a problem, obviously,.

B

Yeah, I mean it's mostly a documentation question at this point, because.

B

At least in the base document, we don't actually have a real cddl because we don't use cdadl.

B

Certainly we could reference cddl into v1 and and define an entire module, but it's, I think, it's six and one and a half dozen, the other, because I don't expect people to be referencing.

B

I don't expect people to be referencing the counter sign thing without having the tag.

B

But I don't know that that's true.

C

I need to check what structure looks like real, quick.

B

It looks exactly like a cozy signature and point of fact is defined as cozy counter signature is equal to cozy signature.

C

Okay, so we're also giving a new label then.

B

The question yeah: do we basically define it, 8152 actually didn't define a label. Anderson I'd have to actually.

C

Go look that that's what I was wondering. I thought it.

C

C

Yeah there is a counter signature text string context string. It's called. I always forget.

B

Well, there's a context string, but there's not a cdddl.

C

C

But I was wondering about this context: string. Oh the.

B

Context string will be different.

C

Okay. Okay, sorry, that's the.

B

Result the context string will be different if we well. Okay, I'll do I'll go in that in the next presentation. It's easier to talk about there. Okay,.

C

B

Okay, I don't think either these issues need to go to the list.

B

um I think that this is, we basically just have authors, discretion and people can complain that they don't like it.

A

I I absolutely agree with that.

C

If this is only about the name, I don't care which one it is really because the counter signature doesn't have a ctdl right now. So it's not that confusing. So whatever you choose, gems is fine.

B

Okay, so let's go ahead and jump to the counter signature algorithm right next slide.

B

So what I put in and proposed is basically the the last line in the counter signature on the right side. So we add basically add an array containing all of the additional.

B

Binary strings that we want to include in the counter signature.

B

The context string is currently defined as its counter sign if that field is absent and counter sign v2. If that field is present, that means that.

B

The code for oscoregroup.com does not change, and it does not change in any way.

B

You'll also notice that I put in the the the tag on additional line. Three and the algorithm is, is going to be defined as to say we don't take it pick it up. If it's, if it's a tag to be stir, we only pick it up if it's a beaster.

B

So does anybody object to using the array at that point as opposed to just adding them one by one.

C

And that would be in the the sig structure right when you, what what is on this right hand, side.

B

The right hand.

C

B

That the right hand side is the 2b signed structure. Okay,.

C

C

No sounds good.

F

Jim, can you tell us what is the advantage of having the array here? Maybe that will also help.

B

um Well, there's two advantages to having the array. uh The first is. It makes my code easier, which is neither here nor there.

B

The second is I wanted to, as I put the array in there, so that there was no no possible question about the number of b strings that are in the in the 2b sign data.

B

I didn't want to have a potential issue where additional line one if additional line one is present but protected attributes of the counter signature is not present that you could potentially produce the same to be science string.

B

Putting the array in there makes it very explicit that that's not possible.

F

F

B

Okay, for now, I'm just going to continue with this particular structure. If people object on the list, they can object on the list.

A

Agreed I was, I was about to say that I mean I think we can, when you have an initial version, they they can start objecting right.

B

uh So the next next slide.

B

This is a more interesting question which is: do we want to define that the tag which says ignore ignore this field in the cozy signature.

B

um This is kind of a different tag than what is you currently used in cbor, because this tag is basically an ignore me when you're doing processing into a data model, but I need to be there for potential application processing.

B

So it's it's a tank, which is it's the only tag that I know which basically says, I'm not saying anything about. What is what what what the data is, which is tagged, it's a little bit different in terms of what it is.

B

um If we define the tag, then we have the full algorithm, but it also means that, in order to go to full standard, we may want to say that we need two implementations that implement the tag behavior and we don't have any coat in any base. Cozy structures that we could define that behavior to so we'd have to make up one for the purposes of testing.

D

So is the purpose says essentially this this data is mutable. Is that this.

B

Point right: this data is mutable.

D

And we don't actually have any examples where we need that yet, but we want to future proof ourselves in this. Okay, precisely.

D

I think if we define this tag um and we have counter signature unit users, I think they will go. Oh that's interesting. um I it may be that this is a an anti-pattern in design to have to require it and maybe no one will use it and when we try to go to standard we'll deprecate, it.

B

That's always possible.

B

And then, maybe after at some point in the future, we'll find out that oops we really don't want it.

C

Yeah, it might also be possible to not not uh like register it, but that just give an intuition that this is possible and if someone needs it at some point, you know they still can get the oh. This is interesting and want to register it later if they need.

B

Yes, um and and I'm kind of going back and forth between doing the registration or just or not doing the registration but describe how it would work, I don't have a strong opinion either way. I mean if.

C

If it was needed already, then the choice will be simple.

C

B

And carson says tags are cheap, so it's it's easy enough to get it.

C

What it depends.

B

C

What range right.

B

Well, that's the other question is what range do we want this in.

E

What would it mean if this tag was on uh something that was actually required.

E

I I yeah, I guess it only applies to b string, but it's just thinking like if it was on another structure like the original signature.

B

ah That would be not legal.

B

If it was on the original signature, it would not be a legal signature structure.

E

It just seems to add a bunch of edge cases.

B

Yes, it adds a bunch of edge cases that we don't know how to do that. We don't have any reason to deal with yet I will agree with that.

A

So matthew miller, speaking for myself, I am thinking about this. I really struggle with the use case here. um I don't have enough experience with smi and cms to know how valuable something like that might have been, then that has never come up with jose. I question how valuable this is.

B

A

I mean my my my personal feelings here is: we've already got a number of points where additional values can be placed and understood semantics as far as how they apply to the um to the protection of of this envelope. So I I mean, having space, for other things, to show up to me seems.

A

Right for problems.

B

Not having it will also make it easier to progress.

A

I mean it doesn't have the side effect that we're now expecting these structures to effectively. You know they're they're effectively set in stone, but I don't think that's a problem.

B

A

B

Think we would define new structures if they weren't set. If, if we needed to make changes right, I mean I know my code is very explicit about going through and saying. This is exactly what it must look like and if it doesn't look like that, I'm going to throw it out.

B

B

So I think what I've heard here is basically a non-normative, descriptive process. Paragraph about this is one way to solve. The problem is the correct way to go.

A

If it comes up yeah, I think that sounds correct.

B

Or maybe it's actually. This is how we think we would solve the problem and you can deal with it. We can actually deal with it at the time. It shows up.

A

I personally prefer.

A

That any other comments from the from those.

B

Presents okay, that's everything. I have okay.

A

Yeah- and that was basically everything um the chairs had, I mean for wrap up.

A

For the wrap up of this meeting, um one question is: if there's still value for another meeting, I think that comes down to jim. If, um if two weeks is enough time for you to have um document, changes or dot, you know initial documents.

B

um Yeah I mean that the changes for the structure document is is actually relatively simple and and the new counter signature document is a based operation.

A

Okay, um so I think.

B

The the the thing I would the thing that I would like to try to get nailed down in the next meeting is bin's. Discuss.

B

A

Okay, which of his discusses on the struct document or.

B

On this document, okay, um he has a discuss which basically says I don't know if we have enough knowledge about message: recovery, signature, algorithms to to have the description of them in the document.

A

Okay, um all right now that seems reasonable and we chairs will try to uh cajole ben into attending the next one. We uh if we can.

A

A

And then, to recap: we have: the working group chairs will have a couple of questions. We will send this as one um one email to list. I think that's reasonable, but we have the um from the meeting. There is rough consensus to have a single to have two documents: uh rfc 8152 best struct and a new document for the v2 counter signatures.

A

Are there any objections and then the second question is um with a two document structure. uh We are the third there's some rough consensus to leave. Actually this is a little bit, at least for the media. It's slightly better than rough um leave, v1 behind in 8152 and any discussion of v1 is that it is deprecated and go see the original document for the implementation.

A

Are there any objections.

A

And we will have this out um I'll chat with everyone. I will chat after this, but I think we can have this out by the end of my day today in the u.s, with a deadline of one week.

A

Right, um we still have 10 minutes left. Is there anything else we want to try to discuss now or give everybody everybody back. 10 minutes.

B

Do you want to talk about charter.

A

um Those that have asked about charter the most are not present in this meeting, so I'd prefer not to.

C

A

Yes, september 9th same time,.

A

And we currently have one more meeting scheduled. We can either cancel that or we can use that to to nail down rechartering.

A

So um that sound alright to everybody present yep.

C

A

All right: well, uh thank you, everybody for for attending. We um we'll get these questions out to the list as soon as we can we'll get the minutes put up, um and once we have the recording we'll make sure we'll link that too.

A

If there's nothing else, um please, before departing double check that your name is listed, um it looks like it to me, so I think we're good. um Thank you. Everybody we'll uh chat on the list and in two weeks.