Internet Engineering Task Force Interim Meetings, 12 May 2021

Previous Meeting Next Meeting

⏯

youtube image

►

From YouTube: COSE WG Interim Meeting, 2021-05-12

Description

COSE WG Interim Meeting, 2021-05-12

A

And we should be recording now uh so hello, everyone, my name is fifa lupetrov, and uh I will be kick off this cozy internet meeting. This is an official itf meeting and as such, the note will applies.

A

If you are not familiar with it, please read it carefully before engaging in any conversation and other contributions, and this is the gender for today we will be looking at some document status and we will spend the bunch of the time with certificates zipper in coding and probably discuss a few more things along the way guys there any passion to this.

A

A

I will take that as a no, so at the minutes can be found here we will be taking a look at them with mike, but please do contribute and if there are any action items connected to you, please make sure that they are correctly represented in 10 minutes.

A

So as a reminder, the attendance and the meeting are recorded.

A

A

Let's move to the documents update, yeah.

A

Mike, do you want to say something.

A

Okay, uh so yes, as you should be already aware, the recharge has completed, and now the zipper certificate encoding is officially part of our charter. As I was working on some additional algorithms.

A

Then I saw that there was some progress with the hashtags and these documents they.

A

Should be in the final stages of the editors editing, so we should be looking at the hot for tda quite soon and hopefully we'll be able to have them published in the next.

A

I don't know a few weeks, hopefully depending on the world of the rfc editor.

B

Well, what happened is pretty interesting. um The rfc editor has a number of states in which documents can be and they have a state progression mechanism, and uh in this case they managed to get these three drafts uh wedged against each other in such a way that only manually pressing, a button for a state progression could unwedge them.

B

So sometimes you have to to look at documents that are in the rfc editor queue and see whether they they got wedged in in any particular way and and alarm the rfc editor, and they are getting better in this, but uh some of the process steps are still manual and they can really get stuck indefinitely. So if you don't pay attention, uh it may take a long time before it finally advances again, but we are beyond that now.

A

Okay, well thanks karsten for pointing this out, I was not worried. I was not aware of it so yeah that is useful.

A

Okay, so then, for the counter sign, we had a new version of the draft that should be addressing the points from the shepherd write-up, I'm not aware of any other issues, so I think the next step would be for the draft to be reviewed by.

A

A

So, yes, we will coordinate yeah to make sure that this progresses and next point is the x509 document.

A

From my point of view, there is only one issue that will not be addressed with the pull request from john for request 35, and that poll request should address uh issues 23, 29, 30, 31 and 33.

A

There is one issue 13 that is adding a reference to an ayana register, which I guess is a trivial editorial change that I would do and the issue 36 is about the support of beast by strings for encoding certificates.

A

A

With saying that this had some additional code to the implementation, so there was the question whether it makes sense to to keep this uh this option uh ben and has pointed out that at this stage uh it might be a little bit more uh difficult change to do all those still, of course possible.

A

uh From my point of view, we have already been having, in other places, variations where we encode elements either as an array or if there is a single element as a byte string.

A

So this shouldn't be something surprising for implementers and I don't believe we should change that if anyone has any other opinion, please share them.

A

Or comment on the issue, if you prefer john.

C

Yeah, yes, I covered some on the pr 35 today. I comment on. I think, ben's comment on that po were mostly misunderstandings from ben's sides. I don't really think there's any need for changes, then there's a discussion with michael richardson and lawrence glenblade regarding must or should then what what kusi should protect. You from, I think, that's more trickier issue to to resolve with more opinions, how much cost you should protect you from and what you can assume from the ca and so on.

A

Okay, I I guess those are discussions on the main link lists on the mailing list.

A

I will take a look at that.

A

A

Well with that, I think we can.

A

Go to the next slide is so uh well, the cause is simpler and encoded certificates is now uploaded.

A

The repository is moved to this location and I we have and we'll be presenting some additional slides for.

A

A

A

So the floor is yours:.

C

Should we or you present your own.

D

um I I think you could do it, so if you want please do it otherwise I'll do it.

C

Yeah I can present so yeah can take so this has been adopted. The new version has been uploaded. I think it might have contained some minimal changes from the last document, but I think yeah very minimal can take next.

C

