Internet Engineering Task Force Interim Meetings, 5 Oct 2022

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF-CBOR-20221005-1400

Description

CBOR meeting session at IETF
2022/10/05 1400

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

A

Foreign and we've hit the top of the hour, but we only have a couple of participants and Karsten is not on yet so we're going to wait. A few minutes.

A

A

Okay, well now we have Karsten, but it's still just Karsten Marco and Russ.

A

I'll give it till five after the hour and then we'll start.

B

I'm actually also seeing IRA and the code.

A

Yeah, hello, everyone, yeah, yeah, I, it's the problem with uh can I just see Ira that I didn't. Oh there's her card yeah, it's the problem with the sort that I did and not noticing the ones that say participant. Okay. Well, then, that's a that's enough. People let's get started um so welcome to the uh the seabor interim call and there's one item on the agenda. It's Carstens it's to talk about coordination with sedate and issues with the time tag document uh Carson go for it.

A

Your slides should be ready to share. Let's see, Grant.

B

Okay, here we are um I, actually have an uh any other business uh item at the end which we might quickly want to discuss. um So the this should be short.

B

um We have been talking about the Civil term, take for for a couple of years already, and it has been the working group draft and for a while. We haven't really done very much with it, because we were waiting for the seedage working group to define the internet extended date, time format, which is essentially RFC c39, with the addition of hints.

B

So the the green stuff on this slide is a hint that can be added to the RFC 3239 timestamp, that is on the on the left side in white, and here we have a time zone hint which says which time zone this is meant to be in and an extension suffix.

B

That indicates this is best shown in the Hebrew calendar, which is uh well it's the example because it's the only such extension suffix that is currently defined and in the previous version of of the time tag document we added map, Keys, -10 and -11 to have time zone hints and extension suffixes.

B

So we were kind of prepared, and what has now happened is that the city bring group things they are done, um and um so um now we we suddenly had to do our homework, because there were a few DVDs in the documents too to release that I think all have pretty obvious resolutions. But of course we have to look at whether I think and I did this in the right way by the way, Hank is apologizes again because he has this uh standing conflict with the uh even weak meetings at this time slot.

B

So um we had to fill in some Ayana considerations. We had to put in some clarifications about durations I, didn't prepare slides on these, but I. Think if you care about durations, you may want to to read the the additional text that that is trying to clarify uh them and, of course we copied update over from the sedate uh changes to their a b and F, because the ABN F essentially governs what what keys 10 and 11 can can point to.

B

So the the intention is that time tag02 is, is ready to go.

B

um Of course. What what sedate is doing at this point is alerting a wider group of people uh about uh one thing they have been doing, uh which was uh actually updating three to three nine, because there is an interability um issue uh if that update goes through.

B

Of course, it ripples through a lot of documents that are using 3339 but I think the the actual practice should be closer to to what uh the result of the update will be then to what what is before the update, so I I see see the the message that went out to art at edf.org to the seaball working group. So you so you know this is uh going on and so far we we just had one request for for information.

B

So let's see how how that is going so um just cleaning up things on on our side. Ariana considerations, um time scales, are an obvious extension points. We currently only have Tai and UDC um in the document, which are the obvious ones that you want to have uh and additional time scales like GPS or NGP um can be accommodated by by just uh converting them into Tai and UDC. So time scales that have a well-defined conversion, such as a constant offset um GPS, is just 19 seconds different from from Tai.

B

So there's really no point in supporting that for interchange, you should be using gai then so these should not be registered, and the policy here is is a combination of expert review and RFC required. So Roc required is probably the the right thing for for something that is as Grave as adding a time scale.

B

It's not iotf review it's RFC required, so people can actually do something like do an irtf document for a new time scale or even an independent submission, but that's the reason why we want to add expert review to that as well. So we cannot just have a random independent submission defining time skates. That then turn out not to be interoperated, so um I think uh commented that maybe we should add ut1 um as well, so ut1 is essentially the smooth version of UTC or the the target to which UTC adjusts itself using leap seconds.

