Session Date/Time: 20 Mar 2026 01:00
Mike Jones: Ivo, did we do a chair's deck? I don't see it.
Ivaylo (Ivo) Petrov: I don't. I didn't do a chair's deck, no.
Mike Jones: You're unintelligible. Speak again.
Ivaylo (Ivo) Petrov: I did not prepare a chair's deck.
Mike Jones: Okay, so we're going to do this without. Um, welcome to COSE. There are a number of interesting topics we have today. We have Lucas volunteering to take minutes for us. I am still looking for a second person that's willing to backstop Lucas as we go. Karen raised a finger. So, thank you, Karen. So, it turns out that not only are three presenters missing decks, the chairs are missing decks. And so, Ivo, is it possible to present or to project the agenda?
Ivaylo (Ivo) Petrov: Uh, sure. Let me, uh, give me two minutes and I will probably just present a modified version of last slides. But just a moment.
Mike Jones: Okay. Do I have to do something to approve it?
Ivaylo (Ivo) Petrov: Uh, no. Let me, uh, see. Too many windows. Ah, there we go. A screen share is being started. Yes. Uh, show.
Mike Jones: Well, um, I will remind people, um, as you've heard many times before and in many other meetings that the Note Well applies. Um, treat each other with respect and in a productive fashion. Oh, there we go. We have a chair's deck. So, next slide, Ivo. Uh, yes. So, I guess that's what you are saying. This is the Note Well. Next. All of you in the room, please do sign in to the onsite tool. We will be using it to manage the queue. I know you will all want to speak up at different points. Thank you. Next. We have note takers. All right. So, this is the opening remarks. We're not going to take 15 minutes. Um, the C509 test vectors [draft-ietf-cose-c509-test-vectors], the authors notified us that there hasn't been significant updates since, um, we last met our heroes. Therefore, they didn't feel that a presentation was needed. Um, test vectors are straightforward and useful things. Um, any of you with implementations of C509 are highly encouraged to test the test vectors. Um, beyond that, would anyone, including remote participants, like to say anything about the test vectors? All right. Hearing none, we will move on to Post-Quantum land. So, Ivo, can you stop sharing and I will share Hannes's deck? And Hannes, I'm going to give you control over the slides if you would like it or I will advance.
Hannes Tschofenig: Um, no, it's fine. Uh, you can, you can do the clicking. It's good.
Mike Jones: I can do the clicking? Okay.
Hannes Tschofenig: Yeah.
Mike Jones: Take us away, Hannes.
Hannes Tschofenig: Yeah, thank you, thank you Mike, thank you Ivo. Hi everyone. I hope you can hear me well. Um, this is a short update of two of the documents. Uh, we talked about them at the last IETF meeting when I joined as a co-author of the document together with Mike Prorock and Orie Steele. I think Orie is in the room as well, so...
Mike Jones: Orie is in the room.
Hannes Tschofenig: Okay, uh, perfect. Um, next slide. So a quick update of what has happened since the last meeting. Um, primarily the changes concern implementation, implementation activities for both of the documents [draft-ietf-cose-falcon and draft-ietf-cose-sphincs-plus]. Um, specifically, I wanted to have some working examples in both of them. Uh, currently the changes focused on the COSE version. Haven't worked on the JOSE version yet, um, but I I think that's at least a start. I also implemented the ML-DSA to just make sure that it, I have the sort of the whole bundle. And you can find the code here. It's based on Pico COSE, which you all know, Laurence's implementation. So, while this is not really, I wouldn't really call it a lightweight implementation, which is what Pico COSE is really aiming to provide, um, because of the crypto library it uses, but it's good enough for the examples. Right. Um, there's one, there's one aspect I want to point out for the COSE SPHINCS+, I currently only have a single example in there because of the size reasons. I could add more if size doesn't really matter much, just to have something implementers can sort of work with. But, uh, yeah, that's what it, what it currently is. Next slide. Um, but since I have a time slot to talk about the documents, I wanted to sort of look at some of the design decisions in the past and specifically wanted to ask the question: are the algorithms that we register enough, or the right ones? Because just this week we had a discussion in the JOSE working group about the number of algorithms that we register. And ideally, we want to have as few algorithms registered as possible to increase interoperability. But of course, we don't want to miss out on some other important algorithms that people want to use. Um, so, so that's why I've added these slides. I don't expect anyone to have an opinion right now while I'm giving the presentation, but I think these, these issues typically come up during the lifetime of the draft process. So I thought it would be good to talk about them again. Okay, next one. So, and I also wanted to put this a little bit in sort of the algorithm number in context of the developments in the LAMPS working group. And here, specifically relevant is RFC 9909, which registers the counterpart for SPHINCS+ for PKIX. Um, and also relevant is, which I'll talk later, is the question about what precisely do we sign? Do we sign the whole message, or do we sign a hash of the message? Um, okay. So RFC 9909 registers, interestingly enough, um, both the SPHINCS+ and also a hash SPHINCS+, which, as the name indicates, it just sort of produces a hash first and then signs the hash. The idea is that it, by doing the second variant of the algorithm, you don't need to pass in potentially large payloads into the cryptographic algorithm implementation to sign it. In the COSE SPHINCS+ draft, um, we currently only use the pure version of the algorithm. And of course, that reduces the size of the implementation because there's only one variant to implement, but it's possible for some that we miss something out here. Next slide. Um, so what, what did the RFC 9909 say about why it includes the hash variants? There it says that there are larger payloads, such as X.509 certificate sizes and also CRLs which, which may require that implementers pass in only a hash. Um, and also talks about hardware security modules that also sort of ideally operate with a high speed. So clearly you have to pass in, if you don't support that form of algorithms, then you need to pass in sort of the whole buffer instead of just a smaller version of it. Um, that's why, why it says it does this. This sounds a little bit like what we would really want in COSE as well, but I'll get to that in next slide. Next slide. Um, so in COSE, uh, of course we, we focus on smaller, more interoperable profiles. But interestingly, we have one specification which is currently being finalized, which is the Hash-Envelope, which is, if you remember that specification, it allows to sign a digest instead of the original payload, not just for the SPHINCS+ algorithm, but in general. So it is, it is a little bit... uh, a different design, but it, at least from a conceptual point of view, it kind of does the same. Uh, so, so that's a opportunity in COSE which doesn't exist in JOSE and in, and in my opinion doesn't exist in the PKIX world. Okay. Next slide. Um, a few words about why this hash envelope is a little different. Uh, like I said, it's a generic construction. I think Orie and Hank and some others are the authors of it, um, and it was discussed in the group extensively. Um, it's also, uh... it's obviously not part of the NIST FIPS specifications, but instead just a byproduct of this working group. So it's very similar, but not obviously semantically identical to the Hash-SPHINCS+ work. Next slide. Um, there, there are potential arguments for registering also the Hash-SPHINCS+. And one is, um, and I think that's the last item on this list is, uh, because for JOSE there is no specific or there is no Hash-Envelope counterpart since it was only defined for COSE. Uh, so, so there may be something to think about whether this is needed also in the JOSE world. But since so far I haven't seen anyone bringing this up, it may not be a big concern. And maybe people are not worried about the size of the messages given that SPHINCS+ itself already requires a fairly large buffer size because the signatures are quite long. Okay. Next slide. Yeah, it works. Um, on the, on the negative side for on why the Hash-SPHINCS+ is not registered, it of course adds, if we support this, it basically adds another set of algorithms because we then have to support all the variants also for the hash-based version. Um, maybe only for JOSE, but, but nevertheless, um, so it's not really... yeah, it can quickly blow up the registry as well. Next slide. So currently, uh, so obviously there are a couple of options. So currently, um, I would sort of the three obvious options are: not, to not register the Hash-SPHINCS+, and the other one is to obviously do it. And the third option is to register it later. Um, my preference at the moment is to just defer the registration if someone really needs it, or at least for all of you in the group to think about, um, whether this is really something you consider using specifically in JOSE, whether that's a real concern. Um, I think the Hash-Envelope in COSE is just fine, so, so I think it's good. I see Carsten saying something different, uh, but that's exactly the intent of sort of like going through these design decisions again so that we actually know that we are still have the same opinion as maybe a year or so ago. Okay. Next slide. So there's also another angle to this registrations. So there are different security levels as well. It's not just the Hash-SPHINCS+ versus the regular one. Um, but there's also the dimension of the security levels between 128, 192, and 256. Currently the document, um, aims for security levels only or the security level 128 and omits the others. Um, and yeah, as a starting point, obviously 128 is a, is a good start here. But, and particularly with SPHINCS+, as I mentioned, I only included a single example because of the length of the signature. And if we extend that to other levels, obviously the signatures get larger and there is some complexity in there as well. Next slide. Um, yeah, it's, the other ones haven't been omitted because they have any sort of negative security aspects, but it's, it's really about keeping the numbers, the registered code points small rather than anything else. But of course, if you have use cases which require these other levels, it would be good to know about them. Next slide. Then, to make things even more complicated, there are also different variants called S and F. S, as I wrote here for small, small signatures. Small is relative in this algorithm. Um, F is for fast signatures. Uh, so there's a difference, like for the lowest security level, the 128, of signatures of the size of, let's say something around 7,000 bytes for S and 17,000 bytes for F variants. So, so clearly there's a difference. Uh, so it's not just a minor detail. But, um, but then there's also the computational aspect there too. Currently the document registers, um, both or algorithm from both variants for the 128 size, um, just to have, sort of the different performance characteristics in there. For COSE type of deployment, so the constrained IoT deployments, of course you would really want something that is both small and fast, but I guess that's just wishful thinking. Um, and so, so for many deployments where the bandwidth constraints dominate, small is probably a good choice. And of course, unfortunately, some of the devices also have limitations on the computational side. Um, but yeah, so you have to decide which characteristic is more important to you, so there's clearly a trade-off here. Next slide. So the, the two variants are there, but maybe, maybe only because of the size reason, maybe the small one is more important to some of you. Um, I I said all of that already. Next slide. So, um, so I will drop a mail to the list, ask these questions again and, and maybe you have a look at it. Look at the three algorithms that are being registered for COSE and JOSE. Both are kind of mirrored and obviously it would be good to know whether um, you see some differences in the different deployments and want to adjust the list of registered algorithms a little bit more. But if you are all happy with the choice that we've made in the past, then I think the document is quite good. Maybe I'm going to provide, or maybe someone else provides the test vectors or examples for the JOSE variant and then, at least the SPHINCS+ version could be finalized. Um, as we said in the meeting, I think November meeting, we wanted to progress the COSE FN-DSA [draft-ietf-cose-falcon] a little slower because we are waiting for NIST to finalize all the work. But I think we are still on that same path. Um, I've been talking to the PKIX team working on the interop tests and there was also some interest to do interop tests not just for the PKIX PQC algorithms but also for the JOSE/COSE ones. Um, so this is definitely something I'm going to pick up. And if there's someone else in the room who would like to do some interop testing, who has some implementation work going on for these two algorithms, please reach out to me. And I see a queue has formed.
Mike Jones: There is a queue. Um, let me take the queue and then... actually, I'm going to ask a clarifying question, um, to get it on record before I take the queue. Um, is it the case that the underlying NIST specifications for SLH-DSA are final, whereas the FN-DSA NIST specification is not final? Is that correct? Any experts speak up.
Speaker 1: Yes, that's correct.
Scott Fluhrer: That's right.
Mike Jones: Okay, thank you. With that, I will go to the queue. Carsten.
Carsten Bormann: Yeah, um, I said I prefer option two. Um, when we decided to not go for polymorphic registrations, for registrations that cover a number of parameter sets, we also decided for combinatorial explosion. So, I cannot take arguments very seriously that we want to keep this algorithm registry small. I mean, look at it. Um, there's no way we will keep it small. Of course, we shouldn't put fluff there. Um, but the hash issue has come up repeatedly. Um, so I would prefer to just put these things in. Uh, in practice, what happens if we don't put things in is people will see that and uh, if they actually did plan to use this algorithm, they will just decide, Oh, COSE is not for me, I'm going to use ASN.1 or whatever. Um, and that's not necessarily an outcome we want to have.
Mike Jones: Thank you. Scott.
Scott Fluhrer: Mute? Okay. Um, Scott Fluhrer, Cisco Systems. Um, I am actually new to COSE, so, uh, take that into mind. Uh, as for, I would take the opposite approach. Um, I don't know how common support a Hash-SLH-DSA will be to various crypto modules, so I'd be hesitant to actually, uh, to support it because, quite frankly, I don't know if the underlying crypto will in the future. However, what my main point I wanted to point out is that this hash versus pure question will likely be repeated in FN-DSA, which has precisely the same issues, and so what, again, you probably will come up with exact same answers whichever it is. You have to keep that in mind. Thank you.
Mike Jones: Thank you, Scott. Philip.
Philip: Thank you. Hi, Hannes. Um, for JOSE SLH-DSA specifically, um, I think first of all I appreciate that the number of algorithms is kept down. I think there are three at the moment, correct me if I'm wrong. Um, the even though there is a much larger parameter set available, so it's not like we are trying to register everything. The, the thing that I'm not sure about is the general applicability of this over ML-DSA or in the future FN-DSA, um, where the small signatures are slow and the fast signatures are not fast enough. Um, so I would like to know whether you intend for this to be a general-purpose signature scheme for JOSE, or whether this is intended for a particular use case such as signing firmware, and in that case is that something that JOSE is meant for rather than just COSE.
Hannes Tschofenig: Yeah, I can quickly respond to you, Philip. Thanks for the comment. Uh, the SLH-DSA, as also Jonathan mentioned it on the list, is definitely a good contender for securing firmware updates already now. Um, so that's, I think that's also why the NSA has sort of like looked at these hash-based variants for firmware updates. So I would say it's definitely not a generic mechanism, PQC mechanism, but in in that for that use case I think it's a good choice. Uh, because firmware updates are in general large, so the larger signature is sort of like kind of disappears in that larger payload anyway. Um, for the FN-DSA, it was developed as an alternative design to some of the other algorithms, so it's kind of a backup, backup choice. And I with that I assume that the primary choice, ML-DSA, would be used sort of maybe more often or is likely to be used more often than the FN-DSA, but I'm like...
Philip: I think also the barrier for entry to Falcon is the complex floating point arithmetic, which is not there for ML-DSA.
Hannes Tschofenig: For sure, true. Mhm.
Philip: But time will tell how often this will be implemented in underlying crypto modules.
Hannes Tschofenig: Yeah.
Philip: And as you said yourself, FN-DSA is quite a way out. I haven't heard any updates since, I don't know, a year and a half ago, so...
Hannes Tschofenig: Yeah. Well, there's also another competition ongoing, we'll see those, this work, and of course only time will tell on how we are going to use or see the use of different algorithms potentially in combination with the traditional signature algorithms, so um, it's going to be interesting, yeah.
Mike Jones: Thank you, Philip. Tiru.
Tirumaleswar (Tiru) Reddy: Hey, thanks Hannes for the excellent presentation. So I have a few comments on the use of SLH-DSA. So if you look at firmware updates, right, I mean, we typically are currently relying on hash-based stateful signatures. The only alternative that we have if you want to migrate is SLH-DSA, which offers the same level of security. There's no way that we can use ML-DSA because of the uncertainties with the lattice schemes, and that's the reason we have composites, right? So for SUIT, I believe the two only viable alternatives is either go to stateful hash-based signatures or pick SLH-DSA. I don't think you will be able to deploy ML, pure ML-DSA, especially because of the non-repudiation issues. Um, and and do you have any comments on that? How you want to take that forward?
Hannes Tschofenig: Um, good, good question. Would, yeah, would have to think about that. Um, do you have a suggestion?
Tirumaleswar (Tiru) Reddy: I think at least we are planning to use SL pure SLH-DSA and not go with ML-DSA or the Falcon one because of the lattice-based schemes, because that would not give us the properties of non-repudiation. So either we have to stick with stateful LMS or XMSS, or go with SLH-DSA. But then it has a challenge that we'll have to look into the signature sizes and public-key sizes and see if it fits within the the memory that is available on these constrained devices.
Hannes Tschofenig: Yeah. Yeah, it's maybe, maybe I should, we should also reference some of the work in the PQUC group on some of those aspects. I don't think we've done that, because there is also um, like as you are co-author on some of the documents, um, which discuss some of these aspects on for constrained devices and also the dealing with the stateful nature. There are also other documents that talk about those. Maybe we should reference them. Yeah.
Tirumaleswar (Tiru) Reddy: Yeah, that would be great. And coming to the options, right, I mean as far as I hear from the LAMPS working group, the hash-based SLH-DSA seems like not a favorite one that the CA community wants to deploy basically, right? So I think we better cross-check once basically, right? I mean, if there is interop, I mean hash-based SLH-DSA has a distinct advantage, it pre-hashes, right? So you basically send a small size of a hashed message to, let's say, HSM to sign the message, which gives you a much better performance than sending very large messages, right, to the HSM, right? But I think it's all about deployability, right? I mean, if there is a good interest from from the community to implement and deploy that, it makes sense. But otherwise, if there is not, then um, then I think we need to probably explain why it is required and and get it to a state where if you really see that makes sense to add it or not. But at least hash-based SLH-DSA, we did not register that in the, we are not using that in the IPsecME or the TLS drafts that we have. IPsec draft is adopted by the working group. TLS is still working in TLS also we did not do register code points for that. So, but I see the advantages of that in this case because of the pre-hashing that is there. Uh, that probably requires some more discussion in the working group on on the feasibility and deployability and whether there is interest to implement and deploy that.
Mike Jones: Okay, thank you, Tiru. I'm going to give the queue to John and then I'm going to run two polls.
John Gray: Yeah, hi. It's John Gray from Entrust. I was just going to say, the SLH-DSA, there's the NIST does have the smaller parameter sets that they're coming out with. Um, if the, you know, constrained size of signatures is is a concern, that's something you could look at. Yes, they might have slower signing times. But again, I guess, I guess unless you know your use cases, you're not sure maybe which ones exactly you're going to need. But, um, so there's that. And I agree with what Tiru was saying as well about, uh, the signing of like with CAs. Like if we're trying to sign large CRLs with SLH-DSA, it's like the pure mode is is very difficult because the whole thing has to be kind of in memory, whereas the hash one works. But then, you know, there's anyway, there's there's issues with operational... obviously, they can be worked around, but that's just again, I agree with that consideration as well. Thanks.
Mike Jones: All right. Thank you, John. I'm going to solicit working group input now on the question of whether we add Hash-SLH-DSA to the draft. Um, the poll is running. There are 52 of you here, and only, or 54, and we have less than half that many responses. Even if you give me a no opinion, please respond in the tool. All right. Um, by more than a factor of two to one among those with an opinion, we're not going to do that. We're going to stay with the scope of the draft as adopted. People can, uh, discuss that on the mailing list further if they would like. So that's that. Um, with that, I'm going to ask the question: do people believe it's time to take the SPHINCS+ draft, um, also known as the SLH-DSA draft, to working group last call at this point, given that the NIST algorithms are stable? So while we are waiting for that poll to complete, um, I'm not so happy about using voting in the IETF. You are counting votes and then you say, Oh, so we don't need that. Well, the reason may be that a lot of people are in this room who actually do not need that, which is totally fine. We can register things that some people don't need. Just pointing out that your methodology is not, not really very good here.
Mike Jones: Um, I hear you, Carsten, and let me respond with chair hat on. Um, by default, um, as chair, I'm going to respect past consensus decisions of the working group. The consensus decision I'm referring to here is the decision to adopt the SPHINCS+ draft with a particular scope that Orie and Hannes and others have continued to pursue. Um, in my view, it would take a working group consensus to expand the scope, um, for us to decide to do so. Um, I'm not basing what I said earlier on a vote. I'm basing it on evidence that there is not apparent working group consensus to expand the scope of the draft at this time. That's another thing that could be taken to the list, and if you want to make that case, feel free, but there's not, I don't have any evidence of working group consensus to expand the scope today. Um, all right. I'm going to end this poll. It seems like there is, uh, substantial support for taking it to working group last call. Did any of the three people who were not in favor of that want to join the queue and say why? John.
John Gray: Yeah, sorry, it's John. I I just said it just based on that I know there's these smaller parameter sets coming for these algorithms. Now, I mean, I guess those could be done in a different draft if you want them, and then I would change my opinion. I just thought, I guess like if they're coming soon, I guess the thing is it's on NIST time frame, so I guess we can never know when because they say things are coming and then they don't. But that was my concern because I notice this like the 128 one, so obviously size is a concern, so if we know there's these smaller size ones that are coming out that would be useful, then can we not just wait for those, or should they be in a different draft, I guess.
Mike Jones: Thank you, John. Scott.
Scott Fluhrer: Yes, uh, about those smaller parameter sets. Those are very preliminary. The 128 versions are around, I think if I remember right, around 3K in signature size, but they may be changed, they're just initial drafts, initial proposals. NIST very well may change their minds. In fact, in some ways I hope they do, because I think they could be improved somewhat. Uh, I think it would be very premature to actually endorse them. Thank you.
Mike Jones: Thank you, Scott. Anyone else? Okay, I will confer with Ivo afterwards, but it seems like we may be preparing for a working group last call. Thank you, Hannes. That was super useful.
Hannes Tschofenig: Thank you all.
Mike Jones: Okay. All right. Looking at the agenda, uh, the next draft up is the COSE HPKE draft [draft-ietf-cose-hpke] where I will be the presenter but not as a chair but as a draft author, and I'm giving control to the clicker. Good morning, or other appropriate greetings depending on where you are this busy Tuesday morning. Uh, good morning. Uh, I'm Mike Jones, an author of a working group draft giving a presentation for which Ivo is chairing. So we've been working on COSE HPKE for a while. And much like the JOSE HPKE, I believe we're finally, uh, at a really good place. So, um, in Montreal we presented draft 18. Uh, since then, based on feedback from the working group and editorial review by some of the editors, in particular Laurence, there's been a flurry of updates published, which we've described on the list. Um, the most recent draft published was 24 on the 15th of March. There are three implementations that were used to validate the examples, which I'm very happy with. So what have we done? Um, the big change was to use, uh, fully specified algorithms rather than polymorphic algorithms, um, in line with the approved fully specified algorithms RFC. Um, we made a lot of clarifications to how the AAD and Info HPKE parameters are used and we have clearer handling and description in the draft of how to use application-supplied additional authenticated data and context information as inputs to the HPKE process. We defined the recipient structure for doing those things. Um, we tightened the rules around what things must be in protected headers when they appear so as to increase interoperability. Um, we clarified the key representation, we updated a lot of examples, I think all the examples, we added test vectors. Um, I got added by the other authors as an author by virtue of the amount of work I was doing on the draft, which I appreciate. Um, so let me drill down into a few of these things. The introduction of the separate algorithm identifiers means that we have different algorithms for use with HPKE integrated encryption mode versus HPKE key encryption mode. Again, this is to use fully specified algorithms. Um, we also added, at Apple's request, um, the HPKE 7 and 7-KE algorithms using a particular set of combined HPKE parameters. So the recipient structure. It contains a constant string, uh, the next layer algorithm so that this becomes cryptographically tied to the next COSE layer. There's the recipient protected header is included, again, to protect that. There's the recipient extra information so that you can add stuff if your application needs it. Um, we clarified that the COSE KDF context is not used, and there's security design rationale in the draft that explains all of this, the reasons for it. Um, deterministic encoding is needed to be used for the recipient structure because it is not transmitted. It is constructed by the two parties independently; therefore, if they don't construct it in exactly the same way, it will not cryptographically validate. So there is deterministic encoding used for that structure. It is not used for other things. The AAD handling. For integrated encryption, the HPKE AAD contains the serialized COSE enc structure, and there's a context string, um, the external AAD must be the external AAD field. For key encryption, things are done a little differently because you're not um, doing everything in one layer. The HPKE Info is the recipient structure. The external context VNE goes into the recipient extra info. The recipient additional authenticated data is generally not necessary, and any large external data should go and be protected at layer zero using external AAD. All of this is well explained in the draft, thanks to numerous authors, uh, word-smithing this text. This was the primary textual change other than the examples, um, made in the draft. And as an asterisk, I'll note that all of these are essentially the same choices that JOSE made to the extent that the same choices make sense given the layering is slightly different. We sharpened the processing of the header parameters. Um, we say where EK must be, um, we talk about protecting the algorithm in the COSE recipient, that the use of KID is recommended, um, and that we recommend placing the KID in the protected headers so that it's covered by the HPKE key derivation context. So the key representation. If the key type is OKP, then the key material must be the raw HPKE public key for the corresponding KEM. Um, and there's validity rules for various key type and curve combinations, including the use of key ops. There are examples of everything and test vectors for everything. Thanks especially to Hannes for doing the heavy lifting of this, but also to Daisuke and Laurence and Orie for writing code that enabled us not only to do this but to believe that we got it right. Uh, so in conclusion, the authors unanimously believe that the specification is ready for publication, having completed working group last call and successfully addressed all known issues. Ivo, you're chair.
Ivaylo (Ivo) Petrov: Yes, I agree. I have started writing the shepherd write-up and uh once I have uploaded it to data tracker uh I will request publication.
Mike Jones: All right, thank you very much. Is there a queue?
Ivaylo (Ivo) Petrov: Uh I don't see anyone yet but yeah if anyone wants to speak please do.
Mike Jones: This will go on record as the first HPKE presentation in this working group without substantive discussion. I feel like we've achieved something. Thank you. Okay, I'll end this deck and I believe I'm doing a different deck.
Ivaylo (Ivo) Petrov: Uh I see some Okay so that's for the next presentation or...
Tirumaleswar (Tiru) Reddy: Yeah I just wanted to thank the JOSE HPKE authors and the entire working group for making progress on this. I think it's a significant milestone so I don't have any comments but it looks ready to ship it. Thanks.
Mike Jones: All right. Um, I believe that the next presentation scheduled was for Tiru but no deck was ever uploaded. Am I correct, Tiru?
Tirumaleswar (Tiru) Reddy: Yeah. Um, so Mike, I had sent a mail a few days back on why I didn't want to present this in light of the discussion in the JOSE working group. Right? I think the chairs and the AD had a comment that we need to work on a unified mechanism on how we want to take this forward for both COSE and JOSE. And the plan is the authors of both the drafts are going to work on realigning these drafts in a way that we wherever possible we will align and wherever not possible we will figure out why we cannot align and give justifications for that and come up with new specs either either one spec or two specs. So I didn't see a need to present this at this time because eventually again it has to go back to the small design team to figure out the best way forward.
Mike Jones: Okay, thank you very much for that context. Does anyone want to speak to Tiru's point? Okay, hearing none, I'm going to pass control to the clicker and be another author. In this case, I'm an author of an individual draft you've heard about for the last three IETFs with my, uh, colleague in Sweden, Emil Lundberg. This is the Split Signing Algorithms for COSE [draft-jones-cose-split-signing-05]. So, when we last met our heroes in Montreal, we gave a fairly substantive presentation of what the draft does and why it does it. Um, you've heard this before, you could read it again. Um, we're not going to go over the what, why, how, or the context of the work today, unless you want to bring it up from the mic line. So, what's happened since IETF 124? We got great reviews from Lucas, who is also our scribe today, from Sophie, and from David Dong of IANA. Um, and what have we done to the draft since then? We have incorporated their feedback and confirmed that the reviewers were happy with what we did with their feedback. Um, so I'll now talk about what we did. Um, in draft 4 we described implementations that exist. Um, in draft 5, um, we made a bunch of clarifying comments in response to both Lucas and Sophie's reviews, um, which I'm not going to read these, this is all text straight out of the history section in the draft, so you could go read it yourself or look at the presentation if you like. And again, draft 5 was where we did the bulk of the work to respond to the useful reviews which uh were requested in Montreal and both of the volunteers did do the work. Um, then a few days ago, IANA in the person of David Dong, who I met for the first time ever at the new participants reception last night, um, did an early IANA review. And he correctly pointed out that some of our IANA considerations sections were still listed as TBD even though we knew what needed to go there. And so I thought, well this is silly, I will populate the IANA considerations sections. That did happen in the last 48 hours. It changes text that used to say TBD to defining the registries and populating the registries with values that were already in the specification. Um, the other thing that was done as part of draft 7 besides populating the registries is some of the algorithms being registered are ARKG algorithms which come from a different draft that was presented to the CFRG by Emil a few days ago. Um, we're going to see if we can get an adoption call for that, but that's not our topic today. Nonetheless, an editorial action was made to import some of the text from the CFRG draft that would be appropriate to be in this draft. Uh, no normative changes were made, nor no animals were harmed in the process. Um, so what did we do since Montreal, in summary? We improved a number of explanations in the draft and provided more rationale for why the draft exists. Uh, we added more background information on existing uses of split signing, especially uses of split signing for smart cards, which our use case is very analogous to that. Uh, we did list implementations, there are multiple. We did populate the IANA considerations section, there's no more TBDs in the draft. There were no architectural changes made. So, my assessment as an individual author, and I believe Emil concurs, the draft is stable and clear. It incorporates review feedback from the reviewers. Um, it meets the needs of a real and important use case. In particular, the WWWallet, uh, cloud wallet from the Siros Foundation, aka Siros ID, uh, was one of the entrants in the German Funke wallet competition and one of the winners. But it depends upon the ability to have split signing, and it also depends upon a WebAuthn extension that's not final that some of you are aware of. So like many standards-based activities, we're assembling the building blocks to make this use case and potentially others standards-based. This building block is in COSE. Uh, so at IETF 124, the decision of the chair, Ivo, which was a good one, was: let's get some more reviews and then consider adoption. We got good reviews, we responded to them. I think adoption should now be considered, but Ivo, it's your chair role to decide.
Ivaylo (Ivo) Petrov: Yes, I think based on the feedback we are ready to run a call for adoption and confirm it on the mailing list. Of course, if anyone has comments now, please share them. Otherwise, that will be my, my plan.
Mike Jones: All right, thank you all. All right. Um, I believe that the next presentation scheduled was for AES-CMAC [draft-ietf-cose-aes-cmac-00]. Brian, you are up.
Brian Campbell: Okay, thank you. Uh, this should be short and it's really a question to the group. Um, so can you go to the next slide, please? Um, oh, I just gave you control of the slides. Oh, there we go. Perfect. Thank you. Um, so I'm going to be talking about the, uh, family of CMAC algorithms that, um, I'm looking at, uh, adding as registrations for COSE. And the, a little bit of background is that there already are registrations for similar, uh, CBC-MAC algorithms, and there's nothing functionally wrong with these things, but they are not approved by FIPS 140, and that is a bit of a gate to using them in certain applications. And, um, the use of NIST Cipher block MAC, uh, is FIPS approved, and AES-CMAC, uh, in that mode is already something that's part of existing IETF, uh, behaviors in IEEE behaviors and some others. And, um, there was actually mailing list discussion several years back, oh, about what to register initially for COSE, and it was going back and forth between CBC-MAC or CMAC, and there really wasn't a conclusion, so it was, I think, just kind of arbitrarily chosen to be CBC-MAC. And that was even before some of these, um, conformance requirements had been made. So it was, it was not a bad decision, it was just an arbitrary decision somewhat. So that being said, um, I have a personal draft that does a very simple registration of these AES-CMAC algorithms, um, only two of them with two different key lengths and maximum tag length. Um, and these are intended to be used in a kind of a hardware-accelerated, uh, authenticator, uh, type of situation. And, the expectation is, uh, that this is going to be used in that kind of environment where it's high throughput, high volume. And there was some discussion that I reached out to the JOSE group, and they were not interested in this kind of thing, um, just because they're not targeting the same kind of applications. So, um, moving on to the real questions to the group are, uh, that, uh, there's a standard action, um, constraint for registrations algorithms between plus and minus that two-byte encoding. And, um, there's many of them that are currently unregistered, and it seems like to me doing this registration through COSE working group, um, seems natural. Uh, there's no customization happening here. I don't think there's any kind of security analysis that needs to be done. Um, so the question is, does this seem relevant for the working group and does the, um, current draft seem like it's on the right track?
John Gray: Hi. I I disagree with that it was not a bad decision. I think it was a very un-baffled by COSE standardizing CBC-MAC. So I think just publish this. It's just it's well-known algorithms. There's not much to discuss. Just publish the RFC register the code points and make the old CBC-MAC not recommended.
Brian Campbell: Okay, so that is actually a separate question. This, this original draft was just registering these code points without touching the CBC-MAC, but if there is a feeling about CBC-MAC, um, transitioning into not recommended, um, that's an additional consideration I think. And I don't have strong feelings about it. My goal is to be able to use CMAC, and if there's other concerns, uh, about the CBC-MAC, um, I'm welcome to talk about them.
Mike Jones: So in the chat, Russ supports adding AES-CMAC. Carsten does. Adam does. Um, other Russ says do something with AES-CBC-MAC separately.
Brian Campbell: Yeah, I'm perfectly fine with that. And there's no real overlap. They're two separate families. They're two separate sets of algorithms and I think they don't need to relate to each other in terms of documentation.
Mike Jones: Okay.
Scott Fluhrer: Okay, Scott Fluhrer, Cisco Systems. Um, given the choice between CMAC and CBC-MAC, I would always go with CMAC because CBC-MAC has some known cryptographical weaknesses which you can by various uh, uh, you can potentially generate uh, for uh, forgeries. Uh, which that we design applied to to CMAC. Are is those particular methods uh, critical for uh, COSE? I do not know. I do not care.
Brian Campbell: Yeah, thanks about that. And there are, like you said, there are special considerations for CBC-MAC that I know are part of the existing documentation that there's a kind of a workaround in how COSE uses them. But, uh, for the sake of a draft and the documentation, the intent here is just to say CMAC is its own meaningful thing and and we want to register it. So thanks for that feedback.
Mike Jones: Does anyone else want to join the question queue? All right. Well, I will ask, probably my most asked chair question: who has read the draft? I see no one in the room. Are there people who can add to the chat that they have read the draft? The good news is that it's very short. The draft is very short. All right. I will ask my standard chair follow-up question to that question. Most of you know what's coming: who is willing to volunteer to read the draft? I would particularly covet reviews from people who have, uh, opinions and familiarity with the underlying cryptography. Uh, so going out on a limb, Russ, would you be willing to read the draft? John volunteered. Russ said okay. Uh, John Preuß Mattsson, would you be willing to read the draft?
John Preuß Mattsson: Yes, and as I wrote in the chat, I have already read it. I can read it again.
Mike Jones: Oh, okay. Thank you very much. So, um, I look forward to reviews on the list, to seeing updates made to the draft as a result of the reviews, um, much like Emil and I did with the previous presentation, and then we will go from there. Thank you, Brian. With that, um, I believe we are at the end of the scheduled presentations. Uh, it's now open mic time, and Ivo, is there anything you would like to say to the working group?
Ivaylo (Ivo) Petrov: Uh, no, I think out of what we already discussed, nothing really.
Mike Jones: All right. Hearing none, let's thank Karen and Lucas again for taking notes. Um, appreciate you being here both physically and virtually, and uh, as they say, we'll see you on the list. Thank you. Bye-bye.