**Session Date/Time:** 23 Jul 2026 14:30

[00:00:34] **Mike Jones**: Could somebody near the back please shut the door?

[00:00:46] **Ivaylo Petrov**: Hello. I think we can get started. It's we are out time. So welcome to this COSE meeting. This meeting is an official ITF meeting, and as such, not well applies. We'll talk about that in a second. Also, please use the Meetecho tool either on-site or the full version. But if you use the full version, please mute yourself so that we can track attendance and so that you can join the mic. So let's talk about Note Well. This is our Note Well. You have already agreed to it. Please be nice to each other, be kind to each other, and also IPR applies in this meeting. If you have any questions around that, please ask us or someone from leadership. And this meeting is being recorded. Here, there are a few tips how to use the tools. Probably you have seen them already a bunch of times. So let me go. Here are some useful resources that you might want to check. And with that minute, we have already two people agreed. Marco and Ricard, thank you so much. And of course, anyone else that wants to contribute, that will be awesome. Okay. And here is our agenda. Is there any version of this agenda? Okay. Hearing none, I will continue with some good news. We have three new RFCs since the last time we met. Congratulations to the authors, and thank you for the work on these things. Okay. And here are a few more updates on working group documents. The hash envelope draft is in IRFC editor queue. The encoded cert is submitted to IAG for publication. The C509 test vectors draft has successfully completed working group last call. I think we didn't make the call on that in the mailing list, but we will send the email. I think there was enough enough support there, so no controversy. And then the HPKE is waiting for AD to start, ITF- call. So, the AD completed the evaluation. And then the SPHINCS+, I just uploaded the shepherd Shepherd write up yesterday and sent some nit picks to the authors to address. And after that, I will send it to our AD for follow-up. And then Falcon, no updates. Waiting on this to advance this specification. And the BLS key representation is waiting on BBC spec progress. And then the HPKE PQ PQ team was adopted and is now a working group item. So those are the dates we have. And with that, I think we can go to our first presenter. Let's let me switch. Yes. K.

[00:05:22] **Brian Sipos**: Hi. Thank you. I'm Brian. This will be short, I think. Just giving some status since the last IETF. If you could flip to the I will flip to the next and only slide. This draft has been adopted. It says here, we'll be transferred to the working group organization. That still needs to happen. I need to coordinate with, I guess, the the chairs about pushing the buttons and making that happen. But that's a mechanical thing that needs to be worked out. The the document itself has been updated and uploaded to the data tracker. It registers four new code points, in the table that's on the right. And this

[00:06:16] **Hannes Tschofenig**: the earlier version of the draft had added a section 3.1 under security considerations to explain

[00:06:25] **Brian Sipos**: key overuse limits and reference an analysis and explain summary about how to avoid key overuse. And then there are some open kind of editorial issues that remain. One of them is a simple typo in IANA section. One of them is that it's always helpful to have examples. And once there are some code points preferred, then I could come up with some very simple examples just as proof of how do you validate a implementation. Issue number 12 is about a reference to the the, CMAC analysis done by Ericsson. Right now, it points to a GitHub Pages URL. There's a copy of the document on the NIST website that might be seen as more stable. I don't really have a strong opinion anyway. And if anybody does, let me know. And the the last one is about adding a link to a trial implementation as a implementation status section. That would be just for the draft and not for a final publication. So that's where it sits right now and pretty straightforward, I think. The the open question, if there is any feedback about those TBA code point numbers, where they would come out of the registry, That would be helpful for making examples. Smaller, I think, is preferred, but I also don't think it matters that it'd be under under numbers 24, which is, that breakpoint of the CBOR encoding size. So thanks.

[00:08:24] **Mike Jones**: Not wearing my chair hat. I suspect the the NIST reference is preferable to a GitHub Pages reference.

[00:08:32] **Brian Sipos**: And Okay. So I'll I'll track that as an issue and can work that out in the next revision.

[00:08:36] **Mike Jones**: Yeah. And you you and I, next week, can find a time to move the GitHub repository.

[00:08:43] **Hannes Tschofenig**: Okay.

[00:08:57] **Carsten Bormann**: Customer one. So Brian brought up this interesting question of how do we handle the code point assignments. I think we want to be more aggressive in using seventy one twenty earlier location. And I think we need to think about a process that makes this happen within the working group. So I think we are approximately there. I'm not entirely sure that we have discussed on agreed on the the selection of key lengths and tag lengths that we have here. In any case, we will probably have to decide whether these are worth very short numbers or whether we go out of a larger number space. So the first 24 numbers are very short, and then we have larger ones. I would expect that the tag length one twenty eight ones don't need a short number, but I don't know enough about how the other two will be used, whether that's worth it. So that would probably be a good place to get some input.

[00:10:17] **Brian Sipos**: Thanks. As my own preference, any number starting in the thirties is is appropriate. Even the 96 bit tag length is it's not harmful to have a two byte encoding. The the goal of these algorithm registrations is for efficiency and for FIPS compliance. So it's it's about processing more than it's about encoding size.

[00:10:46] **Mike Jones**: It is often done in drafts to Suggest request assignments of a particular size. So for instance, asking for something in the two byte range for the things we we would have discussed is probably an appropriate thing to do. Okay.

[00:11:16] **Brian Sipos**: That's all I have for this.

[00:11:20] **Ivaylo Petrov**: Okay. Thank you.

