Internet Engineering Task Force 110, 12 Mar 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: IETF110-COSE-20210312-1430

Description

COSE meeting session at IETF110
2021/03/12 1430

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

A

I haven't heard you guys say anything: your mics work.

B

Okay, do you hear me now.

A

No mine doesn't.

B

Okay, well, maybe we can slowly get started.

B

I don't know if matthew has joined yet so let's maybe give him a minute more and if not, we can start.

B

Okay, well, I guess we can get started so hello, everyone, my name is petrov, and this is the cozy meeting of this virtual idea meeting, and this is an official idf meeting and as such the not well applies.

B

Please read it carefully before participating in any discussions, and if you have any questions, don't hesitate to reach out to me or any of the other chairs.

B

This meeting is also recorded and the presence will be taken and this will happen automatically. So no action is required from your site.

B

And this is our agenda for today we will first have a few updates for drafts.

B

We'll present you our new chair and then we'll move on to some discussion that has been partially happening happening on the mailing list surrounding the draft had a certificate for encoding and ayana registration policies.

B

Is there any passion of this agenda.

C

Hi, um yes, I have a proposal for the any other business if we could have a few minutes just to discuss the need for defining a cosy header map for raw public keys, which, as far as I understand there, is nothing defined yet and that that could be useful. uh For example, in in lake.

B

Okay well yeah. Let's try to have that and, and that sounds good to.

B

B

B

So the minutes will be taken here. Please help with the taking of the minutes.

B

I know me and michael would be taking a look there, but probably someone uh helping out there will be really helpful. Are there any.

B

B

B

Wow christian, would it be possible to like take action items uh make sure that they're in the minutes? I think everything else should be perfectly fine handled by us.

B

Okay, thank you. Okay and yes, jabber. uh I will be looking at it as well. So, of course, if you observe that we have missed anything, please speak up, but, and that should also be.

B

Handled on the chair, changing side, um matthew miller, who has been co-sharing with me so far, will be stepping down as quasi chair, and we are pleased to welcome michael jones to replace him.

B

So I would personally like to thank much of our oh. His help and thank mike for uh taking this opportunity to help with the cause. Sharing might do want to say a few words.

A

Sure thank you for the introduction and thank you to ben and the ads for inviting me to have this opportunity to serve the working group and the itf in this way. uh I'm sure many of you know me. I have been involved in this working group and others this one.

A

Since its inception, I was one of the people who read the original drafts in uh excruciating, detail and provided feedback to jim, and what have you and I've also done two algorithms drafts for cose, as well as helping other groups like the w3c web auth and use the cozy algorithm identifiers.

A

Many of you probably know me because I was one of the primary editors of the jose specs in jason, as well as working in oauth and open id connect. I've produced something like two dozen rfcs with uh many of you, but this is the first time I've been an ietf chair, so I'm looking forward to both uh helping with progress and learning some things along the way so look forward to working with you. Thank you very much.

D

Yes- and I just wanted to jump in and cater because the aed to say thank you to mike as well for stepping into this role. You have a lot of experience with jose and cozy and the itf and standards groups in general, so it will be great to be able to benefit from your experience. Thanks.

B

Again, yes, thank you and now, with the status update, we have now a good number of rfcs that are in rfc editor queue, so hopefully we should have them finished very soon.

B

We have our new charter up for discussion by the isg uh like almost two weeks from now, so we are looking forward for any feedback on that and.

B

We have the quasi counter sign document that is uh still in the working group and michael richardson is preparing the shepherd's write-up so that we can move it forward. There have been a question should it update rfc 8152 or the base struct.

B

I think that was discussed in the mailing list and some conclusion was already reached, but uh if you have some other thoughts on that and you want to discuss it now, please raise your hand.

B

I'll take that as a no so moving along. So.

B

An extra administrative question would be to discuss in the future interim meetings. Do we want to have them or not?

B

uh My personal opinion is that they have been quite useful in the past, so it could make sense to continue with them, but we wanted to hear the working group's.

B

B

Okay, I see some support in jabber for continuing so with that. I think it's time for john and.

B

X509 points that were still nice for discussion.

E

Yeah, thank you.

A

For this, what cadence would people like to have the interim.

A

A

What frequency have they been held in the past and is that what we want to do going forward.

F

They were too not frequent enough, but it really depends on whether we have active discussion going on in the draft. So I would expect in the next uh couple of months we will still talk a lot about the zebra city, civil encoded certificates.