Slide, uh we have also migrated the github repository to the cozy working group, github repository.

C

When we did that, we tried to close quite a lot of old issues that have already been resolved.

C

uh Then there's some changes and I think that one change that we made was the realization that the the draft did not refer to deterministic seabor, meaning that you could actually encode the integers in a lot of different ways. So an update that is also in the last submitter version is that there is a new text stating that whenever zebra is used, it's always deterministic seabor, referring to the seaboard or the the relevant section of the seaboard rfc.

C

And then we change the name of the data structure. They were previously called seaboard certificate and see where celebrity type, they're now called c509 certificate, and now the whole document is updated.

C

C509 because they will comment that we should not call it c board certificates.

C

I don't know if the group is happy with the name c 509 there's been no objection against it, but I think if we want to change it to something else, we should decide that now or pretty soon, um michael richardson, that he can live with c509 um good. Then a question to the working group.

C

I think when the charter was in the late stages of the shorter restructuring in ice isd, there was an addition that the because they might work on double signs that certificate, so that is both using two signatures, one over there and one over c boar.

C

I think that was added by ben. If I understand it correctly now ben is not here would be, would be interesting to discuss exactly what the use case would be for this and how it would help before we start to structure that I guess it would be a new type of c509 certificate.

C

um Is there anybody in the group that has any views on double science tickets.

B

Well, the the obvious use case is that you, you doing some process with both non-constrained and constrained environments and the non-constrained environment, some hsms that only can verify x509 signatures and the constrained devices actually want to stay on the silver side of things. So having both signatures in there may be a good way to to cover this continuum, and I would prefer, if we made this as painless as possible, uh to do so.

B

You you can just have one or the other or both and and things is uh uh it's easy to have them, because in the end, uh the the certificate is the it's the content uh plus signatures and in the end it doesn't really matter from a um security point of view which kind of signature you you have.

B

So it should be able. It should be easy to add both if you actually get them.

E

So I think there's.

B

E

Side to it, which I understood when you wrote double assigned certificates, which was not at all what carson just said, um and that is that in lamps there is some process about to start with, uh having both post quantum signatures and legacy signatures, and some of the pro some of the ways that this is proposed to do essentially look like auxiliary data in a the legacy certificate.

E

um So that's what I thought the word double sign, certificates meant, um and um so uh maybe I've just suggested. There's tripoli sign certificates now, um so um I don't know how that fits into the space of this, but I don't think we should did I get this right. This is essentially.

B

A counter signature type so.

E

It's not the same signature.

B

It's uh the signature actually means something different.

E

Well, so you're gonna have to um spend some time uh uh puzzling through the documents, as I am but effectively there's uh one proposal that says that the same ca will sign uh both um legacy and post quantum public keys with both and we'll sign it with a legacy and a post quantum signature.

E

um Another way says: there's two ships in the night and that the post quantum ca signs, the post quantum part and the legacy part sends the legacy thing um and then there's several different proposals as to how to represent this in this in the x 509.

E

uh In the thing uh process, um with with one of them being there's completely separate certificates for the two things and the other one is that the the data is mixed together using various kinds of extensions, um and I I can't say to you, I can't say which one is the dominant choice right now, because I'm not sure anyone understands that and there's some good presentations in the archives from the last in the previous lamps meeting, and if it makes your head spin mine too,.

C

I'm I don't really understand why the post quantum algorith update would be handled different than any other algorithm update. We have done in the past, like sure md5, to show that.

E

So that's that's one of the arguments. That's one of the arguments. It's just another algorithm.

E

What's the problem and the issue is that um it turns out that people are saying yeah, but I don't know how to process the new certificates yet yet I want to issue them, so you want to have both signatures in each certificate specifically, so that the older devices can continue to do something um and and that we don't know at what point some long-lived certificate is suddenly going to become um um uh uh uh forgiable um and that way, so so that's part of the consideration is that it's not just an algorithm change and um um that's why I suggest you watch the videos.

E

I think we're going to have more than one solution coming out of this.

B

So the question that really comes to mind is whether these signatures are actually the the same or whether they need different metadata in in design part to actually describe them, and when they need different metadata, then you would essentially have to partition the signature between the the parts that are common and the parts that are different and that that is going to become unwieldy.