[00:11:27] **Mike Jones**: And what was next?

[00:11:34] **Ivaylo Petrov**: Yes, Emil. The floor is yours, and I will put the clicker in a sec. Thank you.

[00:11:44] **Emil Lundberg**: Thank you. So here's an update on split signing algorithms for a COSE by myself and Mike Jones. We presented this as IETF 120 and, yeah, described the developments then since 124 and called for adoption. And, yeah, we'll need to repeat the rest of that here now because we did get working group adoption since. So thank you, everyone. And, additionally, what has happened since then is we have published the working draft zero zero, which is just the copy of the the final individual draft and then update number one. There's also an ongoing discussion with on a couple of things, which I'll get back to in a moment. But the so the updates we've made to the spec in in o one is essentially cleaning up some editorial things around the bibliography and some typos and CDDL minor things. There were a bunch of AKRG stuff that was put in into the individual draft o seven kind of in a rush with which we've moved back out. So the draft no longer has any references to AKRG. Other than, like, informative, I believe, examples and that and that kind thing. But all all of the, like, practical examples of of using the spec are now replaced with EdDSA, and ML-DSA examples. We also discovered that we had made an oversight in the EdDSA definitions, and that we had hadn't defined the context input for Ed25519ph and Ed448ph. So we have now just defined the context input and added a COSE_Sign_args member for that context argument. So in short, some editorial cleanup, making this draft independent of AKRG so that we can move that one independently and not need to hold this one up depending on that, and then fix the oversight in the EdDSA definitions. There have been no architectural changes since IETF 120 in Montreal, only the addition of this additional algorithm specific member for the EdDSA context arguments. So the discussion with with Ilari centered around mainly two concerns. The first one being that this is not the best way to address large messages, which is one of the reasons for introducing these algorithm identifiers. Because what you can do is just pre hash on the application level instead or use hash envelopes or similar kinds of techniques. And I agree that that is a better choice for new protocols, but the purpose of this is to to be able to be compatible with existing protocols where you don't have the freedom of choice to choose that, how the algorithm invokes a signature or verifies a signature. So the the point of this is to be compatible as a drop in replacement for in existing protocols so we don't have that freedom of choice. And yeah. So that that is the point of the entire thing is to have that compatibility. The second concern is that the COSE_Sign_args structure is not self contained. So if you want to make, like, assigning API using only COSE_Sign_args, that doesn't work because we don't have the message to be signed in the COSE_Sign_args. We only have the additional arguments for specific to each signing algorithm. So we could add those in. The way we designed this so far is that we've kind of assumed that assigning API in general will have at least a secret key argument and a message argument. And now you can you can add on a COSE_Sign_args for anything else that doesn't fit into those two. It I'm not that opposed to the idea of putting these values into the COSE_Sign_args. It would make COSE_Sign_args, like, a complete representation of everything you need to make a signature. On the other hand, I would make those members optional for protocols that don't need them because they already have key and signal or key and message arguments, which would make it so that you you could have key and data arguments in both in those separate parameters and in the COSE_Sign_args. And that kind of optionality and the possibility to have the same thing in multiple places is a barrier to interoperability. So that is the main objection against doing that. We think it's a reasonable assumption that signing or or signing APIs would have key data arguments rather than folding everything into one. But that's perhaps the discussion to have with the group. So that's summary of what's up and what we wanna do next. We the the draft is quite stable. We have implementations, although I should say as a caveat, not of all parts of it, but we have implementations. We hope that the remaining review feedback can be resolved without needing any changes to the spec, but like I said, perhaps up for discussion. And, yeah, there are practical use cases for this and practical applications already using this, namely, W3C Web Wallet. So yeah. We'll need to resolve the remaining feedback and then hopefully move towards the last call sometime soon. Mike, anything you wanna add?

[00:18:08] **Mike Jones**: No. You did a good synopsis of the journey we've been on and where we are. I agree with you that it would be an unnecessary and kind of a natural change to jam everything into the signing args. In particular, you don't wanna copy the large data just to create that structure. So you've already replied to Ilari. I can do so as well. And, again, this is me chair hat off just as an author.

[00:18:48] **Ivaylo Petrov**: Okay. So now the floor is open for comments, thoughts. Maybe let's start. Who has read the most recent version of the draft? Okay. We have one person. Okay. Who has read a version of the draft? Okay. A little bit more people.

[00:19:15] **Mike Jones**: Sofia's read it.

[00:19:18] **Ivaylo Petrov**: Okay. Yes. And just for, I guess, more better understanding what what implementations are there and what is the status, can you just for fuller context?

[00:19:40] **Emil Lundberg**: Yes. We have so the spec defines two roles, the the digester and the signer, and we have one implementation of each role specifically for for the ECDSA on P-256 is the one that is implemented so far. We have implementation as a digester in W3C Web Wallet and implementation as the signer in yubikey five .eight. Actually, to be precise, it's an implementation of ECDSA P-256 AKRG, which is a separate document dependent on this one. But it extends naturally from the definitions in this draft. So not all of the things defined in the draft are implemented at the moment.

[00:20:40] **Ivaylo Petrov**: Okay. So at that point, it feels a little bit early for working group last call. I would like to get a little bit more people review the draft and kind of provide feedback. But, otherwise, seems like you are making good progress, and hopefully, sometime soon, we'll be able to do that.