F

So I think we will need more frequent interims and when that has left the working group, we probably can reduce the frequency again a little bit.

B

A

So michael says in the chat that every two weeks was good for him, but too frequent for others.

A

Kirsten what do you think.

F

Good those other speak up.

E

Maybe every month.

A

Hannah seems to support every month.

A

De facto, uh two interims between itfs is about once a month per what ben was saying.

A

Michael points out that every four weeks is easier to schedule than every month.

C

Yeah, if I may jump into around scandal, I think I just agree with kirsten saying that it really depends on on whether people have time to progress the work, uh how how much we need. I think it's a good idea to have uh at least one interim, perhaps two before the next itf.

B

Okay, so it sounds like we want to have at least two three interim so once per month, more or less uh one option is to schedule them like every two weeks and then just cancel some of them. If we see that we don't have enough progress or something like that, maybe we can discuss it also in the mailing list in the interest of them.

B

But yes, then they want to say something.

D

Yes, I think we have some some good input from people and hopefully the chairs can make a concrete proposal about. You know having two interims uh before 111 about once every month and we can get confirmation on the list that that's going to work for most people.

A

I agree: let's proceed that way. Thank you, ben thanks all right on to our presenter.

E

Thank you uh so this is. I got an action point to try to summarize the discussion here on the github issues, the discussion on the list and the discussion uh on the last interim and try to make a pr out of that. So this only talks about this pr and the pr I can take next slide.

E

The pr it tries to address four different issues on github 21, 30, 31 and 33.

E

See and the pull request is number 35. This try to address this based on the discussion on the list. Next slide.

E

So the main solution here was the solution uh suggested by russ to use x5 t, together with the other parameters, to make it secure.

E

I tried to make a pr based on this and the other comments and the main goal for the pr was to not change any currently secure, implementations or deployments, but to make everything secure and also try to fulfill the different use cases. People had um so to summarize.

E

The pr added that you need to.

E

Integrate protection of the end entity certificate is required unless the ca did proof of procession, then, later to today, lawrence pointed out that this is not enough, and that there's also the use case when the ca gives out several certificates for the same key.

E

So the pr definitely needs to be updated, um then added that integrity protection, as I said, can be added by adding using x5t together with other headers, uh add in a one sentence. Explanation that x5 bag and x5 chain in unprotected allows an intermediate to remove old.

E

Other clarification that x5t refers to an end entity certificate added media type, application c board for koci x509. It was a comment by carsten stating that if we do this, it should be a more explicit media type. So something like application goes to x5.

E

And then, if you do end the entity protection of the certificate, I think then you end up with that. You don't need any requirements for protection of the uri and then I added security considerations based on integrity, protection, which is quite separate but discussed in the same thing and then why integrity protection of the entity certificate needs is needed for proof of possession. That would then be need to be updated. Based on warrants comments.

E

uh Next slide, we can look through the different changes.

E

uh So these are security considerations.

E

Quite simple, these need would need to be updated based on they. They need to be updated, based on lawrence um suggestion that this is not enough. There is other reasons why you need to predict the entities that get as well.

E

I think we can as long as there's no comment, we I think we can just move on next slide.

B

I just comment here: we are adding a reference to a talk.

B

Whether this is something we want to do I mean here it's not like explicitly referenced, but I guess we will need to somehow say what this thing is. uh So maybe we need to have an informative reference if we keep the text like that, whether this is something we want to do, maybe maybe not just a.

E

Comment, yes, I think the if we are that it should be an informative reference. It might also be enough that saying that you, it you can yeah, might not even be needed. A explicit reference either can talk about things in general terms. Also.

E

Next, so here's the text added that I suggested to add to x5 bag. So the first sentence is an addition of this adding or removing certificates.

E

uh Intermediate certain gets that's requested by michael and then it's text stating that unless you know that these certificates were issued in a secure way, you need to and integrate to protect the end entity certificate.

E

And then it lists ways that this can be done, for example, by using the putting the header in the protected header or using x5 bag in unprotected with x5t in protected or by including the end entity certificate in the external aad.

E

That is, for example, used by edward and the proof of possession text here would clearly need to be updated and then the question now is not only proof of possession, but also the same key in several certificates. Do we want to have this flexibility, or is it cleaner to go for mass integrity.

G

John, a question uh since you raised this question: uh what are the main use cases um like in in general that may answer some of the the questions whether you need this or that.