F

It doesn't take my head, it makes my.

F

More than one signature on a certificate, especially if you consider the sizes of a post-quantum keys and signatures, uh seems pardon my strong language absurd, not all.

D

E

Are not all of the post quantum or the quantum safe signature? Algorithms are actually bigger, some of them are smaller, um but some of them may be right, so um we don't know yet. I'm.

F

I'm considering those that uh are in uh nist around three at the finalists.

C

I think rainbow is very small, but have huge public keys so does the certificate would be? I think this picnic level, one signature or 64 bytes, but the public keys- are several hundred thousand bytes.

F

So the argument wait. Wait. um Let me finish, please my my point is uh saying: well, we want to produce certificates which we do not quite know how to process yet sounds like I want to.

F

I do not know how to fly in a plane, but I want to be an airline pilot now, if, if, if you need legacy for now and post quantum for later, do that because the likely sizes, especially uh since the signature usually is the at least for post quantum, it would dominate the size of the third for classic.

F

Well arguable. Are you talking rsa? Are you talking elliptic curve? Are you talking elliptic curve over p256 or are you talking errors, say 1496 or bigger anyways you, you need uh certificates for different processes, get two certificates and this would alleviate the risk that on a double signed certificate, for example, the classic part is forged, and now you have a cert with one signature, fine, another signature not, and if you can process only one of the two, how are you going to tell the difference be between fake and honest?

F

So I I see what a goran put in the chat. Yes, the the charter suggests exploring and I would say the exploration shows, it's more risks and inconveniences than benefits.

D

Could add something there.

D

So yeah I mean the chart, I think the charter it talks about exploring, but it's also uh clear what I think, what what what is going to be what should be explored. If anything and that's um that you have this sort of the same setup, same keys same same parameters, but you include both the signature over the c board and the signature over the daring coding that that that's what the charter speaks about, and I think there are many interesting exp ways to expand this.

D

But but I think the question particularly was raised by ben was. Was this thing, because this is his words in in the charter? As far as I can say,.

F

And um the main reason to use cyborg, as I said in chat, is it's uh smaller size? How is uh they're going to arrive at the recipient you sending it together with cbor? Then it completely doesn't make sense. Do you expect the recipients to re-encode the cyborg in there and then validate the signature.

D

Yes, that's exactly how it's in that's type type, one that's sort of re-encoding in there so and I think your idea would having an uh an option to strip off the constraints the um that they're encoding, that that that makes sense. I think, but perhaps we should wait for ben to see more more in detail what he is.

D

What he had in mind here.

C

Yeah my question on this slide was my understanding is that it would be a seabor certificate with seabor encoding. Only and what would be added is the original signature, so it will be, would be 64, bytes, larger, and my understanding would be that the this would be an optional expansion of the current draft, so nothing that you do on by default, but I'm I'm not sure it's worth doing but kirsten seems to think it had use cases.

C

Maybe we should agree to, I think the next part of the discussion should, if we explore this further. The next part should maybe be more explicit um details on on how this could be used, but also use case discussions why it should be used. Then.

A

Yes, so maybe we can try to have this discussion also on the mailing list. But yes, what I hear is that, while writing this, there were some considerations that we might need to support, at least that first, both in standing, the their equivalent of the civil war, encoded certificate or the civil certificate itself, and I think part of the reason was also to have simpler parsing on the device, not only the size of the of the messages, but that will be maybe cleared out during the discussion.

A

Hopefully in the main eclipse and.

A

Yes, let's, let's try to.

C

A

Can try to write some summary of the discussion here and we can try to see what would be the best way to uh go forward with this, whether it's it makes sense to support it only in some cases, what would be the cases etc.

C

Yeah, I think it sounds great to have a discussion on the mailing list.

C

Let's continue now when the document is adopted and the document is currently registering a new tls certificate type, so I have requested uh time from the tls tiers at it f111 to shortly describe this to the for the tls working group. Let's see if we get that acceptable, I think it's essential to collaborate and coordinate with the tls working group before cosi registers, tls parameters- maybe the tls working group, I've. What I heard from tls people seems that they seem interested in this. So I assume that will be the case.

C

