Internet Engineering Task Force Interim Meetings, 17 Feb 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: COSE WG Interim Meeting, 2021-02-17

Description

COSE WG Interim Meeting, 2021-02-17

A

Okay, uh hello, everyone. This is cozy his dream meeting, it's an official itf meeting and I such the note will applies.

A

I believe everyone in the call is already familiar with it, but in case anyone has any questions. Please ask me or macho.

A

So this is the agenda for today, we'll start with a few updates for draft status and test charter and uh to spend the biggest chunk of time discussing x, 509. Hopefully, all the issues that we have could be resolved today, but in any case uh we would like at least to have very uh better clarity.

A

What needs to be done there.

A

Is there any bashing of this agenda.

B

Are you you're um here yeah.

B

Regarding the ayana registrations right, I provided some slides just now.

A

Okay, okay, I see two two sets of slides that have been provided. uh Yeah. That's.

A

I guess that should be fine, provided that we managed to finish with uh the x 509 discussion a little bit earlier. How much time would you need for for diana discussion and yeah in the slides.

B

I think 10 minutes is fine. It depends on what you want. We could just have it as an information point in which it goes even quicker, but okay allow some comments.

A

Okay, yeah that that sounds fine to me.

A

A

So the minutes are taken at this link.

A

I also pasted it in the chat. Please, if you have the chance to help us write the minutes, and so so in chopper we'll be taking a look, but in case anyone is using the chopper room.

A

uh Yes, please help us also see any important discussions that are happening there and yes, the meeting and attendance are recorded, uh so the in the minutes. There is uh attendees list. Please write your name there. If you are not already in the list.

A

So that's all for this site, I believe so for the document status. The changes are mostly related to the these documents. The b struct document is now in the rfc editor queue and I believe everything is also noted in the communication with ayanna. I think everything is clear. There.

A

So the next step for the cozy counter sign is for us to decide who would put the shepherd and proceed with the shepherd write-up.

A

Regarding this with matu, we were considering asking the participants for help with the shepherds right up. If anyone volunteers that would be really appreciated.

A

Yes, you can also reach to us via email- it's not necessary to do that. Now. Generally, it's not a huge amount of work, but yes, you will be.

A

You need to still follow up on the draft progress.

A

So the next point is the rechartering. I think we will need to discuss with ben how what are the next steps? From our point of view, I think we have some text that is in a good state, but is what would be the next steps, but.

C

uh Yes, so the last time that I looked at it, there was one pull request open in github that looked like it was correct. So I believe we should merge that pull request, and then I can put it into the data tracker and get the official rechartering process started.

A

Okay yeah, I will march the pull requests.

A

Yeah! That's good! Okay!

A

A

So the next point is about the x509. I saw that there are also some flights provided by uh john, so I haven't had the chance to look at them yet.

D

Use them, if you want there were some requests for slides. I'm.

A

Yeah, okay yeah! I will share them just now,.

A

A

Okay, I guess you should be seeing the new slides.

A

A

Okay, yes, there is uh the discussion around the trust, relation that is connected to the hex 5u attribute header parameter and.

A

In discussions with people, uh what I think ben summarized her in one email was that uh not having the x-5u header in the protected fields could potentially lead to some larger attack surface, and that is the main reason.

A

I guess jim thought of it this way and it sounded reasonable to me what was mentioned is that uh in the other cases we always have the certificate, uh so there is no chance to and to slap a certificate, keeping the same key, and when we use this header parameter in theory, an attacker might be able to do something like that.

A

I don't know if ben could explain it better, but that's my understanding of the reason to to mandate this parameter being in the protected header.

C

So since you mentioned me, I guess I will jump in. I don't think that I can actually convincingly explain this.

C

I think I what you described and what I said earlier is sort of a potential explanation, but I think right now we are kind of trying to reverse engineer why jim wrote this text and I almost wonder if it would be safer or better to just try to do a clean analysis of the situation from the start in terms of what the pieces of information are and how they are flowing and what needs to be protected under which circumstances and what does not, um because that would sort of catch if there are any other.

E

C

That that would need to be similarly protected, and that is probably not something we could do live during the meeting. It would need to be a more focused activity, um but that might be a good path forward. I think you know if we were to go back to the sort of try to reverse engineer this text.

C