E

um What do you mean? It was very similar unspecified question. I don't understand what you mean with this or that.

G

um Like the document is uh includes like, for example, the um the document specifies the number of ways to pass x, 500 x, 509 certificates for different types around, um such as the one that you show on the on on the screen with the bag of certificate, and so it depends a little bit on what you what use case you are trying to cover on whether um all of those things are needed, because one of the problems I had with cosi was like it's a it's a laundry list of things, and then nobody implements the laundry list uh and then it's it turns out that it's often incomplete uh ill-specified and so on.

G

So I'm curious like what are the use cases we start with, and my next question would then be: are you uh implementing them to see whether the description is actually matches reality than in in terms of code.

E

I think I'm the wrong person to ask here: I've not written this document, um I'm only providing this pr that fixes these four issues, but maybe somebody else can answer.

E

If we have time it seems to like a much more general open question on the whole document.

B

Okay, thanks khan uh current. Do you still want to say something or.

C

Yeah I mean john had a question about how we should formulate uh the statement here, whether we should go for proof of possession or make it a make a must requirement instead for for integrity protection, and I think that that would simplify things to go for a must.

C

uh This becomes very complicated to for anyone to to comply with. So that's that's one comment.

C

Then we had a discussion on the previous slide on the mentioning of uh examples here and in this slide there is also mentioning of of ad hoc here's a protocol, and I I think that this is motivated here, because it's an example of how cosy is being used in a security protocol uh which is not the I mean which is not the case for the previous slide.

C

Where there's, basically I mean it, doesn't have to be used within within the protocol, so that that would be a reason why you would actually give the example with external aad as a clarification. I think that aligns a little bit with harnesses is missing explanations here, so I think that should be kept in the in the slide. Five.

E

um Okay, next slide is chain, it's extreme. It's exactly the same thing as bag.

E

Except that it says chain instead of bag, so I think we can move on and the example up here illustrates how you send chain in unprotected and x5 t in protected. Of course, you can also send both of them protected um next slide.

E

So here is x5t. I added text to clarify this is an end entity certificate. It was a comment on about that on the list or in the issue tracker and then similar text, but not exactly the same as for bag and chain, and proof of I think here it seems like we are leaning towards. Having must integrity predict uh yeah, and then we have sunny and protected head there or included in the external aad and then a backward reference to bag and chain um click. Next.

E

So x five you here we had comments from michael that he did not want to implement pkcs7.

E

uh So I added here a c board. There was a comment from carriston that this was to general and we should have something else: maybe cozy x, 509 chain or something if we agree that this should be a chain.

E

So yeah agreement on the chat or alignment on must seems like.

E

um Any comment on using application keyboard- I guess I assume people are fine with that and make it more specified. Okay next and let's do some commenting.

E

So here is similar text for x5 us bag and chain um similar here you first is similar. If you need to integrate protect this, and you can do that by x, with x5t or with external aad, as it's done in analog, then we end up with the now. We can don't always need this uri protection.

E

In fact, I think if we go for, must we don't need this uri protection at all, maybe except if you want to transfer new trust anchors, uh but here in this text it's now divided into two sections one. If, if it is integrity protected, then the uri does not need any protection, and if it's not integrity protected, then you need the same protection as you had in the old version where you need, for example, https on the.

E

Ui yeah discussion, media type on the list.

E

It's good can go to the next slide.

E

Yeah, I think that's just the summary. um Any high level, I think, seems no objection to this seems like we people so far positive on the list we go for must need to explain the security consideration based on lawrence comment. It's not the only proof of possession and then a more specific media type.

E

People agree that that's the way to.

D

Go hi. This is ben. Yes, I think we should have a more specific in the.

E

Chat if you're cutting up- I guess you said more specific media type.

D

Yes, there is good support for that in the chat.

F

F

In the chat, I think we just said that we don't want to mention an ad hoc uh in the text, because you would have to add a reference, and that is a bit late uh in the process. So we should be using more general terms than specifically referencing network.

C

And then I I responded to that and said that uh for the in in order to illustrate how the external aed is used, that that that would be one reason to keep it. But otherwise we could rewrite that part as well. But that would mean we need to change the part which is specifically mentioning how external aed is used.

F

B

G

I record in the vr like adrock being mentioned five times, uh sounds to me a little bit overselling. I think I understand, but I understand the motivation but yeah.

E

I think it's more or less the same text stupid four times.