[00:21:07] **Mike Jones**: Do you wanna get a few volunteers on record?

[00:21:10] **Ivaylo Petrov**: Yeah. That would be great. Can we have some volunteers to review this draft? Thank you, Hannes. Okay. Thank you, John. Can we have a third person?

[00:21:30] **Emil Lundberg**: Sorry. I didn't get the second person.

[00:21:32] **Ivaylo Petrov**: John Bradley. Let me find you. Okay. We'll also ask on the list for potentially more reviews, but thank you. K. Yeah.

[00:21:59] **Mike Jones**: Honest with Falcon is next. No?

[00:22:03] **Ivaylo Petrov**: Yeah. And that's Oh, that's actually scratched. Yes. So the

[00:22:08] **Mike Jones**: Tiru with Yes. PQC Chem.

[00:22:22] **Tirumaleswar Reddy**: Good afternoon, everyone. I'm Tiru. I'll be talking about PQ-KEMs for Kose.

[00:22:31] **Ivaylo Petrov**: Yeah. Oops.

[00:22:33] **Tirumaleswar Reddy**: Yeah. This document has been with COSE working group for almost, I think, three years now. It has been adapted by the working group, has progressed. We received several comments and and all the comments have been addressed. But then the HPKE document also progressed at the same time. It it included PQT hybrid schemes and PQ-KEM as well. And and, basically, the COSE working group realized that we realized that there are two mechanisms, basically, for PQC chems, either to use PQC itself or we could use PQ-KEM as a standalone just for COSE. Right? And though the document covered both COSE and COSE, the COSE working group feel felt like, hey. We we will stick to HPE only. Right? And and then we had no use case for this, so the the idea was let's abandon this. Right? But then we got the request from the lake working group saying that, hey. Lake cannot use HPKey. They need PQChem because they rely on Cozy, and they wanted this document to be progressed. But since the scope of this document would be narrowed, there is no way that we could progress this document in COSE. So there is a working document in there. Now we want this document to come to this working group, see if there is interest, and then progress this document here. What this draft does at a very high level is it uses all the ML-KEM parameter schemes, three of them. It also supports both the COSE algorithms, direct key agreement and key agreement with key wrap. It's independent of HPKE, it does not rely on the integrated encryption mode that was introduced in COSE-HPKE and JOSE-HPKE, it's it's a model very similar to ECDH style key agreement model, it requires minimal migration path from ECDH+AES to PQ-KEM for deployments which want similar interfaces. Right. And it uses the chem interfaces that are already because the chem interfaces, it use the COSE ek parameter to carry the chem ciphertext, and it uses the KDF, basically, to get the CCA two properties so that the public keys can be used multiple times for encapsulation operation. It uses the OKP key type where and the seed form, which is instead of the expanded private form. And all these were discussed and agreed upon within the working group. There was no contention on on the mechanisms that were, discussed in this document. Right. And it supports both the direct, shared secret as the content-encryption key for direct encryption and as a share as a shared secret to wrap the content-encryption key in case if multiple recipients are involved. It supports all the three modes, basically, with all the variants and then the key wrap mode as well with the corresponding AES levels to match the security levels of the corresponding PQ-KEM algorithms. And and the main reason why we are here is we have now a bunch of documents within Lake, which is basically referring this document. And they they really want the PQ-KEM with cozy and don't want to use the HPK one because they they do not do the integrated encryption, and they want to just take the shared secret and then later use it for encryption and integrity and other purposes. Right. So earlier, they were using EDHOC, basically, and the working group was rechartered to basically use PQ-KEM, and it is used to derive the new shared secret. So these are the messages that they have, g x, g y, and and the k becomes the the output of the p q c cam that's being invoked. They are not interested in the KEM + KDF + AEAD bundled into one encryption operation. Well, it's it's a mature document. Right? And there is use cases in other working group that want to take this forward. So we would request the working group to consider adopting this document. Thank you.

[00:26:59] **Ivaylo Petrov**: Okay, Angus. The usual question, who has read this document? K. Do you have any thoughts whether the working group should be adopting it? Do you have any concerns about that? Okay.

[00:27:27] **Laurent Toutain**: Hello. IMT Atlantic. I'm late co chair. Yeah. I read a previous version one year ago when it was. This one, haven't read. Yeah. The time was quite simple. I I don't know if it was at the time at Lake, we didn't have anything about post quantum. So we will need eventually some this at Lake or one solution for ML-KEM or others. We will need flexibility too. I think, yeah, maybe COSE is the right working group where this should happen eventually, But I will well, I I I offer myself to review this version, and and I would think we will need maybe to work closely, like, and this draft to to to have what we need and to avoid making mistakes. And yeah.

[00:28:19] **Tirumaleswar Reddy**: Yeah. John Mattsson, who's quite active in the late working group, was the one who said they would need that. And then we I really looked into all the documents and realized how they are being used. Right? So I don't go to the late working group, but then when he bought it up, I went through and analyzed that. So thanks for that. That would be really helpful.

[00:28:34] **Ivaylo Petrov**: Okay. For the record, it seems like in the room, there is some support for our working group to adopt this so we can run this on the mailing list. And yeah.

[00:28:56] **Rikard Höglund**: Thank you.

[00:29:09] **Mike Jones**: cose-turbo-kanga-kmac.