There is some qualitative difference between what's going on in terms of um you have this third party, and I mean I think what this text says, that the person generating the cozy message does need to have a trust relationship with the party. That's hosting the referred to resource uh in terms of they will provide the correct certificate when requested, but the chain of reasoning between I need to have a trust relationship with this other party to why that specifically needs to be in the protected header bucket protected, attribute bucket.

C

That chain of reasoning is not very clear to me.

F

Ben this is russ. I think the idea is there's two ways that you could get back a certificate. That is not the one the sender intended one is the url in the message could be changed by putting it in the protected bucket. You prevent that, and the second is whatever server you're contacting with that.

F

Url could send you the wrong thing and that's why the trust relationship, because we don't have a protection against that the only way to to prevent to get that would be to put a hash in the uh parameter of the thing you're expected to get back.

C

Right- and so I guess for the threat model here and sorry to back up, thank you for for stating it like that. I think that was a point that I was going to try to make, but not as well.

C

So if we consider the threat model of, I think it was the first one you mentioned where somebody in theory could change the actual value of the url in transit.

C

If we, if the threat model requires an attacker that can do that, what else could that attacker do if we were using like the x5 bag or whatnot, and not the x5.

G

I think that's really the key thing, and I don't understand this, this connection. This is michael. I don't understand this statement at all. I think that it is equivalent to downloading the certificate, putting it in x5 bag and then what is a what occurs and the other complexity about this is what about the 6125 stuff.

G

If this is an http link that we're supposed to retrieve the certificate from how do we know whether we've done that right, um and so I would prefer not to put it in the in the protected attribute, I don't think there's any.

D

Value yeah, I think I think we need to discuss if we want to put some protect something and then what there is. It might be reason to protect identities, for example, but then it would be. I agree with russ that pushing a hash in the protected would protect would provide protection, but that would be bad for the use cases we have in ad hoc, which already put the end certificate in the external aad.

D

So then, then it would be good if this additional hash is optional, if you provide protection otherwise, but I also agree with ben that this is probably something we need to go back and have a whiteboard discussion about seems to be different agreement. Opinions.

C

uh Kirsten, I think you should go ahead.

H

Yeah, thank you um to make the life easier for the note taker, I wrote up what I'm going to say so, the the the other certificate containers we have there are there to divulge information to the recipient.

H

So it's strictly adding information that the recipient may not have at this point in time, so nothing is identified as as being in any way uh special or trusted or anything, and um so there is no consequence uh if the wrong information is being divided, except that well, the the chains won't validate, so that the whole thing is not going to to have the the intended uh effect.

H

um So um if this certificate is is intended to be validated under the same authorization policies as the other ones, I I don't understand what the special relationship is here and the other question I have is what exactly? What do we mean by protecting it? Are we talking about integrity or are we talking about for confidentiality?

H

So um I'm not sure we have even talked about confidentiality in this context, but of course there may be some confidentiality objectives here as well.

F

I'm pretty sure this was integrity, but you're you're right that it's a different kind of attribute.

H

Yeah, so so I can rephrase my question is what what objective is that integrity protection actually achieving.

I

So this is hank on my ad and what are we losing when it's in the unprotected header and therefore, if someone strips it out, do we lose anything here? That's intended to be there and it's reliably there so that sometimes the integrity domain of the signature is used to make sure that some stuff reaches the intended destination.

I

So that's not the use of it, of course, but it can be used as such, so maybe just thinking at least a cycle about what do we lose if we are, if it's stripped from the message is that bad.

D

I think one I think bill drastic larry mentioned that you need protection, I don't know what they intended. They can, but one reason why you might want to integrity, protect that is, for example, mentioning the sigma protocol is. That is the attack where somebody borrows your public key and register it with a different identity.

D

um Ces has obviously, in the past, not been always been doing proof of possession of the private key, and then someone can just strip this put in their own identity, and they call c signature would still verify.

I

Yeah, maybe that's just a security consideration, uh part of this and not the extra body or maybe a worthwhile to make an.

I

A

Okay, so as a way forward, it sounds like we would need to uh try to re-evaluate what is the types of attacks that we want to yeah. What is the security?

A

What are the security assumptions and try to understand better, whether indeed we need this or not, and I am not sure I would be able to help too much with that.

C

Yeah, so I think since john was proposing, maybe that it would be optional to put it in the protected bucket.

C

Could we ask john to try to take a look and perhaps propose text that would do that not to put you on the spot, john.

D