E

I think it's more or less two times mentioned in two different sentences: one with tls and dtls as a way to providing identity protection and one as an example of a protocol that use courses, external aad,.

G

Yeah, I think I think it should be independent of those protocols, whatever the next favorite thing uh is and- and there would be like there's new stuff uh already developed being developed now, so that this would be there would be a continuing list of protocols being used in that context. So.

C

So I I think it's a good, I I don't mind leaving out specific protocols, but I think we should explain that the value of putting the certificate in external aad providing integrity protection. I think that's that's what the message that we shouldn't leave out.

E

I think erdog can be definitely be removed from the body of the text. I think in the security consideration. It might make more sense to give examples such as tls or red oak or opposite.

G

Yeah, I agree with girl describe more the property rather than specific instantiations.

E

So we should remove tls, also.

G

Yes and ipsec as well.

F

G

B

Okay, are there any other comments on this draft.

B

Well, thank you, john and thanks. Everyone for the discussion.

B

So next I think johnny, that's zebra encoding.

E

Yeah, so we have see we have 25 minutes left. I think this can be quite short and we can leave things for the next interim. How much time do you need your um for the ayanna and your other business?

E

You need ten minutes or five five minutes each yeah, that's fine good yeah, so uh seaborn encoding of x509 certificates.

E

So I think one of the big changes are actually the the name was discussion on the list and I think we we agreed on cbr encoded x509. We have added the abbreviation c509 in this draft.

E

There's not been much discussion on the list for that, so I don't think you can say that there's consensus about, but that's the current uh working assumption feel free to comment. If you want that to change.

E

uh So, yes, the overview for people that has not been on the interim, this has expanded. It was initially a short small profile of 7925. Then the comments have been that we have shifted to cover quite much of 5280 and do very little profiling. So this is an an encoding of 528, zero or large part or it the things that make sense for iot cover 7925 the new tls1.3 iot profile, they're very similar, but might be some changes. I triple e.

E

We will add an example certificate for that, and then we are trying to cover the ca browser forum baseline.

E

Yes and they're called c509 certificates and we also make registration, so the certificates can be used in code c and tls.

E

G

Question in in some sense, um I was wondering how this relates to uh another document. I have been co-authoring uh which defines how to use cwds in dls, because in some sense, um what you want is is kind of the the functionality of a cwd rather than a plane cosy. Or am I getting this wrong.

E

So this is not uh these c509 certificates are not cozy, uh they are, they are. The document contains two different types. I think they're called types one is compressed x509 their encoded certificate, so you can use it as a compression mechanism, but it registering tls as a certificate type.

E

The other type is uh a seaborg, a natively sign c c509 that give it get, and the only changes between them is that in the one type the signature is over there and in the other type, the signature is over seabor, but so far, there's no two c in either of them.

G

Okay, I missed.

E

G

um Because, uh like then, the draft name was compressed uh uh compressed x549 certificates right and that's how you initially sort of advertised it in it. The feature it offers is, obviously you can use an existing x549 certificate and, as the name says it like does the compression on the wire, the downside. That's has its beauty um and but then the downside is obviously you need to now.

G

Have the implementation x y for nine uh passes and and libraries, as well as the cozy, uh the the seabor, uh slash cosi, libraries, and you know like at some point in time. You changed that scope, but but still made have the same in the same document. Is that.

E

I think natalie sign was in the original document. Also, um I think the name has. The draft name is still compressed. We will change that as soon as we are working group adopted and changed it to seabor encoding.

E

The word compressed is gone from the from the draft body of the draft itself and based on discussion in the working group. We have changed from registering a tls compression algorithms tls certificate type.

E

My plan is to go to t after this is working group adopted uh yeah or if it is, which I hope it will be and look like it is. Then I will go to tls working group again and ask what the tls working group thinks about this and if they they, if they want this, and if they think it's the right choice and if they think this should be done, in course, or if we should write the tls document doing that registration.

G

E

G

I always um like we had a discussion in dls earlier on this and there you advertised it as a uh you, only put an emphasis on the the compression feature, not on the native uh sibo feature. So that's why I was confused.

E

Yeah, I think it was has been discussion in cosi, whether that would be standardized or not, and now we have ended up that because it should standardize natively sign. There has been where I think most of the interests have been related in comparison to cvt. I would say that cvt might be more flexible and new and that this c509 certificates are with like profiling and content is just a different encoding of x 509.