[00:29:22] **Hannes Tschofenig**: Yeah.

[00:29:27] **Carsten Bormann**: We we definitely have to create a turbo king. We ring two meetings. So I gave a shorter and and less developed version of this talk two two meetings ago, I think, as an another any other business item. And now we have a actually have a draft. So that that's been there in me. And the idea is given that we have a number of Ketak based algorithms that we can choose from, we want to be able to use them in in COSE. And algorithm is readily available if it's registered. So we should make sure we do this registry. So there there are two things. There are algorithms that that don't have a registration yet, and there are also algorithms that do have a registration. But this was an IRTF document. And IRTF cannot make recommended entries in the recommended column. So we would update these algorithms to recommended. And the idea was to have all these in in this document. Maybe we want to split this at some point, but right now, we are not overwhelmed by by verbiage in this document. So the max XOFs, these are registered by the IRTF documents. So why didn't I put the r the the RFC is ninety eight sixty one, so you can look it up. And they are currently set to recommended no. And the only thing we would change here, would be to set the recommended to yes. So that's one thing. And then based on that, we built make algorithms. So the previous one was what we would colloquially call hash algorithms. And the make algorithms have been sketched by 9861, but CFRG essentially thought, oh, this is so trivial. Why don't you do that? And yes, yes, we do it. And we got also got some feedback already on those. It wasn't definition, so it is possible to to make them better than what's in the current draft. So that would be in the next draft. So we are looking at three groups of max, every single one in one twenty eight and one in two fifty six using turbo shake for a Mac. And, yeah, that that should be obvious what we do there. The original KMAC as a Mac, and Kangaroo12 as a Mac. So what's the difference? KMAC is the original Kajak based Mac. TurboShake, first of all, is an XOF. So you can generate all kinds of sizes, but we are only looking at two sizes here, one twenty eight and two fifty six. And TurboShake actually does its job at half the number of rounds. So in a constrained device where where you have battery problems and all that and maybe you don't want to let the user wait for too long, it's useful to be able to use a turbo shake. Apparently, the round reduction here really just takes off a little bit fat from KMAC, which is maybe has been a little bit overly careful. So I think that's the the main difference here apart from the fact that one is an XOF and the other one is is a classical Mac construction, a hash construction that is used in a Mac. And the third one is the Kangaroo 12 algorithm, which is essentially providing a way to divide your input into a tree. And you can paralyze the computation of the Mac in the tree if you have the computation resources. So that's maybe not so important for fingernail a sized light switch processor. But if you have a high performance system, you will be happy that you have this. Okay. These are the three that we kept from the originally slightly larger set. Of course, that doesn't mean that we cannot look at other ones, but these look like we should have them ready to use in our kit. So we need to assign values. And, again, all three should be recommended. Yes. So the plan is to get some good reviews, and we already have some good reviews. So there there probably will be a a new revision of of the draft within little time and revise until the the reviews ebb out, and then we will ask for adoption. So that's where we are. Any comments on that?

[00:35:10] **Ivaylo Petrov**: Good. K.

[00:35:12] **Mike Jones**: I have

[00:35:12] **Ivaylo Petrov**: for volunteers for reviews. Who has read the draft? Okay. Yes. Can we get some volunteers to review the draft? Okay. Thank you.

[00:35:31] **Carsten Bormann**: So we have So Emil, Alex, Hannes, Tiro, and I don't know your name. Chris. Chris. Thank you.

[00:35:40] **Ivaylo Petrov**: Thank you. Yeah. Okay. Okay.

[00:35:52] **Mike Jones**: Because I ask him.

[00:35:56] **Dmitrii Kucheriavyi**: K. Hello, everyone. Good to be here. My name is. I'm from EMT Atlantic, still a PhD student. And last year, I was presenting this work during the IETF 118 in Madrid, and there were quite a few interest about this idea. So for those who don't know, we have prepared a draft on introducing Ascon for COSE. And Ascon, it's a lightweight cryptography cryptographic suite. And since August 2023, it's standardized by NIST. And since COSE is designed for constrained systems, we feel like it's a good place to integrate Ascon and COSE. And since last year, this main blocker of that, it is not actually standard is gone. So now we find it even more pertinent to to to have Ascon and COSE. And we focus on the two main crypto primitives, Ascon-AEAD128 and Ascon-Hash256. It's important to have two of these primitives integrated because the main feature of Ascon is that it actually uses the single permutation function for each of its primitives and which will allow to have eventually very good savings on the memory footprint. And also Ascon compared, for example, to AS, it has a significant significant power power consumption efficiency also, which was perfect for embedded environment. From last year, last year's draft was mainly focusing on the Ascon-AEAD introducing three modes. The default one, Ascon-AEAD128 was a 16 byte tag, and the two versions was truncated tag to eight and to four bytes. And last one is actually important to discuss because it's in typical systems, it it is not really suitable for typical systems, but we find it still important to have it there to in order to satisfy, for example, very constrained networks where the end use can be very short and this four bytes of extra space can be can be crucial. We also presented examples and showed how how it's integrated in in the last year's version. So this was from the last year. Since that time, the draft has evolved, introducing the ask on hash to 56, and there are two main ways to have this hash function integrated. First, through the HMAC function and for COSE mark operation. We proposed two different versions in the with the default hash mark was two fifty six bit output output and with the truncated output to 64 bits. And, also, to have the full ASCON ASCON stack integrated, the new key duration algorithm was also proposed with h in as HKDF with as HMAC-Ascon. Since in COSE, from what we saw, there is no really direct way to assign an algorithm number to HKDF themselves. There are only ways to there are only algorithm numbers assigned to the to the usages of HKDF such as, like, direct encryption with HKDF or or the elliptic curve in two modes. So at the current version, we only kept the direct encryption plus HKDF with a SCON hash to 56. But to have a full picture in front of you, this is the to do list that we we believe is the is the full Ascon integration path for for this cryptographic suite. If I missed anything, let me know. And then yes. What's missing is basically to have HKDF with Ascon hash for elliptic curve and in both modes and have a standalone Ascon-Hash function as illustrated in RFC nineteen fifty four can be used just for indirect content signing, for example. Yes. And a couple of words about the hackathon where we participated. We we came up with a project to actually implement Ascon lightweight cryptographic suite over existing open source COSE libraries. You can find more details following this link. And what we've actually managed to do is to contribute to three open source repositories. I don't know if there are still contributors to the COSE working group because they see they're still maintain this library is maintained because the last change was, like, six years ago. But we we did a pull request over there, and we did to the and to micro score as well. Yeah. We will update this pull request later to to have the full full features implemented a bit later. And, yes, I I've left some time to discuss because there is there are yeah. It's it's all about discussion. We would really like we've we believe that Ascon has a place in COSE, and we would really like to have this draft adopted to the COSE working group. So, yeah, thank you.