I I can try to provide something and try to. I guess it was. Maybe we need more discussion on this also at the itf meeting, but I can try to put in some work I'm depending on these drafts, as the normative reference in ad hoc, close as a informal reference for the seaboard certificate work, so yeah, okay,.

A

And just one point I would like us to mention- I don't know if it's being discussed before there was an email from another sdo that was looking into using this draft, so obviously they are kind of hoping to have it finished soon.

A

Of course, this does not mean we should rush this thing, just uh something to keep in mind.

I

Yeah, this is adding to that uh yeah. There are a few. I think, efforts uh that realize. Oh, this is really useful and are starting uh to uh include in in their own ids, but I don't think there is a cluster problem, yet I don't know uh so. But yes, I think I would support the notion that there is uh has been making made use of this work and we should uh see that as uh it's progressing. I I'm not rushing, not pressuring, but we should not end uh on the other side.

H

So ben do we know what iso 18013-5 uses x5u for if any.

C

I do not think that I know exactly which x-509 attributes it uses.

H

So that that might be an agenda item, an action item to to find that out. um So we better understand what how people are currently interpreting this.

C

Right, I am trying to pull up my email archive in the background and can get back to you if I have some actual details.

H

Yeah so having we actually have this. uh What would be useful? I don't know if that's actually available.

H

H

Oh it's at this stage, not after this.

H

Okay, but that's still a state that is pretty much cooked, so.

C

I think they said they're just using x5 chain.

H

H

Yeah, so um the the the question I I have in mind really is: um does providing this certificate lended any any special position, any special meaning any special authorization, in effect uh from the point of view of the uh kosi sender that that needs to be recognized by the recipient, because I think that's really the the place where we generate security problems where, where sender and receiver don't agree on the semantics to of putting some some data, some signature or something it's in a specific position, and we have to be very very clear about what that actually means that something is in x5.

H

C

My assumption is that it was just a way to retrieve a certificate that was used in gene building for the the signature of the cozy message, and there were no additional semantics.

C

In particular, you should not add the received certificate to your trust, store.

H

So essentially, the the trust relationship that that jim is talking about is one that is needed for availability, but not for the other security objectives.

C

I don't think it's just availability. I think you it's trusted to provide the same bits to everybody. Yeah.

H

But what does it.

H

Mean I mean these bits already exist in some form, so putting these bits in in indirectly in the x5u5u position, how's that different from putting them into the chain position where we also have a protected and an unprotected situation.

C

A

C

Reason I can come up with. Is that there's a third party that is potentially off the path that the cozy message itself is traversing, and so someone who is not on the path of the cozy message has an opportunity to affect the interpretation of the message.

C

But that doesn't really seem like it's strong enough to always mandate that go with a protected header. I don't know.

A

Is there a possible issue if the url is modified to start with a specific other machine like trying to open too many um ssl connections or.

A

C

I think there is some potential risk there. I don't see it as a as a very useful attack vector, but I think that is a good point to consider that when you receive a message that uses x5u, it is expected that you are going to then initiate an outbound connection to that address.

C

So that's something we need to remember and document. If we don't.

E

E

Hi this is jonathan hamill, so that that's a good point in that that could trigger like. If, if the sender or, if the receiver of the message, I guess is expecting some sort of privacy of uh if there's additional confidentiality protections that that uh that, on the message that they received, that this outbound connection trigger might inform someone that that a certain recipient has received. That.

E

A

Okay, so I guess we can for now wait for john to try to dig a little bit more into this and discuss it again during the itf meeting.

D

Yeah I can, I can try to provide some initial suggestion or explanation of the problem and uh yeah no later than the next in the idf meeting. Maybe I'll send something to the mailing list before that.

A

Wonderful, thank you.

C

I expect that if anyone else wanted to contribute to that work, it would be welcome.

D

I

uh Sorry, this is a contribution, does not mean adding new, weird ideas, but uh uh working on the current issues and editorial stuff right.

C

I think it means doing a systematic analysis of what what data flows with the various parameters yeah make sure we understand the the risks that might be protect. It might be prevented by using the protected header.

A

A

Okay, uh so john did we discuss?

A

Okay, I see one more point from your slides about the possible use of oscar instead of other protection mechanisms.

D

Yeah, this was more minor discussion points that popped up. These are not errors in the draft and it's not security problems. This would be feature changes if we change anything, but.

H

Yeah, I think really the the point of requiring tls or dtls here is that for those there is a clear understanding how you get from the text string in in the authority of of the uri to the the requirements for validating the certificate that the server provides to to the kind of communication security that that you are assuming so oscar doesn't have that defined.