E

So there's there's nothing new. It's a large subset of x 509 with a much more efficient encoding.

G

And- and I remember that, I asked you whether you implemented the document, and you pointed out that yeah we implemented the compression, but did you then implement the other part as well.

E

uh No, we have only implemented compression and working on that, and that is soon done. My plan is still to release the the compression as open source, maybe till summer, okay cool. I am not I some point in time. I hope to implement the inverse also, but that has not been done and will not be done for a while.

C

E

So next slide next slide, so not going to any earlier. These changes were discussed from 0 3 2 0 6 was discussed on earlier interim links to these presentations are here. If you want to see them next slide.

E

So these are the changes from zero six to zero. Eight.

E

Some moving information in the draft you're under this change, but it's uh naturally, science certificates is definitely there. So there's some restructuring of sections name change with carson, michael ponto. You should not call this seaboard certificate, so the new is c509 certificates which is combination of cbor and x509.

E

Then there is quite some changes to the header parameters, bag chain tag and uri based on the x509 discussion. uh These are, I think these need further updates. I stopped updating after and planned to wait until the x 509 discussion is finalized, that's more urgent and should be the basis for the seaboard certificates.

E

uh Based on the discussion. We there was a request to add a tag, and if you want and based on that, I created we created a new structure called cc5, which is an array containing one or more seaboard certificates and the same board, certificates or sequences. You can just add them after each other inside an array, uh and then there is a tag I think we have and then from zero, eight zero, seven to eight.

E

It was just formatting changes, thanks carsten, for making a pr to remove these annoying long lines, which I apologize for next slide.

E

uh So a lot of open issues, I think some of them are very minor and someone and just reminder we'll go through some of them as much of their time. We just have to wait for an entering.

E

Some of these can probably be closed also.

E

E

So I think we can go to next slide immediately and start discussing issue.

E

So first this says new issue. Here I think nobody has. I don't think we have done an issue on github yet, but this was after reading. uh The tls iot profile in utah and the discussion in sec dispatch seems to be a lot of discussion of moving more information to to subject alt name. I think the tls profile changes what is going into subject adult name compared to the tls 1.2 version. So the question is more. I think we support everything.

E

The question is: should we change what we optimize for in the subject of name fields, thomas.

G

Yeah I uh rich had in his document he talks about the server side, server, authentication and for the web, and the reference utah document talks about client authentication for iot devices. So um the question to me is whether the use of sans on on the web for servers should also imply that we should use the same for iot environments for client sides or whether his proposal actually also applies to client certificates in sort of, let's say app.

G

Smart app, environment or wherever tls is.

G

Used yeah, I, what do you think.

B

um We have two more minutes for this presentation. Do you think we should move this to the main, at least? Maybe I think.

E

We need- I don't know what should be done, but I think this, the seaboard certificate draft will mostly look at as we have discussed before. This document should not do much profiling. This will look at what other documents do and try to optimize the encoding for that.

E

So I think we yeah, I think we should maybe cut here. I think it was great input from harness it's good to have some discussion with people that has not been in the working loop for a while an active until us.

E

I think we need to discuss the rest of the issues at interim.

B

Okay, so it sounds like we can switch to here again.

B

Okay, the floor is yours,.

C

Thanks, okay, so this is a about jana registration or some guidance requested from the working group next slide. Please.

C

So there is someone whistling in the background: it's very nice, a bit unfamiliar sound though um I'm uh we have in the current cosi ayana register. Only.

C

uh Okay, please mute.

H

Hi this is plane whitley. I think you are the only unmuted person next to me, so I don't know where this is coming from.

C

um Okay, so maybe.

C

Maybe there is something wrong with the setup.

C

ah Thank you for confirming that you actually hear it ben. I thought it was in my head so good that someone else hears it as well.

C

C

I'll I'll try to just talk see if it works anyway. So what I'm? uh What I'm aiming at here is that the it's really distracting what this um cozy currently doesn't define just encryption without mac and and uh there are authenticated uh encryption and authenticate encryption with additional data, and that's also explained uh or clarified in the uh content. Encryption algorithm section, which is uh giving the uh the restriction to only use authentication uh authenticated encryption with additional data.

C

But there are settings where additional, where only encryption would be needed and we'll take that in the next slide.

C