It might be that the tls working group has comment might be that the tls working group would like to doc tls working group document to do this. Registration could also be that the tls working group does not want this registration at all. Even if I don't think that will be the case, but.

C

And that is basically the current updates. Then the next slides are about sending rpk by value. This was brought up in the lake working group like working group. As you probably know, it's designing. The ad hoc key exchange protocol and ad hoc is very heavily relying on cosi, for basically everything both crypto and to identifying certificates and so on, and one of the things in the lake requirement document is to uh include them that the initial focus should be on rpk by value.

C

This was recently brought up again by christian amsas on in the lake working group in the re-meeting. That needs needs to be done, and there has also been several industrial partners that we know of that thinks. This is an important use case, so educ currently relies on cosi to transport and identify credentials, use all the cosy header parameters.

C

Kid x5 parameters or the c5 parameters and rpk by value should hopefully also be done with a cosi uh head of parameters. If the coast working group thinks this is a acceptable id.

C

When thinking about this, we came up with two main options: one is to use a cozy key.

C

This is yeah, and this other is to use a c509 certificate but stripping the issuer and the issue signatures, and these have roughly the same size, but they have slightly different properties, pros and cons. um You can go to the next slide.

B

So, can I quickly ask you a question um when you say rpk, do you mean rfc 7250 or do you mean the concept of a raw public key.

C

I mean the concept of the raw public key, thank you and maybe not to raw either as we will see, but the public that is not a certificate.

D

But carson your question is, is well well put and timely, because one of the solutions uh is that we do like in rfc, 7250, basically strip off the signature of of certificate structure.

B

Yeah- and we should be able to do that today, right.

C

Yeah, but we don't want to use, I assume I assume that's the tls rpk rfc you're, referring to yeah.

B

C

Yeah yeah and that that of course uses a x509, their encoder structure that we definitely don't want. It also strips away everything except the raw public key, and it's not not sure we want to strip away that much either yeah.

B

So in in the cozy world, are we talking about proof of procession keys, or um I mean there are already structures for that.

C

Yeah not in cozy itself, I guess not to send it on the wire.

B

Okay, I I'm don't have this off the top of my head.

C

Yeah, what do you are you referring to yeah? Maybe.

C

Some web tokens, or is that what you refer to.

B

Or eight seven, four.

C

C

Let me continue with this slide. We can discuss so what jiren and I discussed for for ad hoc was so far. We are looked at cozy key or stripped down c509. That could be differently stripped down positive things with koseki is that it's available in cosy implementations? If you have cozy you have that it's not designed for transport on the buyer, but it could of course, be fixed.

C

uh There's currently, a new header parameter to send to use it by value. You can refer to it by a kid, but that necessary. Then you need to have it in your on your side beforehand. uh Kozuki only supports a limited amount of key ops. There have been it does not uh support. I think the key usage for the hellmann key derivation and also has been discussion that ad hoc would maybe need some dedicated key usages or key ops.

C

uh Kozuki does not include additional functionality that is available in a certificate like validity and subject name. It can just be discussed whether these are needed or not.

C

If you want to align with the sigma protocol specification, then you need to have a subject name. That's my understanding is that that stated, as a must in like that's something that the sigma protocol have. So if you start to remove that, then you can be questionable. If you are sigma or not, and then validity and key usage seems to be, could be useful, also for a raw public key or a public key.

C

I don't know if it's raw, if you include these, it's not the certificate benefits with c509, is that adhoc will a lot of edward implementation will use c509 certificates anyway, we have seen interesting implementations of that.

C

So using both c509 and kosiki has some negative implementations. Then you will need to support two completely different key formats which cause additional code, and maybe that you need to register key ops, eq extended key usage twice.

C

Then the following slides shortly show some examples on how these public keys look like in these two variants can take next slide, so here's an easy example of a cosy key with the point compressed the er.

C

Maybe the curve is wrong here, but this is a com point compressed easy to. Let you illustrate uh next slide.

C

And here is an example of how uh slightly slimmed down version c509, the in the cdl here the issuer and the issuer, signature algorithm and the issue signature is removed and you have something looking like on the right here. This is the example signature examples that you get with these fields removed.

C

Then we can take next slide and then you could, of course I you could use them with just nulling them. Then you end up with the left or you could. If we determine that key usage and the validity and so on is not a subject. Name is not necessary for the raw public key.