H

Yet so, if, if I give an oscar implementation, something that starts with the uh corp s scroll on facebook.com, it's not quite clear what what the oscar implementation is supposed to do with that. So I don't think we can make that feature. Extension at this point in time. We might, we might be able to do that later.

D

Yeah, I think I agree.

D

Number four was raised by michael who said that he didn't want to implement pkcs7 made me at least me wonder why why it is pkcs7 in the first place, instead of ascending the same structure as in bag or chain.

H

So when people say pkcs7 here, they do need do do mean cms right we're not talking about rfd2315.

G

Yeah and and it's the cert only it's a cms structure- that's cert only! It has no content.

F

Right, it's it's! What's commonly called p7c.

A

A

Okay, so what I hear is that people believe we should not be mandating only pkcs7, but leave possibility to have other things there as well. I is is my understanding.

A

D

um I think that would be an easy, quick fix. Do that solve your problems, michael.

E

A

Could maybe any of you provide some text.

A

D

D

I can provide text if you want me to.

A

Okay, thank you.

A

D

And I don't know if we have time left this is so based on this discussion. I tried to. It was a lot of requests for what discussions about x509 drafts and also requests about tags for the sebor encoded x509 certificates.

D

So I tried to make make some text for this on on the github version.

D

And first, the defining a structure similar to x, 509 that can hold one or more certificates and then that same structure is used in bag in chain and in the uri option, and also in the keyboard tag that was requested at the last interim or on the list. I don't remember yeah, but I think the same structure could be used in all these four places and also it seems to that.

D

My understanding of jim's x509 draft is that the x5u is it's not specified that it's a chain which probably makes it a bag, but for the cbr encoded x59 certificates, the discussion with joran. We think it would be make most most sense to make the uri c5u and also the tag strictly chain chains.

D

That's the most easy to process for small iot devices. So if you have to choose one of them, shane seems like the right choice.

D

But if you don't have any direct comments, feel free to read this on github, otherwise it will, it will be. This is the current version, so this will end up in the next submitted version of the draft.

D

Unless there are some more comments on this.

E

um This is jonathan hamill. I have a comment, um so you said the formatting is uh similar to x5 bag and x5 chain, um but in the for those um components, if it's a single certificate, then it's encoded as um as a beaster where it and then, if there's multiple components, it's it's the array, whereas I think you've defined it differently. There.

D

Yes, so this is a single certificate here is defined as a sequence, so even a single certificate needs to be wrapped in an array, um and then the idea here would be that you wrap one or more certificates in a single array.

E

Okay, thank you for the clarification yeah.

D

I don't that's the most compact representation, I don't know if there is the best to implement feedback on that. This.

H

When you say wrapped in array, you're talking about the the cddl representation.

D

Yes, so the the cdl group is inserted.

H

When you look at the data on the wire, it's a naked byte string and if you have two in there, then you have a sequence of two naked byte strings right. Yes, okay, thank you. Yeah.

D

So I think it it's.

D

Definitely possible to decode it's you get a unique encoding for everything, but then the question is: if this is previously gotten questions about um how easy things are to implement, with with seaboard libraries and so on, I think that's discussion. We need to get back to.

A

Okay and do we have anything else to add here or maybe we can move to current presentation. I guess people will look at this and.

D

Yeah yep, that's fine with me.

A

Okay, so go around the floor. Is yours.

B

Thank you next slide. Please.

B

So we've had a discussion on cosy registrations in iana registrations, on, in particular, on algorithms and lifted curves, and I'd like to get some more try to summarize discussion and get some more feedback on some open points. Next slide, please.

B

So um as it's defined today, the algorithms are typically not bundled with a curve. So, for example, signature algorithm is bundled with with a hash function, but not with elliptic curve and the rfc 8152, and also the this document specifies how to handle this when new curves are are considered and there's been.

B

The reason why we're discussing is is the quest, because there is also an example of a case where it's actually defined, bundled with the curve, and we seem to agree on on the mailing list that this case is actually an exception, which was used to restrict the use of core c2 legacy case and also limit some security issues. Related to that.

B

So um we seem to agree that there is when we get new requests for new registration. We try to follow the rule about separating the algorithm from from the curve, and similarly this should apply to to ecdh, which is bundled with key derivation or keywrap, but not really the curve.

B

So any comments on this or have I understood this right.

D