Please so there is first of all this request from from fido alliance, registering just encryption: algorithms, there is cipher block chaining and as encounter mode, and it's not really clear from the specification, because it's it's mentioning both uh encrypt and mac and mac, then encrypt. So it's not really clear exactly what they intend to use it with, but one instance which is presented is cosencrypt: zero, wrapped in a cosi, max zero.

C

uh So this is actually a second request for so so, and the motivation is there to support legacy hardware and this actually, the second request from fido uh to register legacy. Algorithms previous requests resulted in uh in an rfc uh which is authored by our new working group chair.

C

So we are familiar to this situation and this might be the the same type of request might be uh going back from from itf to to actually make a registration to explain how they are going to securely use encrypt with with cosy mac, um and then I just want to point out that this is not the only next slide. Please. No, it's not the only use of encryption, only so encryption without mac. There are two other examples, uh so, for example, in in ad hoc in message two, uh it's only by the security proof.

C

It's only required to do encryption without integrity and in this case it's using stream cipher, but it could just as well have been using cosy with an encryption without mac, but that's not specified. So we can't use that for freedom so that that- and that might be others sit in the same situation where they would like to use cosy with an encrypt, but it's not specified, and the third example is groupos core, where we currently, which is, which is about group communication, and there is a signature for source authentication.

C

So currently we use it within within cosi, encrypt with an aad and a signature, which means that we have both a mac and a signature, and that is too much overhead or we can. We can reduce the overhead by removing the mac without changing the security properties.

C

So that's basically what I wanted to say. We can go back to the previous slide and discuss the specific request from fido, but I think that um the general question to the working group is are: are we fine with actually registering encryption algorithms without without mac uh in if they, if that's also? There is also a supplementary specification uh explaining how how this is used securely with security considerations.

C

Any objections to this.

B

C

I hear none okay,.

D

um It does seem like this is uh something that we should probably allocate code points for, uh especially because cos a is sort of more of a framework than an actual protocol. We don't have a great reason to limit what people can build using our toolbox.

D

uh The question that I have is more of whether we want to uh change the structure of the registry, to have it more prominent that there is a warning label that applies to this mechanism or if we think that the existing uh required be in their specification or if we have a description that could say something. If that's enough.

C

We have the recommendation, column sort of recommended which could be either. I think it could be yes, no or deprecated.

C

If I remember correctly, I don't know if we want to if we are so if it's sufficient with no in this case or if we want to say something more.

D

I think that's a question to everybody, not just for me.

C

A

So this is mike speaking just as an individual. I will note that the jose registry has some things registered as being prohibited and we could add to the kosei algorithms registry that categorization as well so, for instance, sha1, is registered as an algorithm. Its use is prohibited, but there were legacy reasons to be able to reference that as an algorithm. I believe that came from w3c web crypto, so I'm perfectly good. Adding code points I will say that uh recommended versus not recommended is not strong enough. We already also have deprecated.

A

I think, if we're going to do this for some of the legacy stuff, we should add prohibited as a categorization to the cozy registry. Just like there is in the jose registry.

C

So question for you mike: would that be the same column as recommended or a separate column.

A

Same column, just increase the number of values.

C

Okay, fine by me any other comments.

C

Okay, um so yeah ben is proposing adjectives here.

C

um Perhaps we could? What do you could we move this to the list? Try to agree on on how to handle that and then we respond to fighter alliances as described here.

C

uh Do we have a minute for the any other business.

C

G

Okay, what what do you mean.

B

What do you mean by.

G

We decide on how we respond to fido alliance. What do you mean by that? So so I.

C

G

The request on behalf of the fido alliance right.

C

Could we take this offline? Honest we only have a minute left. Is that okay, sure thank you.

C

Okay, so is it okay without you to speak about republic keys for a.

I

C

So there is no slight exactly thank you, okay, so just quickly, thank you very much for for giving the opportunity to bring this up um in the last minute. So it's it has been requested from from several uh several parties that we need to define raw public key, a cozy header map for raw public key. uh It is, for example, it's a it's a requirement by the lake working group and it might be used in other uh in other settings as well.

C

So, and the question I wanted to raise here is apparently I already got some comments on the on the jabber is if we need a separate specification for that and what how how we should handle that in in relation to things like uh bob moscowitz mentioned the 7250, which is um not the most efficient representation, but it's sort of we can have the analog representation using the tbs certificate data structure to the to be signed certificate data structure in c509, which also provides public key identity and an identifier but no signature.

C