B

This is, of course, interesting to everybody who actually points into the sky or looks into the the sky.

B

um So it's pretty popular with astronomical astronomers, but these astronomers also have some other time scales and I'm, not exactly an expert on these things.

B

So I I was a bit hesitant, adding UT one, but maybe we should at some point have a uh document called sibo in space that does all these these space specific things that that have turned up in the context of sibo and where we get some some experts who actually understand what what uh how ut1 is defined in such a way that we can actually reference this as a standards uh based time scale.

B

So we can always register this later. So I don't see a big problem with sticking with gai and and UTC, but we we could add time scales that people really have applications for.

B

So that's the time scale. Registry. The map key registry, is pretty obvious. It's pre-filled with the map keys that are defined in in the spec in in the time tag uh draft and the policy for additional registrations will be specification required, which also includes expert review, but does this by definition of the term um and there's also an uh request to the expert reviewers to curate?

B

The good code code points, so somebody shouldn't go ahead and and get a million code points um just uh for for some, some very, very limited coverage project, and then we we don't have compact hold points for uh the time to take anymore.

B

So this this was not entirely trivial. uh The during the Ina conservations, but I think it also is uh pretty clear that the general direction is the uh right one. Any comments on this slide.

B

Good, um we had the discussion about floating time and the floating times the time that that is.

B

Bound to something like a time zone or a time offset uh from the time scale only by local context. So if I tell somebody we, we will meet tomorrow morning at 8.. That is a floating time, because this communication only makes sense if we have common contexts that identifies which time zone I I mean by eight.

B

um So these are often useful and we actually have tag 100, which is based on uh floating times, um but it when discussing this. We notice that that the MTP working group is also looking at floating times, and the assumption is that we want to do this in a way that is compatible with what ntp will come up with, but it will take another year so a year and a half for that to converge, so this probably should be added later.

B

um So that would be my recommendation for Issue Number Four. It won't fix um Issue, Number Eight actually came up after we submitted the show two, uh because there is an inconsistency right now in the document.

B

um The document has negative map Keys, which are ignorable information items, and it has unsigned ones, non-negative ones that are critical and the the status so far was that the only critical, critical piece of information was the base time. So only one key could ever be unsigned the base time key, which could be a different one for five, depending on the representation of the base time, but there could only be one of them and now it turns out.

B

We have critical informations or information that must be understood by the consumer of the tag, and it makes sense to use enzymed non-negative keys for those. So essentially the the um obvious or straightforward fix for this is to limit this. Only one key restriction to the base, time keys um and then, of course, we need to know whether he is the best time key or not. But since all the critical keys are the ones that that their consumer is supposed to know to process the document.

B

The specification of the critical key can include the information whether that actually delivers base time or uh some. Some additional information, like these internet extended daytime format, the keys tenant, 11., so I think that's also pretty straightforward.

B

And finally um one thing that came up. We have a pretty good set of of uh map keys that describe time in more detail which are essentially uh stolen from PDP from IEEE 1588, not directly, but through their Zhang model of uh through the email that the IDF has created for 1588., and that is pretty pretty useful because we can replace some some ad hoc stuff with that.

B

However, there is one piece of information that currently cannot be expressed, and that is whether the timestamp is is a planned or computed timestamp or an actual time, and that may be important because time scales are not entirely predictable if they were entirely predicted or we wouldn't need, several of them would just use one. So we we know how Tai and UTC relate to each other for the past, um but we don't know it for the future, at least the future more than a few months ahead because of leap seconds.

B

So a planned time that is uh uh defined in terms of the UTC time scale may be moving relative to the Tai time scale, which means that you cannot really Translate UTC plan time into a Tai plant type, while in actual time is one that that already has happened.

B

So you know the time scale characteristics actually that there are some details here with uh realizations of time scales which mean that you may not actually know this immediately, but at least at some point you, you know when exactly that was, and so they can be reliably translated between time scales.