For eddsa, the hash algorithm is determined by the curve.

B

B

So it's actually in this case it's it's easy. Do you say when it's when it's actually bundled with a hash function, but it's not the case that this, the signature algorithm, is bundled with a curve.

D

B

Okay, thanks for the clarification.

B

Okay, then we have an one open issue. That's the next next slide. Please.

B

That's the case: how to handle the fact of the case when we have easy groups with cofactor different from one so rfc 8152 is is not looking at that case and to handle that case. There is a need to multiply the cofactor in the helmet calculations or the shaft secret calculations to protect certain attacks, and the question is: how do we handle do?

B

We need any new registration to handle this case, and it seems that we will not need to have specific I mean for if we have, we don't want to have one registration for for each curve.

B

So we like like to do something in general, and the two candidate solutions are one is that we um we basically duplicate all the iffy helmet registrations and define uh copy of the registration, but with co-factor different than one and another solution is that we allow this the current registration to include multiple sort of co-factors different from one as well as co-factor equal to one and that could be handled by defining in the ecdh operation or the shared secret encoding.

B

How uh how to how to multiply with the cofactor that can be defined in the curve specification, so those are two candidate solutions. I've heard from this mainly in hillary's, provided input here, and some support would be good to hear if there are other other solutions and if there is any preferred solution- and there was a voice here about saying that solution 2 seems more robust, because, um basically, if you define it with with a curve, there is no way to perform the wrong ecbh operation or share secret calculation.

D

I think yeah, I think, several of curve, two five, five one, one nine and um curve four four eight already have cofactors. So I think it's not uh if a helmet with cofactors in general, it's if a helmet referring to 60 90 with cofactors, all right, good, good.

B

Yes, that's the same type of issue here so, but for those cases like, for instance, we have this case when you want to do easy. Dsa with uh with curve25519.

B

And should we define yeah so those are? These are two proposals. Any other comments on that.

C

So this is not a terribly substantive comment, but it seems potentially of an issue where, if you know the procedures for multiplying by the cofactor are somehow buried in a obscure corner of the specification for using that curve, I don't know how much of a risk there is that somebody would overlook that just assume. They know how to do ecdh and and miss that part, but that's a pretty speculative risk and I don't have any concrete thing. I can point to.

B

So what you're saying, then, is that if we introduce a specific um registration, especially a code point, would that make that less less likely.

C

I mean you might.

E

On an absolute.

C

Scale, probably not I mean I think that would be slightly different risks and it's not clearly better.

I

So those who think I can see how you you're, of course, struggling with the pro concierge ben in general, why actually yeah specify more, uh but but again, I think that is the more robust solution, too has a ring to it, and I would agree with the could that be buried so far away that people not very familiar familiar with this uh with this uh context might miss that and do that actually wrong. So then they think that's a valid cause because everybody's doing it some point and and everybody's gonna create this.

I

And it's a point and it's, I think a clear statement seems very naively from my point of view to be way more uh interesting than yeah. Well, you know it's a co-factor. It's it's been buried somewhere, um so I guess having a more clear, robust option too, but I'm not sure where the specification actually uh would happen.

I

I don't know, but I am leaning to more transparency to not being buried. So that was your initial point. That's why I'm speaking up.

C

Right, I think those are all good points and I am coming to agree that option two may be more robust.

C

um It does seem like if we do option two, then the requirement for being very upfront and clear about the cofactor is going to apply to every document that specifies a curve that has a cofactor, uh whereas option one would to some extent only need one document.

C

That needs to be very clear about what's happening, but um if I remember correctly, we do have the iona designated experts that are going to look at these things as they come in, and so we should be able to rely on the experts to remember that cofactor is a thing and request that the specification be more clear about it if needed.

B

Yes, that's that's one one point and I think yeah. I think that you could. Still I mean if this is written in one specification, you could still imagine that someone who hasn't read that particular text might make the wrong choice for the code point as as well as as algorithm here, yeah, not saying anything new, so okay, so it seems that you have a slight uh preference for for solution. Two.

B

B

Any other comments.

B

Okay, thanks next slide,.

B

B

This is just an informational point.

B

B

You can hear me.

B

Yes, yes, we can so my my I went into some sleep mode here, not not personally, my computer went in some sleep, so that's why I asked so. This is about a comment about deterministic signatures, whether that has a any impact on the code points and it's we agreed in the group that that is only recommendation, so that should not be any reason to not use the particular code point, but we should probably just change this recommendation, or that was a discussion point.