C

Then it will look something like on the right yeah and then there was a comment from the comment from cast and use. I don't know if it was 8 7, 4 7, and I guess that would be a third proposal compared.

B

To this yeah I don't want to muddy the water, but I think we should have at least demonstrate that we have looked at this thing and consciously decided against it.

C

Yeah but then we that does not have a header parameter either. So if you want to use cwt says rpk by value, then you would need to register a header parameter for that. Yeah.

C

I have not looked at using cwt, so I think that's a good.

D

Input and there's also some needs um for canonicalization. I suppose in this.

D

C

So I don't know if there are any more slides.

A

No, that's the the end of the presentation. I don't.

C

Know what does the cousin working group think about defining a way to send the rpk by value? I guess the cosic either though it would be a separate graph, defining a kosoki by value or a cwt by value if it's the c509 alternative here that would ecs be defined in the c509 draft.

C

Another alternative would be that late working group do a registration like this, and we will discuss this more in late course also later, but we wanted to discuss this first in the coastal working group. I think the expertise for this is here, and this is very much cozy.

A

It sounds to me as well that that could belong to the cozy working group. Of course we need to discuss that also with ben, and uh I don't know if mike has any other opinion, but at first glance that that sounds, it could be long here. The other point is, of course, having the consensus that this is something we want to be working on.

A

G

My question is: are there real use cases for this? If so, we could consider it um I'd like to see like a paragraph or two write up on the mailing list, saying why we would want to do this and what use cases would be.

D

Satisfied: okay: let's: let's start that trend.

C

Yeah, but the the use case would be like optimistic. You, you get your key on first use like in ssh.

C

That's what we are hearing from some industries wanting to use in this? Maybe christian you have use cases. I don't know if you want to describe your use case. If you want to wait until the main.

C

D

I think they're basically several ways of doing this, but I mean it's probably easy to argue that for certain use cases we need to transport the raw public key like like the example john gave here. But what is more difficult is to say what exactly which option should we go for because there are more than one and um yeah, and then there is this slide with the different pros and cons where we can argue uh add arguments to.

D

Oh christian is now answering in the.

D

G

The other question I've got is- and this is partly for evo, but really for ben. Does this just doing this require a charter modification? I don't.

E

E

I think we have an ad on our call.

A

Yes, I think we'll have to discuss this with ben from uh from memory. I think that would need a rechartering, but we need to verify this and discuss with me.

A

Okay, uh are there some other comments on this, or maybe we can be discussing the uh future of the java implementation.

G

So I, as long as we've, got a little time, I'm going to ask what people on the call think of the.

G

Possible representations, there's that bear option. There's the cwt option. Why would we choose one or the.

G

G

All right well hearing nothing.

G

um Maybe that question should be asked on the mailing list as.

G

A

Okay, so uh are there any opinions about the future of the causes java implementation?

A

I believe this record might.

H

Yeah, yes, maybe I can say a few words since I kind of triggered this discussion. So basically, there is, under the cozy working group uh part there under github.

H

There is an implementation, of course in java, which is hosted there on github, let's say in the folder of the course working group, and this is the implementation that jim chad created and maintained and we're actually using that in an implementation of ace and also we're using it for os core functionality.

H

And the problem is, I would say, two uh number one is: is there anyone that can kind of take over from him and maintain this code and accept incoming pull requests? Now, I I reached out to ivaido and he could accept one pull request. I created there, which was very nice, but I guess there is a need for a more long-term solution, so the code maintenance is one question.

H

The second question is that this course yoga library, it's also released on maven as a maven project and that's typically how we use it as a third party library through maven. So there is also a need for someone to regularly release new versions of the cosio library onto maven, because now, even though I managed to get my pull request accepted to the to the java code, if that's not released, if the latest version is not released as a maven project, we can't really link and use that as a third-party library in ace, for instance.

H

um So I guess the question is generally.

H

How can this is also, I see like we're using it for some projects and all if I look at maybe there are other projects using this code, so it would be a shame if it kind of went away or if no one took it upon them to continue uh developing this code, since it's used here and there. So that's basically the question like: what's the plans for the future for this code, that, uh with tim sharp's uh unfortunate passing, is there any plans on how this can be continued to to be maintained?