[00:41:57] **Ivaylo Petrov**: Okay. I will start with my first question. Is are there people in this room or in chat that are interested in this work? K. I see people. That's good. Then are there people that have reviewed the latest version of this draft or the recent version of this draft? Okay. Somewhat. Few people. Good. Then I think we should get some more reviews. And, I guess, also for a better understanding, for now, you have an implementation, like, one implementation that you were working on?

[00:42:51] **Dmitrii Kucheriavyi**: Okay. So we did not implement Ascon itself. We already took the existing c library, and we just integrated in in the existing APIs of COSE libraries. We focused on the c language. So if somebody wants to tinker together on any other language like Java, Rust, etcetera. Yeah. Let let's let's talk about it so it can be interesting project. Okay.

[00:43:14] **Ivaylo Petrov**: Yeah. So, yeah, basically, you were working on kind of a demo that was using this?

[00:43:21] **Dmitrii Kucheriavyi**: Yes. Exactly. Like, that that was the part of the hackathon. We actually brought two underwater modems to to illustrate the exchange in the constrained environment. Because for us, it was important to show that, okay, we actually want to have the the four byte version with the Ascon and COSE to to show that empty restrictions are important, and we deployed one acoustic modem, second acoustic modem, put the stack. As the application layer protocol, we use the OS score with CoAP Mhmm. Which we use the COSE with OSCON. And, yeah, it was a fun project to do. The details, you can find on the description of the of the hackathon.

[00:44:06] **Ivaylo Petrov**: And do you have somewhere listed the improvements that you said it says a lot of computational power, memory, etcetera?

[00:44:15] **Dmitrii Kucheriavyi**: Unfortunately, we did not do any benchmarking yet, but, like, yeah, it it it can be it can be done later, of course.

[00:44:23] **Ivaylo Petrov**: K. Yeah. Hi.

[00:44:24] **Hannes Tschofenig**: I had a student working on this for DTLS, and, unfortunately, the performance is worse than the existing one because for the existing algorithm, you have had the acceleration. For this one, you don't. Mhmm. So that's a little bit of bummer. So the comparison is a little bit difficult to make, but but I'm sure that would change at some point in time when when chip manufacturers pick this up. Mhmm. And then it would be more realistic or maybe someone, as a project, creates an I'm sort of maybe not the hardware implementation. It would be an expensive hobby project, but an FPGA based implementation. Sure. Why not?

[00:45:09] **Tirumaleswar Reddy**: I have been looking into this algorithm as well. My understanding is it's designed for constrained IoT devices that don't have hardware based optimization for, like, AES being supported by hardware. Right? Is that true?

[00:45:25] **Dmitrii Kucheriavyi**: No. Not really. You can design it on the hardware, on the software, the way you want. Like, it's a monkey sponge based

[00:45:33] **Tirumaleswar Reddy**: No. The hardware that cannot afford to do spend cycles to do that, and you really want to do it in software. I don't know. I'm asking. No. I I would

[00:45:44] **Dmitrii Kucheriavyi**: say it's it can be. Actually, Ascon is designed in a way it actually saves the space on silicon as well. Okay. So it's also designed to be put on the hardware while we're saving space on the silicon. There is a paper comparing IS on the silicon and and Ascon on the silicon, and then they say it's, like, 30% of the IS space that is occupied with their implementation. Or yeah. That's good. Thank you.

[00:46:10] **Rikard Höglund**: Yeah.

[00:46:11] **Ivaylo Petrov**: Okay. Yeah. Thank you. Okay. So I think then the next step would be to get some volunteers to review this draft and, yeah, take it from there. Can we have volunteers? Christian? K. Can you say your name? Oh, quick. Thank you, Johannes and Tiru.

[00:46:38] **Rikard Höglund**: Thank you so much.

[00:46:39] **Ivaylo Petrov**: Thank you. Yeah. Thanks. And with that, we are at our last item for third revocation. I hope the latest site should be fine.