So any any quick comments on that. What people think about should we define it as a sep, uh an analog way as rfc 7250, or should we just define it as a another um cyborg another cozy header map.

E

Cool c key is maybe the word you're looking for.

C

Right sorry, yes,.

C

So so, but what we we, we still need to have the the catalyticalization of the.

C

C

So I I'm reading the jabber here and saying that what what you provide the question is, does you we need to have this still have the header map like? If you look at the x519, for example, we have a cosy header map to to to uh to to index whether this is an x5t or an x5 chain, and the similar similar type is what I'm requesting the type which is indicating that this is a particular.

C

C

Map there's no one wants to jump on the line, and I see a lot of comments here. So I suppose we just move this to the mailing list unless there are other for the.

A

C

So there is no raw public key draft tennis. This is something that is just proposed as an as an uh yeah.

C

C

Okay, I'm done thank you.

D

I guess uh renee was in the queue before me.

B

D

I hear you renee.

I

Okay, um I just have a brief question because we are in the other, any other business uh section.

I

um As you all know, uh I think that's some cozy registrations for uh things in the lv curve draft and I was wondering how we can speed up some of the discussions so that we can uh more easily get to a resolution.

I

So the first round uh has taken more than three months without any satisfactory uh uh technical discussion. So I was wondering whether we could do it uh in a different way or if people have suggestions how to make it seem more collaborative instead of now, it feels like blocking.

I

So currently we have a yana expert review and it's uh handled offline and it seems to be moving target and discussions on the cozy mailing list also seem to be separated from what's actually in specifications.

I

um I would really like to see that, if there's discussion that there will not be a two month, silence period happening and there will be a discussion on technical merit, as also stipulated in some of the specification works.

I

Any comment any comment also: why they're from the wider cosa group.

D

So I guess I can comment that I have a partial review of your draft and I'm planning to get back to that. Hopefully, in the next week or two, which I think will include some comments about the jose registrations. But I can't pronounce that more yet.

I

Yeah, so this is, this is more a general question. I I want to separate it from you know. Particular things about six uh one character strings. In that specification. I was just learning. How can we make the process more conducive to get into the results instead of making it an endless, dragging uh mind numbing exercise.

C

So renee this is joran zelander. I I think you have been provided an answer. At least I've answered the ayanna like a month ago, when we had this last main main uh mailing.

I

After three months of silence- and uh you know, there has been some offline discussions where uh it seems it seems that uh people are interested in blocking things instead of moving moving forward. Yes- and I.

C

Pointed that already on ben caduck's,.

I

Email that a few weeks ago, but I have not seen any response that all the half-baked ideas on the cozy mailing list- don't work.

C

So, as I said, I think there has been an answer to the ayanna at least what I know from from from my side. um There might be something uh not going all the way back to.

I

So so the reason I mentioned this under any other business is not to have a discussion with you on this so because you have not responded from november to february onwards in a in any responsive fashion, and I think the process needs to be changed so renee. If.

D

If you have issues with non-responsivity from ayanna review processes, you should talk to the isg or the responsible lady, which would be me.

I

I have, I have had many discussions with ads, but uh it seems that we have to wait until some people drop off or something, but I think we should. We should have a discussion on technical merit and not discussion. Yes,.

D

Based on specifics, political and blockage, there have been several classes of potential technical issues that were raised and we only had actual back and forth discussions about some of them. There are there's at least one where I think you were the last one to respond, and there was not a follow-up, uh but I think there were some where there were issues raised and you did not follow up. So I think there's work to be done on many fronts here.

I

I think the the political posturing has to stop because there was already discussion one and a half year ago by jim shot, who, unfortunately, is not here anymore, but I want us to be constructively moving forward and not get the impression that uh people just for whatever purposes they want to drag things on and not even have a look at the rfcs 8152 details.

I

I agree. We should.

D

Be focusing on the technical aspects and not political posturing, and I have not- I do not recall a specific instance of political posturing. I think that we need to continue the technical discussion and that is on all parties involved to continue to do so.

D

We are quite far over time and I do want to make sure now that matt has actually joined the session. But I get a chance to thank matt as the outgoing chair for service matt. You've been really great for this working group and we appreciate all you've done. So. Thank you again and uh best of luck. As you move on to newer and greater things.

J

Thank you and thank you everybody for the time um and, like you said, we're almost 10 minutes over. So unless there's anything else, I think we can call this a wrap.

A

J

All right, thank you. Everyone.

J

J

B

B