Session Date/Time: 20 Jul 2026 09:30
[00:00:41] Chairperson: Okay. Let's go ahead and get started. Tthis is the ACE meeting at IETf-one twenty six, and we have the note well. Tthis is just Monday, so you may not have seen tthis yet. By being here, you've agreed to all of the following policies. Please read them all and understand them before you participate. And then the agenda to do we don't have the agenda on the chair slides tthis time, but it is going to be the CoAP pub-sub profile first, followed by workflow and params and OSCORE GM and KEM, all three by Marco, and then the EDHOC and group OSCORE profiles by Ricard. And then at the end, we'll have the EST for C509 presentation. Any agenda bashes other than the few issues that Marco pointed out earlier to me earlier? Alright. So I guess, Marco, you're up first. And let me see if I can find your slides.
[00:02:17] Marco Tiloca: Yeah.
[00:02:19] Chairperson: Let me let's see if I can assign it.
[00:02:44] Marco Tiloca: Well, that works. Thanks. Hi, all. Tthis is Marco. A quick update on tthis pub-sub profile of ACE and on version five. Yeah. To recap, tthis is an application profile as an instance of RFC ninety five ninety four for distribution of key material for communication using ACE. And here, considering in particular the CoAP pub-sub architecture specified in a core document. So as a road mapping, you have the ACE client as the publisher and or a subscriber. The resource server is the broker, and there's also another resource server, the key distribution center distributing the keys in questions. And there's two access tokens involved that the client can request from the AS One to be uploaded at the broker for the sake of publishing and subscribing the topics. One of the KDC finally aligned with ninety five ninety four for the sake of getting key material to participate in the secure end to end pub-sub communication. So what happened recently? The working of was completed early tthis year and a version addressing those comments, version three was present remotely in Shenzhen. Then as discussed during that meeting, a version for follow that was that is addressing now some points that were raised also in Shenzhen. They were mostly comments that we would expect to receive if not addressing them already. Since similar comments came during the IESG evaluation of another IESG document essentially analogous to tthis one, the other application profile for distribution of group keys. Most of them were from a ballot of Dave and and a few other ones kind of editorial related to clarifying requirements. And we also added, as mentioned in Shenzhen, a statement that was implied all along, but still it it's a clarification clarification compared to the generality of the CoAP pub-sub architecture specified in the core document. And some minor fixes are on the way. And version four has been out since shortly after the Shenzhen meeting. So after that, in call, we finally managed to request publication of the pub-sub architecture specification that was essentially keeping tthis this document on hold. That's now sent to the IESG. And I published a new version of tthis ACE document before the cutoff, essentially making some editorial fixes for, yes, straight alignment with little things that changed before the publication request of the core document. And it's really peak alignment on some last minute fixes that were done to that I tried to summarize here in the slide, but really no breaking or or software than than breaking changes at all. In the process, I noticed that two parameters that were well defined and used already were locking the corresponding registration section that I added. So it's now there. So considering the the blocking reference sent to the IESG and all the content, hopefully, here already, tthis document should now be ready for the Shepard review write up.
[00:06:03] Chairperson: Alright. Any questions for Marco on tthis quick update? Alright. So up next is the workflow in params. Let me find the slides.
[00:06:50] Dave Robin: Alright. I
[00:06:50] Chairperson: think that was all the correct clicks.
[00:06:52] Marco Tiloca: Yeah. Thank you. So tthis is the document. Proceeding well, I'll say, and now in version eight. Yeah. A recap of the on the scope. Tthis is intended to formally update r c ninety two zero zero as the main RFC defining the ACE framework and a number of other documents related to ACE for minor reasons instead. Yeah. The main contribution is definitely the definition of the new SSTC alternative workflow where the authorization server uploads the access token at the resource server on behalf of the client at the ultimate discretion of the AS. And we are also introducing a number of additional parameters mostly for the sake of, yeah, addressing the request of tokens for group audiences. So in order to provide the client in a single response from the AS with multiple authentication credentials of resource servers and naming the participants in the group audience. Also, extending the semantics of tthis profile parameter as discussed a couple of years ago already. And beyond the additional parameters, we are also defining a bit better something that was a bit of a gap in ace so far about how c and and the ace can coordinate on exchanging the relevant authentication credentials by value or by reference. They started to emerge in a number of recent profiles. A newer code, and we are deprecating the original ace error payload for using instead the better format in RFC ninety two ninety and minor amendments to requirements. Endoscope is unchanged, by the way. It's still about tthis many things. So what happened at tthis last round apologies. Bear in mind that that the latest version of the draft has some remnant from my editorial processing where I say with value zero or two in a couple of sentences in those section. Those sentences should really end with value zero. I'll fix that in the next version, of course. There were minor fixes in the IANA considerations, mostly editorial and also noting that other documents have recently added new entries in some registries. Those entries also deserve some additional references and information in there that are coming from tthis document. Tthis is now notated the Yana consideration section. During the Shenzhen Meeting, Dave Robin, thanks again, recommended re rephrasing some text about, well, that. I did my best to disentangle, I would say, what is on one hand including or not. And on the other hand, if included, what it must not, should not be, and why. So it's still the same same reasons. Hopefully, it reads better now. Let me know otherwise. Thank you. Okay. I noticed that when introducing and defining the new SSTC workflow, there was some gap in giving practical guidelines and recommendations on what to do if the client is also interested in using the service defined in RFC ninety seven seventy on the notification of revoked access token. In the new workflow, the client has basically the option to to request the authorization server to get the access token by value as usual anyway even if if the upload that the RS succeeded or instead only the token hash or instead neither of the two calls just fine. Well, yes. However, if the client plans to benefit of the service of ninety seven seventy, at the very least, it needs the token hash or the excess token to copies to compute the hash itself. So it doesn't make sense in that case to go for the neither indication because then it would not be possible to use that service. Just a clarification. As I mentioned during the Shenzhen meeting, I noticed that the previous version of the draft was wrong in a wrong way coupling together two parameters that are actually fully disjoint. These two parameters are intended. We're using the new workflow for the client to give to the something to relate to the RS when uploading the token, and in the other direction for the AS to relay back to the client parameters produced by the RS. And the latter has really nothing to do with the former and can be totally disjointed. And now that's the case in the new text. Okay. More around that following section. I noticed that we're all also an under specification in the previous version on on what to do in the case where the access token is requested to be issued for a group audience and what it means in terms of the AS posting that access token to each and every of those resource servers in the group audience, when it should stop, and how. I I prefer to write down a proposal as a first thing, but in in in my initial view, the AS just proceeds sequentially through the resource servers in the audience. And as soon as there is a failure, the whole uploading on on behalf of the client is declared failed. Or or in other words, it's it's a success even though they've every single upload succeeds at each of those resource service. We can think more about it if we find something fancier and more complicated, but tthis looks good enough at least to me. We added a new section nine where we define an an extensive EAD item for the protocol in relation to the EDHOC-OSCORE profile base that Ricardo would present later. Tthis EAD item was initially defined in that other document the finding the EDHOC-OSCORE profile base. And we preferred instead to move it out from there, bring it in here because its main benefit comes up when using the alternative workflow defined in tthis document. In fact, so if the alternative workflow is used and it succeeds, you practically won't end up without giving the access token to the client at all. But when using the EDHOC and those core propeller based, the client will still have to upload the access token to the RS, but it didn't get it. So at best, it can send an identifier of that. And the idea is to to use tthis alternative ID item exactly for uploading a reference to the access token or the access token by reference if you want. We had a lot already in the other document, so it was pretty much about moving and adapting it to to read NICE in the context of tthis other document instead. Again, its main application is in the context of the new workflow, but in principle, it can also be used for a possible optimization even in the normal workflow. For example, in case of executions. Something that was noted already in in version six. I have just have to bring bring up some background here to understand the next slide. We identified some time ago a special case where the client asks for an access token for the dynamic update of access rights. The token is issued and per the alternative workflow, DES uploads it to the resource server. And that upload fails because of a very specific reason. The resource server dropped the token that's supposed to be replaced. So tthis is not the end of the world that upload failed. The the AS would give back the issued access token to the client for the client to try. The client will try and we know for sure they will fail because having the RS dropped their access token, it also terminated the secure communication association. The client's upload would fail. And at that point, the client can really give up and ask for the access token altogether. Fine. We realized we could do better than that, which is what we added in tthis version of the draft. And, again, in tthis very particular situation, as it was somehow hinted by by Dave again, DAS can create a new token series on the fly. So something went wrong with that upload. That series is gone. It cannot work. But rather than wasting more round trips, the AS in tthis particular situation can create a token series on the fly, essentially aligned with what the client was trying to do already. It's just a new series starting with a new token, and we'll give that token to the client. And the client will just follow the regular procedure by the book that you do for the case of the first token in the series. Tthis is the gist. It may look a bit dense in the slide. Please check the draft. There's a dedicated section about that. I think I'm done with the draft updates and my broken record moment. We have seven open in errata against r c 9200. Please review. And most of them are about examples, so it shouldn't take long.
[00:15:56] Chairperson: Here. Let's see let's see if it works better if I say it. Everybody, please review the open errata and 90 to 200 and provide some feedback. Thank you. Thank you.
[00:16:08] Marco Tiloca: Yeah. Next steps. I have to fix the sentences. Sorry about that again. And, definitely, we need an example of message exchanges related to the upload of an access token with a new workflow when it is about updating access rights, preferably showing also that particular case that results in creating a new token series on the fly. We still have an old issue that Christian opened quite long ago. Actually, we still have to get on that giving more guidelines on the use of one of the new parameters in particular when group audiences are involved in issuing the token. We have to extend the security considerations a bit and consider the addition of the operational consideration section. Until then, comments, reviews, anytime are welcome. Thank you.
[00:16:54] Chairperson: Thank you. Any questions on tthis one?
[00:16:57] Marco Tiloca: Dave.
[00:17:03] Dave Robin: Hi. Dave Robin. Of course. Yeah. A couple questions. I I love that you're right about how the new on the fly has a a very good write up, very long step by step, very well written. Question is, is it actually required? Because right now it says, if it supports the SSTC work, then it must store the token. Blah blah. The implication is that it's required behavior. Although what you're saying is it's kind of a nice to have. I'm just trying to when I adapt tthis over into my spec, you know, I I don't want to leave out something that the RFC said was required and then have someone ask, hey. You made it optional in your spec. Why is, you know, why is it optional? So for those that don't know, I'm I'm I take tthis work and adapt it to the BACnet spec, and it's a it's a translation. It's not literal because, you know, we use ASN. We use our own services, all that kind of stuff. But I try to map it as much as possible. And so tthis is a a neat behavior, but do you intend it to be absolutely required or is it optional? Because the client can certainly recover. Let's just
[00:18:10] Marco Tiloca: Let me reply in just that, for DAS, it's optional to support any workflow, altogether. Right. If it does, the idea was to have tthis as as a must support Okay. Feature of it.
[00:18:22] Dave Robin: Okay. Okay. I just wanted to make sure because that means it also requires you to store the token's original form for as long as the series lasts, and that might be a really long time. You know, a really large number
[00:18:34] Marco Tiloca: of requests. You don't need to store the original token. You need to store the original request that produced the original token, and you are doing that any way you think about it to enable the up to the access rights and to preserve the same audience in the same month.
[00:18:47] Dave Robin: If if yeah. I do wanna make sure I wasn't misunderstanding that it's required. Great. Great to decouple RS to RS and from RS because I never thought they were coupled in the first place. So great. I'm glad it's formal that way. And the the final thing is for group distribution, it says that the AS stops at the first failure and returns the error. But great. Okay. Does it have to? Can if it receives the identical request again based on the client knowing that a Daveice is now online, can it resume? Is it allowed to is it allowed to remember the ones that succeeded and fill in the one that failed, or does it literally have to stop and forget everything and start again from the beginning? Maybe I'm
[00:19:32] Marco Tiloca: I'm thinking that the poor client is waiting for an access token response, and the token was issued. So if the upload No.
[00:19:38] Dave Robin: I understand that the oh, okay. He
[00:19:41] Marco Tiloca: gets So something went wrong with tthis optimization of alternative uploading. Okay. You you just cut it short. Give the token
[00:19:48] Dave Robin: You can't say tthis is what I will send, but don't use it yet because I haven't sent it. So it's just a knack, and you have to start it.
[00:19:55] Marco Tiloca: Well, I tried. I fail. And let's forget about the details. Here's the token. Good luck.
[00:20:01] Dave Robin: Well, I
[00:20:03] Marco Tiloca: That that's the group audience you asked the token for.
[00:20:05] Dave Robin: That's partly it. I'm I'm kind of wanting to it's like you I succeeded to 99 out of a 100 Daveices. You know? One guy is offline. Then just tell me that, but let me proceed with that access
[00:20:19] Marco Tiloca: token to
[00:20:19] Dave Robin: the other
[00:20:20] Chairperson: nine Okay.
[00:20:20] Marco Tiloca: An option can be a a new parameter to make the list of the successful areas.
[00:20:25] Dave Robin: Partial partial success is possible. Let me know. Okay. But just just a band because one Daveice is offline, I can't distribute it all. Seems kind of rough.
[00:20:35] Marco Tiloca: So We can give an indication to the client of of make that. Which RSS that succeed and which not.
[00:20:40] Dave Robin: Maybe. Yeah. Right. Okay. That's it.
[00:20:43] Marco Tiloca: Thank you.
[00:20:48] Participant: Because then I'm just indicating which file precisely failed might even be excessive because if there's an indication yeah. I tried. I failed with some. Here's the token. Just go with like, try it. And if you find that it doesn't work, here's the token that you can submit.
[00:21:03] Marco Tiloca: That's the current approach.
[00:21:04] Participant: Okay. I'll and piggybacking on the on that, in some situations, like, abort, if one fails, might be overly prescriptive if the management of the group is something that is tightly coupled in here. There might be situations where a failure just indicates that that item is removed out of the group. So please make sure that the well, please look into whether that is something that can be at least described as tthis is not necessarily a failure because there might be changes to the group as tthis is progressing. Sure.
[00:21:33] Marco Tiloca: Thanks. Thank you.
[00:21:43] Chairperson: Alright. Looks like we're ready for the next set of slides.
[00:21:46] Marco Tiloca: Yep.
[00:22:12] Chairperson: Now you should be good.
[00:22:13] Marco Tiloca: Thanks. Okay. Tthis is a brand new document, and it's tightly coupled with another, brand new document, to be presented in in core, on Thursday. And it's about distribution of group keys with days that we are doing already, but, yeah, with some extension to cover the coming post quantum. Nope. Yes. Okay. As some background, we are using the Group-OSCORE security protocol to protect group communication for co op that was Daveeloping core. And we started to wonder if Group-OSCORE is quantum resistant. And thinking through the details, it has two modes of operation. The group mode is at the end of the day, it uses signatures and okay. Use a quantum resistant signature algorithm, and some are already registered in COSE. And in that sense, you are done. It's a bit more tricky with the pairwise mode where you don't have signatures and security and message protection is purely achieved with symmetric material. But those pairwise symmetric keys are in turn derived by the peers using those from a shared secret that right now is derived through the as a pairwise key agreement. So, clearly, we have a problem, And there is no equivalent immediate drop in as of the h 90 that they standardized that can just replace the today. So to fix tthis within, we need something different like in space of KEMs. Yeah. About tthis precisely and for group of scoring itself, as I mentioned, we have a brand new document to be presented in core later tthis week that is try is trying to fix tthis essentially opening for different key agreement algorithms that are based on KEMs instead without any other change whatsoever in the use of pairwise mode itself for the message protection. Now that proposal already take advantage of the fact that to use Group-OSCORE, you also rely on the concept of group manager entity responsible for the group that among other things is also already taking care of collecting and distributing among the group members the corresponding authentication credentials with public keys. And the idea is to take advantage of tthis same entity also for the sake of facilitating the exchange within the group members of information like KEM public keys, a KEM ciphertext so that they can practically use a KEM as a as key agreement algorithm. And we are intentionally living life for other things already, the real details of how that happens at the group manager at the particular realization of group manager. But at some point, one of these particular realization has to come up. Now we do have in tthis working group a particular realization of group manager is the document that hopefully will soon enter in the RFC editor queue as an application profile of our c ninety five ninety four, defining the ACE based group manager for group Oscore. And, of course, in the approved for publication, original design was not considering any of tthis. So the contribution is about taking that a space group manager as is soon to be published and extend its interface to essentially provide a few additional operations through the same fundamental interface for the sake of facilitating the exchange of KEM ciphertext and KEM public keys. I ended up maintaining tthis term KEM based group just to indicate an OSCORE group where the pairwise mode used is used and and in particular, KEM is used as pairwise key agreement algorithm. Already in tthis version zero, I I really did my best to to present and organize the content as much as possible in the same style, rationale, or structure as the existing document describing the group manager adopted. Yeah. It's a bit about updating existing operations at that group manager and about defining brand new ones through new entries in interface, essentially. When it comes to updating, there is a token transferring to the other input at the group manager, and it was already possible in the old realization to exchange parameters between the joining node and the group manager to learn more at that point about how the group works. Well, it's about defining a new parameter here so that the join node can request and obtain information descriptive of how the group works when it comes to the particular key agreement algorithm based on cam. There's equivalent extensions also about the the join request and the join response. And in the join request already, so before being a group member or about to be, the join note can already take the opportunity to upload one of its public keys. And the join response can, on the other hand, provide descriptive parameters of how the group works, blah blah blah, and how many can public keys per group member at most the group manager is meant to store at the same time in tthis group. On new operations instead, at a high level, it's it's fundamentally and as expected about four things for a node as a group member to be able to, one, upload a public key of its own to be used by any and exactly one other member in the group, fetching the KEM public key of another group member for the sake of producing a KEM ciphertext for that group member, uploading such KEM ciphertext intended for another member of the group. And you won't see from the other perspective, retrieving the KEM ciphertext computed by another group member for itself. And each of the four operations are mapped into one new resource defined at the group manager, again, in the spirit of the same interface we have already. Tthis is all extension. Yeah. Number one of a new resource, node specific where that node can upload a public key of its own. As long as it reaches the limit enforced by the group manager, it can keep uploading more, and they will be popped out when given to another group member. It can also check how many of those there are or flash those. And and symmetrically, it it can instead request the public key of another group member indicated by OSCAR sender identifier. That's the gist. Third and four are about the ciphertext. So you can upload the ciphertext that you computed for for another group member indicating together with the ciphertext, the sender identifier of that group member. And for now, a hash based identifier of the public key of that group member that was used to compute the KEM ciphertext. And used by that other group member, operation four would be fetching a KEM ciphertext that a certain group member left for the requester together with the hash based identifier of the KEM public key to use. So tthis is, in essence, enabling the circulation of tthis information that makes it possible separately for group members to run a KEM and ultimately derive those pairwise keys. Yeah. The the big structure is in place already, and I tried to cover the the noncorner case for now giving already examples of message structure and exchanges and extending the the interface up to tthis point. There's more to cover. You have a particular case that the previous RFC to be already covered. You may have a group that uses only the pairwise mode. That requires some additional careful handling you need before joining to obtain something related for the group manager somehow to run cam with the group manager for the sake of mutual proof possession during the joining. So I've not written tthis down yet. I I prefer to cover the easy part before, but tthis is really the immediate next step. And we have another document also in the RFC editor queue defining for the same group manager and alternative admin interface that administrators can use to create, configure the group and so on. Possibly, nothing yet another document, but in tthis same one, I can easily extend that admin interface probably only in terms of a few more parameters, really, for the sake of configuring the support, for tthis too. And these are the immediate next section, that I imagine, for tthis document. Thank you.
[00:31:05] Chairperson: Alright. That's a big one. I'm gonna enjoy reading that carefully. But, yeah,
[00:31:13] Rikard Höglund: I know
[00:31:13] Marco Tiloca: you and the the content is is self sufficient for an understanding of the whole thing and the reading, I hope. Yeah.
[00:31:23] Chairperson: Given that it's pairwise, a transition would be darn close to impossible. So you're you're are you likely to be setting up an entirely new, quantum safe group and and just transitioning people over?
[00:31:42] Marco Tiloca: At some point, non post quantum groups should just not exist anymore, and tthis makes it possible to do that.
[00:31:49] Chairperson: Yeah. No. That's what I think. You would never actually try to transition an existing group. You would just set up a new group.
[00:31:54] Rikard Höglund: Oh,
[00:31:54] Marco Tiloca: oh, of course. Yeah. Yeah. The the group has just to be born that way. Yeah.
[00:31:58] Chairperson: Yeah. Okay. Makes a lot of sense. Alright.
[00:32:01] Marco Tiloca: Thank you.
[00:32:30] Chairperson: Tthis the right one?
[00:32:32] Marco Tiloca: Yes. That looks correct. So hello, everyone. My name is and I will be presenting some updates to tthis work on the EDHOC-OSCORE ACE profile. Oop. I one second. Of course.
[00:32:50] Rikard Höglund: There you go.
[00:32:51] Marco Tiloca: K. Excellent. So, yes, an overview what tthis is about. Well, it's a profile of the ACE framework. So we're using EDHOC for key establishment. And we also upload the access token in an EDHOC EAD item as part of the EDHOC session execution. And then following EDHOC, we use OSCORE for the secure communication building on the key material that was created from the end of execution. And you can see basically the workflow here, you request a token, and then that is posted as part of the EDHOC execution followed by OSCORE to actually protect the communication. And we also support the reverse EDHOC message flow. And then to go over some of the main updates that we've done now in version 11. So first of all, we've clarified when an audience should be included in the case that sees performing update of access rights. And just to mention that a number of these points are from a review from Christian Amsüss, so thanks to him. Now we simplify tthis a bit to say that you should always include the audience if it was included in the original request for the first access token in that series. And if it is included, it must have the same value. And tthis was simpler than what we had before, where you also had to look at the value of the session ID parameter. We did a number of editorial improvements and general fixes. Further point we did was clarify the meaning of prescriptive and non prescriptive parameters. So basically, have tthis EDHOC information object that the AS produces to instruct the client and RS on how to execute EDHOC with each other. Some parameters in tthis object are prescriptive, meaning that a peer must comply with what is indicated and abort the session if it notices the other peer is not complying. Some are descriptive, yeah, well, nonprescriptive, meaning that they're just general information like, okay, tthis peer supports these EDHOC methods. So it can be a set of methods. Obviously, you don't I mean, as long as you then use one of those methods, are aware of what other peer support. So it's more informational. But now that's clear in the draft what we actually mean by these terms. Yeah. We did one change actually for the reverse message flow. In the past, you could actually put the access token either in message two or in message four. But we thought about that and decided that let's simplify tthis so you can only put the access token in message four for the reverse flow. And the reason for tthis is that EDHOC will only protect against passive adversaries if the access token is in message two. And that means that basically, the AS would always have to encrypt the access token to provide sufficient protection because the AS doesn't know what if it's the forward flow, the reverse flow, and it doesn't know if the token will be placed in message two or four. So thus, we removed the option to transport access token in EAD2. It's simplification in both for the draft itself and also for like of the AS. We have some more considerations now on the timing of the access token request when using EDHOC in the reverse flow because it's important that the token is bound to the same client credential that is used in the EDHOC session. However, a client typically only learns that credential after receiving message one when you can actually see what credential is being used. Now if the AS is already known, the token request can be sent by C after processing message one because then the client knows the credential. But if the a s the a s two use or a s two contact isn't even known, then the client actually has to wait even after processing add up message three to do the access token request. But these are kind of clarifications and like help for a reader to understand how things function. We also have a clear definition of when proof possession is achieved, just stating that in kind of more straightforwardly and more clearly and in a better location also. We have a number of updates actually about new EAD items. So we introduced three EAD items. One is the actual ACE Auth access token. Mean, the EAD item where you actually place the ACE access token during an end of execution. We also have credential by value to signal to the other peer that I would like to receive the credential of that peer by value and not by reference, which is useful if you don't have the credential. Right? And then we also have the idea item request creation hints, which functions as the normal ACE request creation hints, just that it's part of an idea item during an EDHOC execution. And, well, we have now clear and simpler naming. We revised the format and style of the definition and picked some CDD annotation that didn't validate. And one thing we did, which Mark also mentioned, is that we removed the the item session ID. It is now instead in workflow and params. Yes. And we also added operational considerations section, initial version at least. So now we have two parts of it, which I will actually cover in the next slide. So the first part of the operational considerations are considerations for when the RS belongs to multiple audiences with different authentication credentials. So an RS may support multiple edoc cipher suites and edoc methods. In that case, it's good that the RS belongs to one audience for each of its authentication credentials because that allows the RSNC to distinguish which credential to use. Otherwise, it can be ambiguous. Another point we clarified is that it's important to keep the information about C and RS up to date at the AS because the AS produces and sends tthis EDHOC information object to the CNRS so they know how to run ADOC with each other. But if the capabilities of CNRS change, they are reconfigured or something changes, then it's important that the AS is kept up to date regarding tthis so that it can produce an accurate ADOC information object. We have more message exchange examples with improved notation and details. And we also added one more figure for tthis, what we call the non sequential workflow, which is the workflow where you're actually using the request creation hints, EAD item. So the client doesn't initially know like which AS to contact. Yes, we did some updates on the confirmation methods. We aligned the C5B method with the CBOR encoded search draft. We also did some fixes in the description of three other confirmation methods. We did some updates for the profile requirements just to make it clear that we are, in fact, defining one new EAD item, request creation hints, that is a method for the client to discover permissions and AS for accessing a resource. That's part of the profile requirements. Yeah. Another small thing, we added some references to the IANA registries we didn't have before. What are next steps? I mean, next step we had noted is that if you imagine the scenario where eddoc has already started, like you're using the reverse flow or you're using the solution with the request creation hints, so the client has actually initiated eddoc with the resource server before receiving the access token. And then at a later stage, the client receives the access token and the EDHOC information object. It may be the case that what is indicated in the EDHOC information object clashes or there's a mismatch between that and the actual configuration the client started adequate towards the RS. So the question is then what to do? You ignore that or you consider that some type of failure. We also raised tthis in the past about early allocation of code points, and we sent a mail about tthis. So we want to follow-up on that point just to, yeah, let's say, push that more. And, we won't also send like a formal response to Christian's review of version nine, which had multiple of these points. And, yeah, any comments or questions are very welcome and reviews.
[00:41:21] Chairperson: Alright. Any questions? Alright. We'll move on to the group version.
[00:41:29] Marco Tiloca: Yes. Right. So tthis is another profile of base for the Group-OSCORE protocol. And just to recap what it's about, I mean, tthis is for I mean, Group-OSCORE is a protocol for secure group communication, but we want to enable access control for accessing resources at group members, meaning that, you know, the security protocol is Group-OSCORE. And well, one important thing here is that tthis happens, like, after the nodes have joined the group. So they join and only after that, now tthis comes into the picture where you can have fine grained access control between the group members already joined in the group. And how to join, we have other documents to describe that. Some proppers we have, we have proof possession of seas private key. We also have proof group membership for the client. So the RS can be assured that tthis client is indeed member of the same group. And we have mutual authentication when completing a first group of score exchange. Just overview of the protocol flow. I mean, I don't have to go into tthis in too much detail, but essentially, an access token is requested from the AS. It is posted to two resource servers. And following that, the client can actually access resources at those resource servers. I mean, it's it's, let's say, normal ACE in that sense. Right? But if you see on the right hand side, the when the RS receive tthis group of score request, that's when they can actually authenticate C and do proof accession of C's private key because that request will be signed. Some latest Daveelopments. We previously presented tthis for Version three in IETF-one hundred twenty one November twenty twenty four. Since then, both of the dependency drafts have been approved, and these are the actual Group-OSCORE protocol itself and the documents like defining the group manager functionality for Group-OSCORE. So what have we done in terms of more detailed updates? We have noted that the CNF claim in the access token, its content, meaning authentication credential of c, must be perfectly aligned with what C provided to the group manager, for instance, a certificate chain. We also mentioned now that the proof possession evidence from C in the request for an access token is optional because the AS may have performed through possession of tthis private key before or, I mean, in the past or by any other means, let's say. So it's a bit too strict to require tthis to always be present. Yeah. We have some suggested values for registered code points and alignment with other drafts. Yeah. We also we clarified that, again, tthis is optional inclusion of the pop evidence, and it's important to keep the data associations locally up to date at the RS. We have some guidelines in now about using multiple profiles. So there's the revised semantics for ACE profile parameter, and we have added registrations to the ASON web token claims in the registry and some other clarifications. And the point about using multiple profiles is you may want to use some of the group of score profile in your group, but you're also using the Oscore profile or some other profile. And then it can become important, like, how to distinguish between tokens for different profiles or how to request a token and somehow indicate, okay, I want it for tthis particular profile. Some updates from version six to seven. Yeah. Minor things, reference to Anna registries. We did extend and clarify the protocol overview, so it's clearer. And now we say that so Group-OSCORE has tthis associated document, like I mentioned, defining the Group-OSCORE group manager. And we're now stating that it's recommended to be used, but we don't want to mandate that you have to use that particular, like, incarnation of a group manager. There could be other ways to do tthis, and we don't want to lock it into a specific functionality. We added some detailed clarifications about the RS, about processing received access tokens. It can join the OSCORE group latest when receiving the access token. We also have some more information about proof group membership and proof possession for C. Yes. So basically, the RS will bind the access token with the recipient context associated with that client, not the whole group of core security context, but that specific and we have multiple recipient context for each client, right? And then at the RS, we did a simplification in how we're binding the access token to other information. In the past, we had, like, you can see these multiple elements, group ID, the client sender ID, client's auth cred, and the GM's auth cred, all, like, binding them, associating them with the access token. But that was a bit excessive, so a simpler solution is just to associate the access token with the token, series ID, audience, and the client's authentication credential. And one more thing, which you can see in the next slide, we also enable the dynamic update of access rights. And how did we do tthis? Well, we define tthis concept of a token series, basically. So an access token can be part of a series of tokens. And if it has the same audience, the same client authentication credential, then it's bound to the same security context. And, yeah, yes, I note that basically, like, if you consider tthis profile, the actual access token does not establish the group, of course, security context. That happens when you join the group, when you receive information from the group manager. So that's already present. Now we have a definition of a token series and we allocate so we say that, okay, for each pair of client and audience, you have a a unique token series ID. And then all access token in the same series in the include tthis token series ID. And what's the point of having tthis ID? Well, the point of having the ID is that I get an initial access token. It has a certain ID. Now I want to do update of access rights. Well, I can conveniently use tthis ID to point to, okay, tthis is the token or tthis is the series of tokens I wish to update, which otherwise we didn't have any mechanism to indicate. So what do we want to do with next steps? We want to improve the error handling at AS, adding the use of tthis ACE error code failed pop verification. We also want to elaborate a bit about resource servers that are monitors, aka silent servers, and tthis is like a concept from Group-OSCORE where you have servers that are they cannot trip basically, they cannot send responses protected with Group-OSCORE. They're only, like, passively ingesting messages, which can be useful for certain use cases. And it's also simpler to set up those kind of Daveices. We also want to consider setups where you have multiple application groups and multiple security groups. So imagine a client needs an access token spanning multiple application or security groups. Well, currently, way we define things, an access token can only target one security group. And if you imagine security group, it's basically like the group or score group with that shared symmetric key. So we need to extend some parameters and make things more dynamic if we want to support tokens covering multiple security groups. And, yeah, also for tthis draft, any comment and review is very welcome.
[00:49:35] Chairperson: Any questions? If not, we're on to our last talk of the early afternoon as I try to figure out what time zone I'm in.
[00:50:13] Rikard Höglund: Clickable?
[00:50:14] Chairperson: It should work.
[00:50:15] Rikard Höglund: Perfect. Hello, everybody. I'm I'm not. Unfortunately, he's not here, so I'm gonna talk to this slides. Tthis is a new draft, and it's actually in version three now. It's been some some progression, but these slides are are on version two. And tthis is about enrollment for secure transport over CBOR encoded X.509 certificates. So the background is the COSE working group has been spending some time defining a certificate format in CBOR, which is mapping from X.509. And that's in a late state now, a very progressed state, I should say. And there is also definitions of CSRs and and CSR templates and so on. And the rationale for tthis is that it provides some efficiency and reduced complexity properties. So, for example, you don't need to use ASN one, their encoder. You can use C port instead. And there is also on new work coming in on revocation objects like certification, like CRLs, for example. And so Lijun, who is working he was here at the hackathon. He's working for a car company, and they are deploying C509 in their connected cars. And and he wants also to have support for for enrollment, and, that's a missing component, to use to be able to use EST with C509. So what are we doing in the ACE working group? Well, ACE has previously worked on lightweight enrollment. So there is one RFC, RFC ninety one forty eight, which is EST over CoAP and DTLS. And there is also EST Oscore, which is an ongoing work, which is EST over co op protected with Oscore. And the latter actually supports C509, but the former does not. So that's also one thing that tthis draft is containing. It's, the purpose is to make C509 certificates be possible to enroll using EST either over co op, over HTTP with TLS or DTLS. And so it's basically looking at the EST operations and see what needs to be updated. And, yeah, the boldface here is supposed to illustrate, I think, what is new. So if we start with the non bold phase things, let's we have the cacerts where you request to see a certificate. And that's if you just use the accept and and the content format to indicate that you are using the C509 certificate or or or a set of C509 certificates, then you would it would work. So that's and those formats are already defined in the basic C509 specification in COSE. And similar on the last row here, if you want to retrieve a CSR template, if you then just indicate the media type of tthis C509 certification request template, then you would be able to request the C509 certificate. But then there are also some new operations proposed here. One is the caps capability discovery, which is only for HTTP because for for CoAP, we have a resource discovery mechanism that that actually manages to provide the sufficient information. So here's a proposal for a new EST operation, And the response to tthis request would be, like, what operations is tthis particular CA supporting? What EST operations is tthis CA supporting? And then there are also two new operations for for CRLs. So how to request the CRL and or to request metadata for CRL. Whereas the actual data structures are defined in another draft in COSE to be presented on on Thursday, I think. Too many clicks. And similar here, if we start with a non bold phase, we have the usual simple enrollment, simple rekey, server key generation, and it's just a matter of using the, the media formats, media, types for, certification requests and as as a request and either certificate certificate or PEM structure, which is defined in the COSE document. So the only new thing here or the main new thing is the chemc operation, which is basically enabling the enrollment of KEM public keys. So what you do is you run the KEM protocol, you send the public key in the request, and you get back, KEM ciphertext or KEM challenge as it's defined called here. And then you have a shared key, then you integrate to protect the enrollment request with that key. And those two formats are specified in tthis ID, the C509 public key and and the C509 cam challenge. And that's it. That's the proposal. Tthis draft is filling a gap in enrollment of lightweight certificates. That's been the topic of tthis working group before, and tthis is an update to RC ninety one forty eight. And at the same time, it's also updating the EST draft. So the obvious question is, is tthis something for the working group to accept as a work item?
[00:56:26] Chairperson: Alright. We have four minutes for discussion here. And, of course, you can also speak up on the list about it. I'd be more than happy to run an adoption call for tthis once we get back I'll get back and get settled.
[00:56:43] Rikard Höglund: Okay. No more no more comments. Perfect. Thank you.
[00:56:48] Chairperson: Alright. Thanks, everyone, and thank you to all of the presenters for doing an excellent time on presenting quickly and staying within your time boundaries. It makes tthis all run very, very smoothly, so thank you. Alright. We are adjourned. Go have fun.