[00:47:10] **Rikard Höglund**: Yes. You saw the reservation, right, from today? Yeah. Yeah. Alright. Hello, everyone. So my name is Rikard Höglund, and I want to present this new draft about CBOR encoded certificate revocation management. And as you see, we currently have five quarters, and this is a version 0.0 submitted recently. So what this is about? What is the motivation for doing this? Well, we have C509 certificates in this other draft, and that makes certificate compact for constrained deployments. But certificates are only one part of PKI, right? So revocation information is still commonly represented as their encoded CRLs and OCSP messages. And the thing is that revocation data can be a significant bandwidth storage and processing cost. So to kind of have a good you know, PKI and a complete ecosystem, to have a compact certificate ecosystem that will be incomplete if you don't also have, compact revocation information. So what this is draft trying to do? We want to enable a compact manner to convey revocation information. And this is both for CRLs, which can grow large when you have a lot of certificates revoked and also for OCSB requests and responses, which are encoded in a particular way, but they could be encoded in a more optimized way in the interest of constrained deployments. And that's what we're doing. So what are the contributions exactly? We define C509 CRLs, which are natively signed CBOR encoding of X509 CRLs. We define C509 OCSP, and these are CBOR encodings of both OCSP requests and responses. And the solution that we're presenting its approach, C509 certificates, X509 certificates and also future certificate types. We're trying to apply the same compression principles as for C509 certificates, and we are not aiming for wire compatibility with their encoded CRLs or OCSP. So this is a new way to encode those CRLs and OCSP requests and responses. We also want to provide media types and co op content formats for these new encodings. So what are the design principles we try to keep in mind when doing this? First of all, we want to optimize for constrained implementations in terms of wire size, parsing logic, RAM usage and code complexity. But of course, we want to preserve the familiar revocation behavior, so the trust model and the purpose of revocation is just the same. We want to promote common information so that frequent extensions become first class field in our encoding. We also group repeated information once to avoid repetition and per entry duplication. We also did some optimizations to use constant size records where lookup speed matters, supporting direct access and a faster lookup. We also used uniform certificate identifiers to support C509, X509 and possible new certificate types. So having a look at I mean, we also asked this question like why not just do a more direct mapping to CBOR, You could do that. It would be more straightforward, but it would preserve many legacy structural choices. So any deviations we did from this straight mapping, those are deliberate engineering decisions guided by our design principles in the previous slide. So examples, some of these optimizations, variable length CRL entries, they become constant size revocation records. Repeating issuer identifiers, we instead group the issuer identifiers so it's only present once. Instead of doing sequential processing, we enable direct access and binary search. So looking at the, let's say, two key building blocks, starting with the C509 CRL structure, where we have this also in the draft in a CDDL. This is like a visual representation. Some things to point out. The issuer information is explicit and not positional. The same structure can represent multiple issuers. And we have this removed from CRL. Those entries are separated from the currently revoked certificates. And the CRL info data can be reused without carrying the large revocation list. So this is the overall structure. Obviously, how to use it is more detailed in the draft itself. But further points to highlight differences. Current CRLs, you have the implicit certificate issuer switching. In the C509 CRLs, you have explicit per issuer grouping. You have, on the left hand side, variable length revocation entries. In our solution, the constant size revocation records. For current CRLs, you may have to do sequential scanning for serial number lookup. In the solution we have, you can do binary search when the entries are sorted, which they may or not be and that can be indicated by a bit flag bit. For current CRLs, you have common values carried as generic extensions. And in our solution, you have dedicated fields for this frequent information. And, yeah, also in current CRLs, you may have large application lists needed even for metadata. We have split out the C509 nine serial infrastructure so it can be standalone. So it's a number of improvements, let's say. So why using these fixed length revocation records is because in their CRLs, the entry size can vary depending on the serial number length, time encoding extensions. In the solution we have, we fix the serial number length to date length and the base date so that each revocation certificate has a constant size. And, again, this means improvements when it comes to search and parsing. So that's the CRL part. Then we go to the C509 OCSP design. So again, looking at the current OCSP solution, you have sort ID that repeats the issuer field per certificate. In the C509 nine OCSP solution, we group the request and responses by issuer. In the current OCSP, you have plain serial numbers that reveal the current certificate. In the C509 OCSP, we use the serial number hash. In the current OCSP, we have the responder ID that uses these type specific choice structures. Instead, in our solution, we use the responder sort hash. And similarly, for the current OCSP, you have issuer identities using two separate hashes where we have one issuer sort hash. And some further details to mention, yes, the certificate serial numbers are replaced by a serial number hash. And this also means that passive observers cannot identify the create certificate without already knowing the serial numbers. The issuer, requester and responder are identified by certificate hashes. And the signature algorithm is covered by the signed data, and the requester or responder certificate chain is covered by the signed data also. So this is the C509 nine OCSP design. And, yeah, the current table of content, this is what we have today. So, yeah, introduction terminology, but then you come to the section five where we define the C509 nine CRL, its CDDL and the actual field encodings and the logic of how to process and use it. So that's one part. Then we come to Section six, which is C509 OCSP, defining the OCSP request, the OCSP response and some further information and details on how to use this, including using this for stapling in TLS. We have Section seven defining some hash algorithms. Then we have the normal section security considerations, ION considerations, etcetera. We also have a lot of examples examples of encoded OCSP request responses or CRLs. And we also have statistics in terms of size comparisons. So if I go to the next slide, you can see the size reduction. So this is with regards to CRL, four different examples for CRLs. And you can see that, I mean, depending on the exact scenario, we may reach 18% to around 50% size reduction. And then looking at the OCSP request response size reductions, again, we have a lot of examples and you can see more details in the draft, including the actual values of the data, the bytes themselves. But generally, we may reach 40% to 60% to 70% size reduction comparing the current solution with our C509 encoding of the OCSP requests and responses. Yeah. So next steps, what do we want to do? We want to confirm this design direction in COSE. We want to discuss and explain a bit more this point I mentioned earlier, the optimized encoding versus direct mapping trade off because, again, direct mapping would be more straightforward, but we would like to do something more clever to actually optimize these sizes even more. And by the way, we have further ideas also, so we may be able to do even further size reductions. We also want to make prototype implementations, looking at a transport mechanism for those three speed data. Yeah. Refined IANA registrations, media types, and CoAP content formats, add some security considerations which are currently missing. And, yeah, of course, any reviews or comments are very welcome. We would like to get feedback, from the group about this. Yeah. But to summarize, what we're trying to do is a new way to encode CRLs and or CSP requests and responses in a more optimized manner adapted for constrained devices.