B

So all this stuff is is really only of interest to people who care of uh accuracy down to a second or less um so for most applications. You can completely ignore this, but for for applications that need this uh and uh Yes. Actually, even some security applications want to know when something happened uh very precisely.

B

um There may be uh maybe useful to add a flag for this distinction, so my current uh view of this feature is uh we. We definitely want to have that, but we may want to wait until we have talked to enough uh time not to understand whether we actually want to add more information to this than just the flag between planned and actual times. So since these keys can be registered by by anyone. It's it's not hard to end that so here again my a recommendation would be one fix.

B

So with that said, we are now entering this discussion, uh which happens on several mailing lists. The art mailing is the C date, mailing list, ntp and Tick Tock uh have been addressed and, of course, the the sibo uh mailing list. So within the next two weeks we might get some some additional uh issues, some additional information, some additional editorial corrections as well, um so my assumption would be. uh We should be able to have a digital three uh ready for working class call um before ietf 115 uh at rb4 October 24th.

B

um So if we do a working class call immediately, uh we might have completed that at itf115 and should be able to to process the working plus call comments at 115., IRA.

C

C

A question about the flag for Planned time versus actual time functionally. It makes good sense to me, but how do we know that the originator sets the flag correctly and doesn't it have really bad side effects if they set it to plan, but it is actual because we can't translate well. This would raise this flag is more dangerous than not than not addressing the issue.

B

Well, it would be an optional uh flag, so that would only be provided by uh producers uh that actually care about this issue and for those producers. Yes, you would hope that they have made up their mind of what they put there.

C

Right and not done a hard uh Coating in their code like most implements. That's what I'm concerned about that. Somebody had that thinking. Oh I should add this lag and then fixes the value such that it uh it diminishes. The utility of the flag.

B

Yeah, so the the recommendation and the view forward should be to not add this flag unless you know what you're doing um and I think that that's a good point um but uh yeah for those that do know what they are doing, uh it's useful to be able to express this.

C

Yeah I understand I gather that I I guess we need. We need a strong recommendation to be careful not to add the flag unless you really know what you're doing and need to do distinguish planning time.

B

Yeah, so in the financial Community, for instance, uh you would, um um if you know a particular.

B

Base rate adjustment will be announced by by the feds in in January 15th at a particular point in time. You know that this is a plan time that has fixed to UTC. So if somebody adds a leap seconds at the end of this year, you know that that leap second will be considered when making that type.

C

I see that was a good example too. Perhaps an example in the spec you know of a a use, a practical application of plan, time.

B

B

Okay, any comments on what I said and the plan I'm proposing here.

A

C

I, yes, it's a good plan and I think moving for working group last fall soon and trying to process it at uh 1. 15 would be a fine idea because, as you say, it's been floating around for a couple of years and it would be nice to have closure and sedate would be pleased too, as I'm sure foreign.

B

From people now that that this needs to become an RFC before they can integrate that into their SEO application standards, so indeed we will. We should finish this up.

A

Okay, I guess we finished that agenda item last call for comments on that now all right Carson. What's your uh aob.

B

Well, the the aoster pointer to a discussion that is happening in the Cozy working group right now, which I think is, is relatively typical about discussions that we will see uh when when sibo is used in a field that has uh previous ad hoc data structures and the the discussion in the Cozy working group is about the new hpke key exchange.

B

And that is a slightly weird document, because it defines abstract forms of components going into and coming out of this key exchange, um but there's also an expectation that hpke gets to set the representation of these data, for instance, actual keys uh in particular asymmetric uh keys, and we know that asymmetric Keys have had a very, very different representations over time, Complicated by the fact that some of these representations used to have patent claims on them.

B