B

I just want to note that here and I don't think we have time to discuss it now. So unless there any other comments- and you don't disagree with this- let's go to the next slide.

B

um There is a request to register a curve for use with ecdsa and shake 256., which means that, following this, the principle we have discussed, we need to register ecds. We check 256..

B

I just wanted to raise this because there is no definition. Currently, it would be similar to what's done in in rfcr 8692, but this is missing any opinions on this.

C

It will be a big bike shed for what to use as the short name.

B

C

Because this is, uh you have to fix the output length of the shake as well. So this is the 512 bit output of shake 256.

B

B

Right is this something the cosy should take on as a work item? Should we or should we ask the person that wants to register the curve to fix it or, what's the so, we can review it.

B

What's the working group's opinion.

D

Where did the requests come from.

B

This is part of of this curve registration draft from from l, wig.

D

C

Yeah, I think my personal opinion is that it is something that's totally in scope for the working group to do if we want to, but it's also totally fine to just ask the group that wants it to to fix it up. So it's doing the right thing.

C

So, since no one is jumping up to say that we definitely should do this. The most expedient thing seems to be to request changes in the document from link.

E

B

Good next slide.

B

And it's the last slide, so there was also request to specify a curve with multiple key types for both ec2 and kp. Currently, the registration has only one key type per curve, and this is so. This is related to an ecdsa application. So it actually is the case that rfc on 8152 only define ecdsa in terms of ec2, at least to me, it's unclear if we can deviate from that.

B

The only case where we speak about deviation, it's basically that we can add new curves, and it's not really clear to me actually why okp is needed with cdsa, so yeah, I'm looking for input here. um First of all, whether we need it and what kind of specification we would require, and then, if this needs to be one or multiple code, points.

B

C

Since no one else is jumping in, I will say that I had started looking at this while doing my isg evaluation of the document in question, and my at least tentative conclusion is that we do need to stay true to what 8152 specified and that ecdsa has to use the ec2.

C

Point format and that we would not be able to use okp without like updating 8152 again.

B

Okay, that's a fair answer. I think.

B

Great I've got good feedback and uh I know how to progress. My evaluation of these requests.

B

C

You thank you for putting in the time to do the review.

C

H

So we have two minutes left. Do we have time to talk about the ayanna policy issue that came up on the mailing.

C

List, I don't think that's enough to jog my memory of which issue that was maybe I need more coffee. Well,.

H

The issue is that the the short labels are standards action and we we now have a document that wants to register a short label, but that's informational, and I think we we just miss the fact that that security area documents are often informational when when they are kind of creating standards, so we have a gap there. So we would have to make this document standard strict for only the reason that it wants to have a short.

C

C

I see so we we might have wanted to leave ourselves an escape clause of standards, action or isg approval, or something like that.

H

Yeah, I never understood whether not writing or isg approval is, is excluding isg approval, because in principle the isg can improve anything.

H

So um I'm wondering whether we can just get away with a variance here where we say okay, this is not a standards track document formally, but the for all intents and purposes it is um or whether we actually have to create a document that changes. The inf policy here.

C

I do not have a solid answer for you off the top of my head. I would probably have to go. Ask the rest of the isg.

H

Yeah, so we probably want to if we want to change the policy from standards action to ietf review, which I think would be the more appropriate policy.

H

Given the fact that we have information documents that need to do this, then we should need to start this document pretty soon. So we don't hold up the a wig document.

C

So I mean the l wig document is currently suffering from a procedural discuss, because the data tracker claims is going for standards track.

H

C

Guess because of this.

H

Because of exactly this issue, yes,.

C

Right but it was only last called as informational.

H

Yes, and and solving this problem here would mean that the eric document can stay informational, yeah. We.

D

Think that's right.

H

D

Yeah magnus expanded his discuss today or yesterday, to also include that elvig is not short to do any standard track documents.

H

Yeah another reason not to try to do this. I.

D

I would be positive, I think, let's give renee his informal draft and if we can fix the short registration some other way quickly. I think that would be positive. Instead of forcing this drop to be standard track right, further yeah, I.

C

C

Okay, well, I will take an action item to figure out. If there is a well, I guess figure out what our options are for getting a shortcut point for this.

I

I

A

Okay, well with that, I guess our time is up. So thanks a lot for all the participation and useful discussions, and I hope to see you at the itf meeting.

H

I

I