[00:57:29] **Hannes Tschofenig**: Thanks for the work. It seems logical after the the work that was done in the group to do the certificate compression to then look at the CRLs and also the OCSP. The question I have is in I haven't seen in a constraint IoT space where this mostly would apply to anyone using an either CRS or OCSP, but instead they had to deploy their certificate management and then their device management solutions. And so the whole setup was a little bit different, and I wanna how this would be? Could it how does sort of how you see that working? And specifically, like, for those who would really like to go that path and and basically ignore the device management approach, wouldn't they go and take a leap and take, for example, this the status list instead, which provides more properties. Like, it provides better properties. You like and there's this is very recent work. So that could be like, deals with some of the disadvantages of CRS and OCSB. So

[00:58:52] **Rikard Höglund**: Yeah. I mean, good question. Like, I like, why people are not using these for, like, CRLS and OCSP for constrained devices? It may be that what we're doing now may enable some people to use it that are currently not using it. And I would also mention this, the actual main author of this draft, Lijun Liao, he's I mean, I understand that they they have some interest in in doing this in terms of, like, there are actually people who want to use it. But I think you have a good point. We could have some, let's say, section or some more considerations comparing to other existing solutions.

[00:59:26] **Hannes Tschofenig**: Yeah. Because I I don't think I don't think people sort of don't use OCSB and TLs because they are too large and they say, oh, we can't do it and that's why that would be, of course, great if that's the that's indeed the reality. But I think they have a mechanism already, namely because they have to do they talk to on one server device management. Most of the scenarios are really this cloud this device to cloud sort of communication, and they they have already a pipe. So whenever they want to deal with changes of certificate revocation, etcetera, checking the status, they can just, like, do that in as in band, and that provides some benefit. But it might be worthwhile to check back with with some of those companies to see whether that's really a valid approach and whether that's really what they, what their thought process was, which, we kind of all second guessing.

[01:00:26] **Rikard Höglund**: Yeah. I mean Cool. Yeah. Is a good point. Like, I don't have that insight. Like you said, they have some existing channel. There's an existing pipe. They have an existing solution. Or then on the other end, some may be interested in this, I think that's something to explore. Like, what what would their feedback be on this, and what would we be able to say if we compare to such kind of solution. You know?

[01:00:49] **Ivaylo Petrov**: Yeah. And, Yaron?

[01:00:55] **Göran Selander**: Yeah. Hello. Yaron, an under. So, yeah, I think this is this is great work. And as as Hannes already mentioned, it makes a lot of sense to standardize these the revocation given that you have already standardized certificate format, the certificate request format, the certificate request template. So so location formats also makes sense in this context. And that's actually it was part of of a previous charter for for Cozy. And when it was removed, it was not because this was out of scope, but it because there was sort of reformulation of of the charter text. So it it's it's somehow already in charter. And then as to what is the most efficient way to to handle revocation in in these systems, I mean, there there might be multiple ways, but and, unfortunately, Lijun is not here to to answer and who is the main driver of this. But having worked with Lijun for for one and a half years now for the base C509 specification. I know he's very focused about on the industrial deployment. That's basically his scope. He's using C509 in in their connected car. I mean, it's working for a money car manufacturer, and they're using C509 in this connected car setting both in device and device to cloud. So but that's I think that's a really good question from Hannes, and we should continue to elaborate on on what are the gains, And that's something that the authors should should explain. So I'm supportive of this work. Thank you.

[01:02:47] **Ivaylo Petrov**: Thank you. Thank you. And this, yes, brings a very good question. We'll have to double check. This is in charter of the working group. It's kind of feels it should be, but I would like to double check this. And, yeah, it also sounds like a very logical continuation from C509. But, yeah, I would also like to see what is the industry kind of interest into that, elaborate a little bit more on that part.

[01:03:25] **Rikard Höglund**: Yeah. That's a good point. I mean, like, I mentioned, we have Lijun Liao. He is from this NIO car manufacturer, so I understand they have, you know, industry interest, but that's, of course, like, one single voice. So we can investigate this further.