um So it's really a complicated area and um I I was very surprised to read um message uh on the course and mailing list that apparently the the result of the discussion was not to use the the Cozy way of representing cheese but use the hpke way which, as I said, is, is not really fully defined. At this point, um one of the things that that we did when we uh defined cozy was trying to get rid of of uh 20 30 years old baggage um and weird key representations and come up with key representations.

B

That would be easy to process on constrained devices. So I just wanted to to point to this discussion, because there may be more people that actually have an opinion on this. That, then, is currently visible on the medicine Russ.

D

uh So thank you, um Karsten for raising this topic, but I think that the um characterization of the discussion is incomplete. On one hand, people want to use the same cozy structures for public keys. That's the approach you who just articulated and supported.

D

On the other hand, people want to use hpke libraries without modification uh and that modification would be to change the encoding um from whatever that Library uses to the cosay one um I believe the discussion is over and that the people who want to use the unmodified libraries one and as a result of that I, have withdrawn my name as author from that document.

B

Yeah, I must admit: I haven't followed the the whole discussion. um So maybe that's my fault not to have looked at this, um but um yeah in the ITF. We try to do the right thing and then not uh stick to decisions that are wrong. Unless we we have a deployed base that uses the result of these decisions.

B

um So I'm I'm not entirely sure that that the fact that the discussion is over means that we cannot have this discussion now so that that's why I'm, bringing this up I really don't understand what it means to use an hpk Library representation uh Because. Unless that is standardized, uh that doesn't mean anything.

D

Well, in the um the E spec the place where that appears is opaque, and um so that that's really the thrust of the argument is: do you have to convert the opaque thing into a cozy key or not, and because the the hpke interface basically treats that as a internal thing? That is not need to be standardized, and anyway, I I think that that's going in the wrong direction, as I already said, is that's the reason for my uh stepping away from that document.

B

Okay, so so raising uh attention here to this item is about all we can do here, but I think that this is a major change in the the underlying principles of how cozy operates. What should be worked on by the Cozy people, of course, but I'm not sure that um this is being curated uh in in the right way. Right now, anyway, we will need to discuss this in in the Cozy environment.

A

Okay, Carson thanks for bringing that up.

C

Today, but um are we going to talk about cddl 2.0 at 19 or not.

B

Well, I think so. um I have managed to to get the drafts out before this interim and the next one is on the 19th.

B

um So there is still little opportunity, a window of opportunity for me to do that and yeah I'm still optimistic.

B

But yes, we should discuss this in 115.

C

Okay, um cddl2, of course, has much interest uh far beyond the ITF ly, and my two cents on the Cozy and hybrid public key is merely to observe that the NSA has come down strongly against hybrid public key inside NSA 2.0, and this doesn't be supporting it as much. So. I um also really dislike the idea that doesn't matter that it's opaque in some hybrid Public, Library, neurode Posey and for things derived from closing of which are far more than.

B

C

Of us, foreign.

A

Okay, yes, we um Christian and I do need to put together the agenda for the 1 15 session, um so we'll be posting something to the list soon about that anything else from anyone. Ira.

D

Even if I also do be careful that I think your definition of hybrid that you just used and the definition of hybrid in the hpke spec are two different things.

C

um Well, it was actual staff of NSA on other lists, not in the ITF recently expressing uh lack of uh interest in specifically hpk. He has defined in the RFC 9180 that.

D

I would okay all right because they've also come out and spoke against what could be called composite, but yeah just want to make sure you were right, yeah. Well, it is.

C

Again, I agree: hpk has uh as many meanings as there are people talking or maybe a few more um and and that's that is another problem, um uh composite versus and so on.

C

With respect to cddl 2.0 Carson I would suggest that we still want to talk about it at 1 15 in slide, where, if not in specs, um that we um want to um encourage the larger ITF and out of ITF community that we're taking seriously moving on with cddl 2.0, because there's certainly a lot of perceived need for many uh places.

B

A

Okay, anything else.

A

All right, Marco, thanks again for great notes, really appreciate that and um we'll have another one of these in two weeks thanks everyone for coming.

B