H

How can it live on and how can it be released regularly on to maven, etc?.

E

Ricardo, I think you've just found yourself a job.

E

Actually, I think that you should fork it on github to a repo that an organization you control and I actually think we should mark that code as archived in our repo and point it someplace that elsewhere, because I don't think that uh as a working group, we have a responsibility or authority to figure that out.

H

So so, of course, that's one solution that I I I take it upon myself to make a make a fork, let's say and then try to transition, so that becomes a new official release to some extent at least we can use it in our own local projects more easily.

G

This is mike, I agree with michael that this isn't a working group issue. There may be interested parties in the working group and related working groups, but I don't think we have authority to decide anything about code.

H

Okay, okay, so the recommendation is that this is not a task that this is the responsibility of the working loop, like you said, or under the authority of the working group. So the current code there in the in the github of the working group, can be marked as archived and then, if anyone wants to continue to use this, it's more upon them themselves to to fork it and manage that on their own.

E

Unfortunately, yeah um I mean that doesn't mean that I think that postings to the working group mainly saying that you're doing this and other people are unwelcome, but um that's uh really. It.

H

Sure sure, of course,.

G

I agree with that. It's perfectly fine to inform people of things that are happening in implementations related to working group output, but it's not a working group project per se.

H

Okay, let us think of it on our side and then, if we decide to to do this act and fork it, we can send a post to the uh mailing list to announce this, that we will try to, let's say, take over this code in a sense.

H

Okay, thanks for the input.

A

Okay, is there any other business.

I

Hey um I I have one similar to the to this discussion on on the github repo there's an examples, uh cozy examples project and I was just wondering how that's being maintained.

I

For instance, I've had pull requests, sit there since december.

I

Is that planned to be maintained by the working group and who reviews and accepts those pull requests.

B

Well, the working group doesn't create products like that, but I think it's do something that people in the working group can be interested in uh maintaining. um So uh I think this is the case where, where this is close enough to what we are doing in our documents, but we also need examples.

B

um I think these examples actually are in 81 52 bits, so we would be uh well served by keeping this code alive in case we ever need to update that. So I think it's slightly different from from the java code case.

E

So I actually, for instance, I actually import that examples into my code as a sub module uh to run my tests against. So um I don't know what your pull request is, but I'll certainly look at it. um I don't know how we can achieve um authoritate authority on this well, but I think this is perhaps within the working group to decide.

G

Just mike, I also agree that this is within scope.

G

It kind of reminds me of rfc 7520, which was jose examples which our own matt miller wrote in 2015, that that was considered important enough to interoperable adoption that it's published as an rfc. In our case, we've published examples in our rfcs and given that this is an input to our rfcs, I think it's worth.

B

Maintaining so we need to find someone who wants to be cured of it.

E

We have that github summary thing that sends us weekly the mailing list: weekly um summaries of activity. Do we have that running for the coast, cozy.

A

I don't think this is configured there right now, but uh yes, we can do it.

E

If we did that, and we added the examples to the list, that would probably be useful, because then things like pull requests that were sitting there for six months would would show up in the summary and um maybe we'd get some upvotes or something.

G

Michael, could you maybe ask to have that done.

E

I'll find yeah I'll ask on the list.

G

And I think matt miller is the one with the expertise to do it.

E

Yeah, okay, um yeah spencer, did it for the working group that he and I are co-chair, and I am blissfully ignorant.

A

D

D

Another admin thing while we're running out of time, I forgot to link the seaboard certificate, the c509 certificate draft, the working group draft and the individual draft is there something u.s chairs can do or is it something I should do.

B

You can do that or you can send a message to the secretariat and they will do that manually. That's usually usually the easiest way to fix up things like that.

D

Okay, so I'll send the mail to the secretary yeah.

A

Okay, any other topics. I guess we are more or less out of time, but if you have any other things you would like to discuss. Please also share on the mailing list.

B

Yeah but once the meeting is over, if I again have to talk to you about that meeting, we are still trying to set up sure.

A

Okay, so again, that's all. Thank you, everyone for the participation. uh Please take a look at the minutes and once they are published and see you again in about a month.

G

Thanks everybody.

G

Thank you right.

D

Thank you thanks.

A