[01:03:37] **Brian Sipos**: You know?

[01:03:40] **Ivaylo Petrov**: Thank you. Thank you. And, yeah, and people interested, please review this document and share your feedback. And with that, I believe we are at the end of our agenda. Is there anything people want to talk about? Any other business? I don't see anyone. Okay. Well, maybe someone is coming. So, yes, Chris? K. Well, I see. Okay. I see

[01:04:29] **Chris Lemons**: Chris Lemons.

[01:04:30] **Ivaylo Petrov**: Oh, I okay. I see also Christopher Yes. Is

[01:04:34] **Chris Lemons**: Chris Lemons. The a couple of IETFs ago, there were a number of folks in this room, the names of which I just checked. We actually wrote them down who volunteered to read and provide feedback if they had any on the composite claims draft. Two people have done so. Neither of those two people were on the list. So bonus. If you are one of those people who is interested in reading and, providing feedback on the composite claims draft, I would love to read your feedback. I have received a fair amount of feedback from people in person who I have asked to post to the list so that you can see their names, their identities, and the fact that they care. And I've even provided some updates based on their based on their feedback. But that work is still live. It matters. It's important. I don't wanna take a whole lot of meeting time up about it. But if if you would like to see composite claims in CWTs and especially if you are interested in the MoQ work because it is a normative dependency on important things in the MoQ authorization model. So if you care about MoQ, media over quick. Sorry. I forget. Media over quick. If you don't know what MoQ is, you might not care.

[01:06:11] **Ivaylo Petrov**: K. And Thank you. Our AD. Yeah.

[01:06:15] **Roman Danyliw**: So I am most of the way through the HPKE draft. Mhmm. But I will note that the JOSE HPKE has gotten tied up in its set of algorithm selection, in that it wasn't actually fully coherent, and then you couldn't actually implement all of the, functions in it because they didn't have the right combinations of of, encryption and and and max, so it's going back. The question is really, so I'm mostly sitting on it, waiting on that a little bit. How much alignment does does do all of you want between the COSE and JOSE HPKE? I will note that I have noted the differences in out in, you know, particular algorithm selection. So that's

[01:07:13] **Ivaylo Petrov**: kind

[01:07:13] **Roman Danyliw**: of the question and and that Jose one is really kinda gonna take a fairly long round trip as they fix that up.

[01:07:23] **Mike Jones**: So speaking not as a JOSE chair, but as an editor of both of the drafts. In JOSE, we sorted that. Deb and the chairs, one of whom is just behind you, told the working group that we had removed the two key establishment algorithms using ChaChaPoly because there was no registered ChaChaPoly content encryption algorithm. So it didn't make a lot of practical sense to have a ChaChaPoly HPKE key establishment algorithm. So those were pulled out of the JOSE algorithm set. We did not pull the corresponding integrated encryption algorithms. And, I mean, you could talk to Deb, but that's closed. We're done. It's back to the ISG for approval now. So there's not the degree of churn that it seemed like there might have been. In terms of, it's a different situation. We do have registered ChaChaPoly content encryption algorithms for COSE already. Therefore, the motivation that applied in COSE to remove those two key establishment algorithms doesn't apply here. The algorithm set other than those two removals, to my understanding, is aligned. And Hannes can speak to that perhaps. Thank you.

[01:09:18] **Hannes Tschofenig**: Yeah. The it seems that different groups have a very different appetite for registering algorithms. We just had that discussion earlier. Like, if you had brought the algorithms we discussed today to the JOSE group, they were would have freaked out, because they for some reason, more algorithms is a sort of earth shaking event for them. And so there's there's always this reluctant like, we could probably imagine a specification like retrofitting one new algorithm like ChaChaPoly into an AYANA table, but that's a stretch for a different group. Right? And so so that's why we had that discussion. We removed it. And maybe in a few years, people would say, yeah, we we actually need Cha Cha Poly also in in JOSE. Here in in in JOSE. Yeah. In in in this group, it's it's different, but the underlying design is very similar because the we initially started the work on HBKE in COSI first, And then we took some of the concepts because, obviously, some of the deployments that use Cozy and JOSE are sort of, like, intertwined and often the same developers, etcetera, etcetera. So, yeah, sort of makes a lot of sense to think about the same issues and and, obviously, adjust them accordingly as the the encoding format. Karsten gave a great presentation yesterday on the serialization, if it if it differs JSON versus a binary encoding and so on. So yeah. So but I hope, as Mike said, that this is actually moving forward relatively quickly. There are no shop showstoppers along the way anymore. Has taken us some a while to get here given that we are using an algorithm and dump it into another format would seem like a totally trivial thing,

[01:11:25] **Brian Sipos**: but then it isn't. Okay.

[01:11:29] **Roman Danyliw**: So, I mean, the conversation I had with Deb as we simultaneously reviewed the drafts was I paused somewhat in order for that to be resolved in case it there was any ripple between them. So what I'm hearing, and anybody's welcome to come to the mic and say otherwise, I will advance it in that you guys do collectively do not intend any kind of change to algorithm registration or anything else. K.

[01:12:02] **Ivaylo Petrov**: Oh, okay. I thought there is someone on the queue, they seem to have given up. So with that, is there any other business? Anything else to discuss? I hear nothing. So thank you very much. With this, this meeting is over. Thank you.