Session Date/Time: 17 Mar 2026 01:00
Karen O'Donoghue: Okay, it is 9:01, so we will go ahead and get started. Welcome to the JOSE Working Group at IETF 125.
This is the IETF Note Well. You agreed to abide by this by joining any of our mailing lists and also by registering for this meeting. Please be sure that you read it and understand it. If you have any questions, please feel free to reach out to the chairs or the ADs.
Speaking of chairs and ADs, I wanted to—this is the first meeting where we have a new chair, so I'd like to acknowledge Michael as our new chair. And I'd also like to thank John Mattsson, who served for a couple of years as our outgoing chair. There is also IESG leadership changeover at this meeting, but in our case, we will be keeping our AD as Deb Cooley. So going forward—applause in the room—so going forward, Deb will be our AD. And those are the people that you ask if you have any questions about the Note Well.
A few reminders from the IETF meetings people: be sure that you have signed up for the meeting. Scan the QR code; that's the way that you get in the queue, either locally or remotely. And then the rest of these are reminders for all of the meetings that you will see going forward.
Here's some resources that you should probably have already found. In particular, though, if you have any issues, please follow the issue reporting channel.
This is our agenda for today. I just realized I neglected—I mentioned that we needed a minutes taker, but I have neglected to actually get a minutes taker. Do we have any volunteers for dropping notes into the notes page?
Brent Zundel: I can.
Karen O'Donoghue: Okay. Well, that's okay. We'll combine them with Eric's tool, and life will be happy. So, Brent has agreed to take some notes for us. Anybody that is participating in the conversation, feel free to check the notes and make sure that your comments are adequately represented. And is there any agenda bashing? Okay.
The first document I wanted to mention—I don't think we need to have a lot of conversation on it, but I did want to point out that the HPKE document has been forwarded to the IESG. We believe all of the comments to date have been addressed, and so it's beginning the process of moving through the IESG.
Deb Cooley: So it is happily in my queue, and it is behind two other drafts, though. So it's going to be a minute before I get to it.
Karen O'Donoghue: No worries. It hasn't been that long since you've gotten it, so mere moments.
The second document I was going to mention—the chairs have communicated with Neil. He's not here for this meeting. However, the draft-ietf-jose-deprecate-none-rsa15 document has been updated in accordance with the consensus call in the working group that we did around some wording. We believe all the comments have been accommodated, and the people that made those comments have had an opportunity to review them. So at this point, we would like to move this to Working Group Last Call. Are there any thoughts on—any questions or comments on that? Oh, sorry, the deprecate none. So, it is linked from the agenda as the top document. But Neil is not attending this meeting, and so we communicated with him in advance.
All right, so those are the first two documents. The third document, or the third—the next agenda item which includes three documents are the web proof drafts. Mike, up for this? I think we have Mike here and David online.
Mike Jones: Good morning all. Thank you for being here. So, yeah, I’m happy that we got the HPKE draft over into Deb’s capable hands. I know more topics of that kind will come up shortly. But I’m here at the moment to talk about the JSON Web Proof work with my co-author, David Waite.
So, we have done some things since we last met our heroes. Oh, not Madrid, we need to fix that. This was Montreal. So, one of the things that was noticed in review was we were putting optionally algorithm identifiers in JSON Web Keys and COSE keys. But this set of algorithms is not in the JSON Web Algorithms registry or the COSE algorithms registry; it's in a different proof algorithms registry. And so we thought it was inappropriate to use the same identifier in the key. So we’ve introduced a proof_alg identifier to use instead of alg. It should be non-controversial. I mean, the only thought that I’d ask the working group to consider is: should this be a separate set of algorithms, or should these instead be put into the JSON Web Algorithms and the COSE algorithms registries, in which case we would revert this change and make a different one. But we took a stab at saying what this would look like if you keep them distinct.
DW, who is a master of CI, updated the code that runs every time we build the specification, which generates the examples in such a way that now the inputs are deterministic so that the examples don't keep changing each time we build it, which is useful in terms of not having false diffs that are meaningless between drafts.
So, all the rest of what I'm going to talk about is things that we might do next. So, please pay attention and tell us what you think about the things we might do next.
The main thing that has come up from implementers, including Emil Lundberg in Sweden at Yubico and others, is they said, "Well, you know, if you compare JWP to SD-JWT and SD-CWT, SD-JWT has the ability to disclose part of a claim if it's an array or a structure, as opposed to just disclosing the whole claim, yea or nay." And Emil, and maybe DW can tell us who the other implementer was—two different implementers came up with about the same idea. And so there's an issue and we are thinking about whether to do this and how we might do it.
So, you know, unsurprisingly, some of the claims, maybe given name, you're just going disclose or not. But address is the classic example of a structured claim in the JWT claims space. There's a corresponding one happening in space for CWT claims. And maybe you don't want to give the party the whole postal address, but maybe you want to give them the country field in the postal address. There's syntax for being able to do that in SD-JWT and SD-CWT. And there's a proposal to effectively have a claims path in that case—so, country within address, and the value would be US. There is not a pull request for this yet. And particularly for those who’ve worked in this space, we would like to keep this as much like the other things as possible, should this go forward.
The other thing that's brewing in the space that touches or may touch JWP is, you know, while BBS hasn't finished in the CFRG yet, which is a whole, you know, discussion in itself, the authors nonetheless created multiple extension drafts to BBS that are nowhere near as mature as the core BBS spec. The catch is that to use these extensions, they currently require the verifier to support them whether the functionality is used or not, so it becomes a code change whether or not these extensions are used. And also, it requires a fair amount of setup between the parties to be able to effectively use them.
One of them is the BBS blind signatures draft, which allows for messages known only to the holder and not the issuer. And the primary interest is around keys to confirm the holder. So, the holder can disclose values to verifiers. However, as I said, we need to decide whether we're going to work on support for this or not, because it would change the shape of how JWP uses BBS if we do. If we do work on this, it'll probably be in its own draft for the time being rather than in the core JSON Web Proofs draft.
And there's also per-verifier identifiers as the other extension, where you use long-held secrets to generate pseudonyms per-verifier. And again, it's still early, but there's some investigation into this. So, if you have use cases for using either of these, or you want to say we're not interested in those things, both would be useful at such point as we—as the BBS draft is final or becomes close to final, we're going to have to decide whether to hold any parts of JWP for that or just to call it done.
Um, so that's our brief update. What would any of you here or online like the working group to know? And DW, if I muffed anything or you'd like to add anything, please speak up now. Who in this room has reviewed the draft? Brent raises his hand. Brent was an early contributor. Okay, go ahead.
Brent Zundel: Brent Zundel. I'm the note taker; I can do that. Um, you asked a question about support for extensions. I think supporting BBS signatures without supporting BBS blind signatures is silly. I think blind signatures are core to the whole capabilities that BBS brings to the table. Verifier identifiers, I'm not quite as sold on, because of other efforts underway that may not even be compatible with the way BBS is doing things for verifier identification. Um, that's my two cents there. So just wanted to say that.
Mike Jones: Thank you. Do any of you have any reading of the tea leaves about how the blind signatures is progressing in the CFRG? Maybe I can ask that there's two CFRG meetings, but—
Karen O'Donoghue: Okay. John.
John Bradley: John Bradley is an individual. Um, so I agree with Brent that probably BBS without blind signatures is not very useful, especially since a lot of the use cases are for different types of pseudonyms that we're seeing in Europe. Um, there is work; apparently Germany has sort of come to the conclusion that batch issuance isn't going to work for them—it will not scale. Um, so they, Ania and others, are driving BBS work in ETSI. Um, so we need to coordinate some of that better so that ETSI doesn't come up with something different from IETF and JWP. But we have those contacts.
Mike Jones: Do you know if Tobias and Vassilis are looped into that, or is this just a parallel universe?
John Bradley: Um, it is the normal sprint suspects. Um, so but I don't know how deeply Tobias is connected to that.
Mike Jones: Okay. Thanks, John.
Karen O'Donoghue: All right. Any other questions or comments for Mike and David? I think they're putting a lot of work into these documents. It's time for some of the rest of the working group to review them and help us move them forward. Thank you. Oh, wait, sorry, David's in the queue.
David Waite: I did have one thing. Since we had two people who were on a level of interest in the blind signature—you're really quiet, get closer to your mic. Okay, um, that should be better. Um, that isn't any better. Sounds like you're on the wrong microphone maybe. Hold my microphone; it's got muted yesterday morning. Uh, do you hear me now? We could hear that, but speak louder than that. Okay. Um, since we had several people who were interested in blind signatures, um, there's knowing that there's a secret value that the holder has, so say something that's escrowed by a wallet in a digital credential use case. There's also um, having payloads that are basically holder specified and released that were blinded to the issuer, so actual data that's captured in the message. Um, that one's a little bit harder and I'm experimenting with it, but I could use feedback on whether or not we actually do want to have non-issuer payloads in presentations. Doesn't have to be now.
Mike Jones: Okay.
Karen O'Donoghue: All right. Anything else? Thank you again, Mike and David. All right, thanks all.
(Scene transitions to Tiru Reddy presenting)
Tiru Reddy: Can you hear me?
Karen O'Donoghue: Ah, yes I can. Let me get back to the right window for you. All right.
Tiru Reddy: Uh, can I move the slides or do you do it?
Karen O'Donoghue: Let's see. You should have—okay.
Tiru Reddy: Yeah, I can move the slides. Thank you. Good morning, everyone. I'll be talking about the updates to the PQ KEMs for COSE and JOSE draft [draft-ietf-jose-pqc-kem]. So far, we have addressed all the comments received from the working group. The main contention when we presented this last time was whether to use AKP or OKP. I think there was quite good consensus on using AKP. So what we have done in the latest version of the draft is to update it to use AKP. And the draft uses separate algorithm identifiers for both direct key agreement and key wrap. So that way, there is context which clearly distinguishes between the two modes.
Uh, there has been some discussion on whether we need PQ KEMs for COSE and JOSE and whether we can just leverage the HPKE variant of that. Uh, so just we decided to add some clarity in these slides for further discussion. Uh, I think this discussion also happened when this draft got adapted, right? And we wanted to have a draft which is independent of HPKE that does not have to rely on the new modes that were introduced in COSE and JOSE specs. This draft pretty much follows the existing JWE ECDH style key agreement model. Uh, it's basically a minimalistic migration path from ECDH ephemeral shared secret to PQ KEM. Uh, it provides an alternate for deployments that do not require the full feature set of HPKE. And in the recent discussion, the LAKE working group depends on, especially the COSE part of it, right? I think they are using COSE because it's for constrained devices and they are pretty much relying on this draft and they've been using it as a reference for migrating from traditional asymmetric crypto to using PQ KEMs. Uh, we don't have any further comments from the working group, so we think the document is ready for Working Group Last Call.
Karen O'Donoghue: Go ahead, John.
John Mattsson: I don't think it's on. I think it's on now. So now it's on. I reviewed the draft and I agree it's ready for Working Group Last Call.
Karen O'Donoghue: Okay. Thanks, John. Mike.
Mike Jones: Mike Jones. Um, I know we had this discussion a long time ago, but it seems like it's probably time to raise the topic again now. Given we have HPKE and there's a whole suite of post-quantum and post-quantum hybrid algorithms happening in that space, which we can just adopt, and there's other drafts about that, it's not clear to me that this isn't an unnecessary third way of doing the same thing. Uh, why would you use this when you can use the HPKE variants?
Tiru Reddy: Yeah, John, if you—Mike, if you look at the previous slide, right? It's—it's a simple migration, like I said, right? I mean, uh, if you are planning to use—do not want to use the new modes that were introduced and want to just want to use the JWE ECDH style, then this provides an easy migration path.
Mike Jones: But so does HPKE. That doesn't answer the question. Sorry. Why would I use this instead of the equivalent HPKE?
Tiru Reddy: HPKE and PQ KEMs are different modes, right? I mean, the ECDH style is—is like KEMs basically, and HPKE is a public key encryption scheme. So they're—they're two different techniques.
Mike Jones: I understand that. The question is why would we support two? Interoperability will be improved if we only support one.
Tiru Reddy: So it all depends on the migration path, right? I mean, if somebody wants to deploy this mode, right? And for instance, I—I don't want to use HPKE and just want to migrate using KEMs, right? I don't have to be dependent on HPKE as new algorithms come up. This is like an easy migration path.
Karen O'Donoghue: Since there's two other people in the queue, they might be speaking to the same topic.
John Mattsson: John. Uh, yeah, what LAKE needs is a KEM, uh, and also an independent KEM that is not bundled together with a lot of other algorithms like AES-GCM and so on. Uh, LAKE needs that for COSE. LAKE needs a COSE algorithm, then depending on the COSE message, LAKE uses the different—slightly differently, and some of the messages are further optimized to save bytes. But LAKE would need a COSE algorithm registration for a KEM. Yeah, but where it's done is, yeah, that's what—
Brent Zundel: So just to clarify, LAKE needs a COSE algorithm registration for some KEMs, and we're asking the JOSE—JOSE working group for that? That's just—just a—
John Mattsson: LAKE, I don't think LAKE cannot talk for LAKE, but I don't think LAKE has asked anybody, but LAKE was depending on these drafts. This draft was in JOSE for both JOSE and COSE. Yeah.
Karen O'Donoghue: Okay.
Tiru Reddy: Just to clarify, this draft is not just specific for JOSE; it's also for COSE.
Brent Zundel: Yeah, I—maybe I'm not the only—others don't entirely share this opinion, but I think this is representative of a pretty deep problem of tightly coupling JOSE and COSE work in a single document because the dependencies, like across the board, from the message structures, the algorithm support, to the way it looks, to the dependencies, to the places that use it, to the use cases are all different. And we get into a lot of problems with tightly binding these two things together because it—it couples work in ways that are unnatural and unnecessary, and it also introduces a lot of difficulty in terms of who's looking at the document, who's reviewing it, the expertise working on it, etc., etc. That said, I want to go back to Mike's point and reaffirm that like, even—I know we've said here, we've talked about it many times and it's come up—but even in the introduction of this in conjunction with the HPKE work, I asked the question why would we introduce two distinct mechanisms to do effectively the same thing? Not always, but that's often an indication of a problematic design or a problematic approach forward. And it was never really answered; it was just we're going to do both. So the fact that it's coming up again, I think Mike makes a very good point. There's not a compelling reason to pursue this work as I see it now, other than to cause interoperability problems, to fracture the ecosystem, and other such things. Um, that's putting aside whatever dependencies LAKE has. I haven't followed that, but those are LAKE needs around COSE work that should be in the COSE group, I guess? I don't know. But this—this is JOSE, and I think the point stands that this—this work probably shouldn't proceed as is for the JOSE part of it.
Karen O'Donoghue: Go ahead, Hannes.
Hannes Tschofenig: Yeah, I—I think this is a discussion we keep having—the relationship between the two working groups. And in some situations, it seems convenient that there's one document for both of the groups, and in other cases, it's a big drama. Um, it's probably it's a little bit more overhyped than it actually is to have registrations and descriptions for both cases. But I think John was in his previous statement quite clear why he has different design requirements and why he—he wants this approach. That's okay, then the next person will have another case why they want to have a different algorithm. So, I—I don't see this as dramatic as—as some others. If you don't want to use it, don't use it.
Mike Jones: Mike Jones again. Um, so before we would do a Working Group Last Call on this, I think I would like to have a good discussion on the list of what are the COSE use cases that require this approach as opposed to the HPKE-based approaches, which we'll discuss in upcoming presentations. Um, I mean the answers I've gotten in the room, I would paraphrase as: well, it's a different mechanism. I know it's a different mechanism; I'm asking why we want that different mechanism here in JOSE. Thank you.
Brent Zundel: Uh, at the risk of being dramatic again, I—I do want to point out that there is a real cost to the larger ecosystem of registering algorithms and having interoperability questions about what—who supports what, what the registry implies to implementers and users of libraries. Like, it—it's not as simple as if you don't want to use it, don't—don't use it. There's—there's much broader implications and greater cost to having something registered. So it should be a very intentional choice, not something that we just did because—because it's different, I guess? I don't know. It—you greatly oversimplify the—the implications on the—on the broader deployment ecosystem, Hannes.
Hannes Tschofenig: Well, um, I—I don't see that great cost for the whole ecosystem because—not too long ago, in—in some ecosystem, specifically the—like OAuth ecosystem, like the need was mostly for digital signatures. And that was not a big issue that there are—that there were other mechanisms. So people just didn't use them and didn't implement them, and that was all good. And there are—we have tons of other specifications that then describe very precisely on—on when to use the other mechanisms. Like we just had a few minutes ago with the JSON Web Proofs—just because those exist, it doesn't mean that you have to implement them, you have to do interoperability tests and so on. And now, specifically nowadays when in days of wide coding and—and AI, um, when implementation costs pretty much go down to—to zero for—for those things. I—I fear it's—it's even less dramatic. Like a year ago or two, probably people could have said, "Oh, big drama, I now need to spend months and months implementing some of that stuff." Uh, that's not—not true anymore.
Philip Blum: Library sizes and bundle sizes are directly dependent on the number of algorithms that you have available. So saying that implementation is cheap because of AI is—is—it's beside—it's just besides the point. Um, the fragmentation of the ecosystem is real, um, because you're gonna—you're gonna end up with implementations like you said that chose one and didn't want to use the other and others that did something a little bit different. Um, and then of course you've got those interop problems where two libraries or two system components can't talk to one another because one chose HPKE because it needed—um, it needed hybrid composites, and the other one went directly straight to post-quantum with—with this draft. Um, it is—for JOSE specifically, it is two ways of doing the same thing, and we should try to avoid that.
Hannes Tschofenig: It's funny that you say that because you just gave an algorithm presentation yesterday, Philip, in OAuth, so yeah, that fits quite nicely then.
Philip Blum: I don't see how that's relevant at all.
Jaroslav: Jaroslav. Uh, yeah, from my perspective as an implementer, having two ways to do the same thing when you need to interoperate with other providers is not great. Meaning that I would need to implement both because I don't know up front, will everybody who I speak to will be speaking HPKE flavor or will be speaking PQ flavor? I would need to maintain both, I would need to figure out vulnerabilities and bugs in both. So, yeah, my strong preference would be to go with the one approach at this stage.
Karen O'Donoghue: Um, I'm sorry, I'm just catching up on chat real quick. The—the unresolved question seems to be: what's the positive use case for JOSE versus COSE? So, um, did we have anybody who had an answer to that?
Tiru Reddy: Uh, I can at least talk about the use case that interests us for our networks, mobile networks. So there are two paths of migration that we see: either moving to hybrid schemes or moving to pure PQ, right? For hybrid schemes, unfortunately, we don't have any other mechanism other than using HPKE, because that's the only one which gives you a native support for hybrid KEMs HPKE model with both PQ and traditional. But if someone straight away wants to jump from let's say traditional to let's say just using pure PQ, then this provides the most simplest and easy path for migration without having to do new modes like integrated encryption—just leverage the existing modes and—and it—it's a very easy transition path, right? And—and several deployments would require migrating straight away from traditional to pure PQ, and this meets that without having to first migrate to HPKE then—then eventually migrating to the eventual work happening in the HPKE working group.
John Bradley: Hi, John Bradley individual. Um, I kind of have a question for Deb, just to put her on the spot. Um, some—some groups of people have skepticism about hybrid definitely signing, likely encryption. Um, are those groups of people likely to just use HPKE in a pure post-quantum mode or are they going to—is there—do you have you detected any desire to not do HPKE so that you can do pure post-quantum?
Deb Cooley: So I have not looked at this closely at all. Um, the original HPKE was not a post-quantum construction, right? It was just the traditional. Um, the new version of HPKE that they are putting out is a hybrid post-quantum traditional construction. If you wanted pure post-quantum without the traditional algorithm, what are your options in JOSE? This?
John Bradley: Well, I'm assuming that we can—that HPKE can still be used in a purely post-quantum way without requiring hybrid.
Deb Cooley: So, if that's the case, the argument that we need these more low-level constructions may—you know, that might not be entirely true.
Michael Jones: Hi, Michael speaking as an individual. Um, yeah, just to John's point, kind of agreeing with Tiru there, you can do pure PQ in HPKE. I think there's a couple of links to the draft in the chat. I think it's just the nature of the terminology where the H in HPKE is hybrid, but that's a different hybrid from hybrid PQC. So, uh, yes, you can do both with HPKE.
John Bradley: Okay. Hi, yeah. So my comment is because the—the hybrid came up. So like, wouldn't this fit with the composite KEM, right? Because if—if you wanted a hybrid, that would be a way to fit this in like—the—because the way composite KEM, which is in the LAMPS group about to be standardized, it's just—it's basically a KEM API wrapper, right? It looks exactly like a KEM, it acts like a KEM, you could use that, it would plug into this nicely, you don't have the HPKE complexity. So I mean, you can do the pure mode, you can do anything that's basically a KEM with this thing. So, uh, yeah, I'm just bringing that up because someone, I think, mentioned that there wasn't another way to do hybrid, but you could do something like a composite KEM to do a hybrid and I think it would fit right into this too if—if that was something that people wanted. That's my comment.
Tiru Reddy: Yeah, thanks John. I'm aware of the draft; this draft is—this draft is just specific for using pure PQs. So it's just using the very same KDF APIs that's used by LAMPS working group. So you can see very many similarities between this draft and the LAMPS draft.
Karen O'Donoghue: All right. Uh, so with two ways forward, I mean, we need to discuss this on the list. One is to go to Working Group Last Call or the second one is to have the discussion prior to the Working Group Last Call. Um, and the chairs and the authors will sync afterwards and figure out which is which—which way we're going to go, if that's all right. I see raised eyebrows. Holder of raised eyebrows.
Brent Zundel: Uh, I—I don't quite know what it would mean to go to Working Group Last Call after that discussion. Okay. Maybe I—I am missing the bigger picture here, but seems like there's a lot of concerns with the work proceeding and so Working Group Last Call doesn't seem quite like the right step at this stage.
Karen O'Donoghue: Let me see what—okay. Checking in with folks.
Deb Cooley: So one of the options is to split the draft, right? And just, sorry I've got a visitor. Um, to split the draft and just do a COSE version of it, in which case you could take this back to COSE; you don't have to do it in JOSE, really. Um, sorry, he likes video calls. Um, and the question is whether you—whether you need two ways to do it. Do you need a HPKE way and a just straight up generic pure KEM way? And I can see from an interoperability point of view, from an implementation point of view, you don't want to have two ways to do the same thing. So there has to be a compelling reason for why you want to do it—why you need two ways to do it, be that HPKE or be that just straight up regular KEM. That's what you need to have the conversation on the list about: what are you going to do about the JOSE piece of it? And if you decide not to do the generic version that you have here, then you just split it out and take it back to COSE for the COSE piece.
Karen O'Donoghue: Okay. All right, we will take it to the list. So, it looks like I uh—jumped over—I made the presentations out of order, so my apologies. Good help's hard to get sometimes. Do you want the clicker? So this is the previous item on the agenda that I accidentally skipped over.
(Presentation on PQ/T Hybrid Composite Signatures for JOSE and COSE)
Lucas Pardue: Okay, so hi everyone. So this talk is about the hybrid composite signatures working group document for JOSE and COSE. So it was presented during multiple IETF meetings. Um, it got adopted in January this year and it was updated last month following this adoption. So first, just a quick reminder of what this draft is about. So the goal is to define different hybrid composite signature schemes for JOSE and COSE, in particular combination of ML-DSA for the post-quantum component and either ECDSA or EdDSA for the traditional traditional component. So you have the list of registered algorithms given in this slide.
The draft also describes how to handle the key generation, signing, and verification for these composite algorithms, in alignment with the construction described in the LAMPS composite draft. We also use the algorithm keypair key type, and we only support the seed representation for ML-DSA private keys to stay consistent with the COSE pure ML-DSA draft. We also discuss multiple security properties in the security considerations section, like separability, key reuse, key integrity, or the lack of strong unforgeability security, and we include multiple test vectors.
So what happened since the last IETF meeting? So the draft got adopted as a JOSE working group document in January. Following this adoption, we had an update. So in this update, we included new test vectors for all combinations for JOSE and COSE. We also rewrote the security consideration section with more details, better explaining the security objectives, how the lack of SUF-CMA security—so this construction should only be used when existential unforgeability is acceptable. But we also explain how to handle—how to deal with replay protection, for example, and we have some discussions regarding key integrity and key reuse. And finally, some editorial modifications.
And so, looking further ahead, we plan to—in the next update—to include a few modifications to address a comment which was received after this update: so regarding point compression and the presence of ASN.1 computing, so that we want—that we don't want.
So for the next steps, we have a few questions for the working group: is the list of registered algorithms satisfactory? Is it not too long, not too short? Is the security considerations section satisfactory? And if you have any issues to be solved to follow—to allow the progress of the draft, and what kind of improvements you are looking for before considering a Working Group Last Call? So I would be happy to receive your comments and suggestions. Thank you.
Karen O'Donoghue: Any questions? Who's reviewed the document? Okay. Request to the working group to please review the document and put some comments in. Go ahead, Mike.
Mike Jones: Yeah, I mean the one thing that I don't claim sufficient expertise to answer is whether this is the right list of algorithms. This is where it would be great if we had, you know, a John Mattsson or somebody who is closer to the cryptography vet the list. I think the draft itself is solid.
Karen O'Donoghue: All right. So with that, thank you Lucas. Okay, thank you. So maybe some people would like to review and share and send their comments to improve the draft. Thank you.
Karen O'Donoghue: Yes, please review, comment on the list, review on the draft. Thank you very much. All right, next is Brian and Philip.
(Presentation on JOSE HPKE PQ & PQ/T Algorithm Registrations)
Brian Campbell: Okay, thank you. Topical, I guess. I'm here to talk about a document largely that Philip worked on and I've attached myself to, thanks to his generosity: about JOSE HPKE PQ and PQT algorithm registrations.
So what is in this draft? I know a lot of people don't have a chance to read things beforehand; I certainly appreciate that, so I'll try to give a little summary. This is a focused algorithm registration document. It doesn't do anything else. That's it, just registers algorithm code points. It registers both pure PQ and PQT hybrid or composite—I’m still struggling with the name there because hybrid hybrid confuses me, but we seem to have settled on hybrid, so probably call it that going forward—both those algorithm identifiers for JOSE. It includes test vectors for all registered algorithms, and it builds entirely on established mechanisms developed in this working group and elsewhere in the IETF, specifically the JOSE HPKE draft that we just learned we're sending along to the IESG for publication, where this working group spent a lot of time trying to build a coherent and meaningful model to represent HPKE messages in the context of JWE. And I think we settled on a pretty good place for what that message representation looks like, and this working group is producing that document and getting it published. This builds on and registers algorithms in the context of that JOSE HPKE framework period, and the algorithms that it registers are from the new-ish soon to be probably closed HPKE working group where they have a distinct draft. I don't know if folks haven't followed it—the HPKE working group has basically done a bis on the original HPKE document, which is largely just a rewrite, clarification of the existing work, moving it from informational to standards track and fixing a few nits and things here but here and there, but it's basically the same thing. And then they have an additional document which is the definition of PQ and PQT hybrid KEMs for the HPKE framework. And that's all defined in this IETF HPKE PQ document that is progressing either alongside or shortly after the bis-ish HPKE document. And this document that we're presenting here relies entirely on those two constructs to register the PQ and PQT algorithms defined in the HPKE document for use in the context of JOSE HPKE. No new crypto methods or mechanisms are introduced, nothing is rehashed. It's a very baseline, basic document that seeks to accomplish making these algorithm suites available in the context of JOSE HPKE.
Why does this draft exist? We got to some of that in the contentious discussion a few minutes ago. But effectively, as the HPKE work progressed through this working group, Philip raised the question about, as well as a fairly in-depth pull request on the HPKE document itself, asking why we don't use this new framework that we've developed as the vehicle for representation of PQ and PQT algorithms going forward for all of JOSE. There's a lot of words there, and he basically recommended doing it in the context of that very document. There was some pushback, and I think it was rightly so that we didn't want to hold up the HPKE framework itself for delivering the PQ PQT content there. But conceptually, the idea I think is very valued. So the HPKE stuff proceeded, and Philip took that pull request and basically transferred it into a very concise, nicely done document that frames it as just registrations for the underlying HPKE framework in JOSE.
Um, there's some choices that were made because they have to be made about the algorithm suite approach. Right now in the context of the document, there's five KEMs across the two different categories of PQ and PQT. Um, you see here I decided to scratch out hybrid and call it composite just to confuse myself for you; I don't know if it helps, maybe it makes it worse. But we've got the—that's an angry-looking glare—um, you list them out there: there's ML-KEM 768 with P-256 and with X25519, as well as ML-KEM 1024 and P-384, and then we've got the pure PQs with 768 and 1024. Um, there's one KDF across all of them, just SHAKE-256. It's used inside of some of the ML-KEM things. It's nice to have one common KDF hash algorithm, one piece, one thing to use throughout this context. It’s helpful. There’s two AEADs: GCM-256 and ChaChaPoly. And each suite has two modes building on top of what we established in the HPKE document itself: one for so-called integrated encryption where the HPKE stuff happens sort of internally to the JWE HPKE framework and is directly encrypted and encapsulated—I won’t use the word encapsulated even though I just did—encoded in that message format. And then there's the key encryption mode where the HPKE stuff is used to encrypt the symmetric content encryption key and then standard vanilla JWE is used after that. Um, we did omit ML-KEM 512. I'm not an expert in this area, but it seems like there's growing concerns, growing consensus about the security level of this and potentially cryptanalysis sort of reducing what security level it actually provides. It seemed optimal to just drop it and not try to push it forward in the sake of like avoiding potential security questions as well as reducing the overall number of algorithm suites implemented. I saw a hand pop up, but I don't know if that was—
Philip Blum: That was me. Um, I decided to not include ML-KEM 512 for one reason—maybe—maybe two. One, the HPKE PQ document itself didn't start with ML-KEM 512. It was added just for completeness with the exact same concern, so I'm repeating it here on why it wasn't included. The other, which is—let's say—exhibiting those concerns in practice, is that libraries—not all, of course, because some libraries just want to implement everything—some libraries chose not to implement ML-KEM 512, and that includes BoringSSL, which directly transfers to Chromium and therefore the Chrome browser and Edge, where ML-KEM 512 will not be available.
Brian Campbell: Yeah, I was just going to say in the composite KEM as well we didn't have ML-KEM 768 either, so we left out the ML-KEM 512, so it's kind of—it's in alignment with that as well.
John Grey: Just if you could cut something—do you need three hybrid KEMs? If I would—I don't know, it's fine. If I would cut something, I would cut the P curves. The only reason they are like included in the hybrid in TLS is that people have certified implementation of the P curve and they want to add ML-KEM and claim—then they have a NIST FIPS certified hybrid also. But—
Brian Campbell: We do have a slide on trimming down the algorithms coming up. I'm fine with the current—if I cut it down, I would keep X25519.
Lucas Pardue: Yeah, the X25519 isn't—I don't think on anybody's list for cutting, but some of the other ones were discussed. Turns out that choosing an algorithm suite is harder than you might think. But these are the ones that are initially reflected in the document. And the next slide talks about some feedback we've received on list, some discussions we've had—nope, it's not the next slide, it's the next slide after this. This is just the sort of menu of currently offered algorithm suites. I don't think this is anything different than was shown on the last slide, it’s just laid out in a nice table form.
So, and it’s not even this slide, it's the slide after this, but this leads into it. Some of the mailing list discussion: ChaChaPoly variants. So, it's potentially possible that AES-256 covers all the practical needs in the context of this work. Notably, JOSE itself doesn't currently have ChaChaPoly AEAD algorithms registered. So at the very least, it's a bit strange to have the HPKE key encryption variants using ChaChaPoly and then mixing that with AES because there's no ChaChaPoly equivalent registered in the current suite of JOSE algorithms. So removing those at least would make sense for some—not algorithm parity, but matching of similar algorithms in a single message, and that's not even available in the current suite. It might make sense to drop them all, but we're kind of trending towards at least dropping that set of the key encryption and maybe all of them.
Orie, who is a very busy AD, is not here, but he suggested that due to low P-384 adoption, maybe just leave out ML-KEM 1024 P-384 hybrid composite. Um, I think Philip summed it up here nicely with like: I don't really know. It is the same security level there, but it's not a hybrid composite. I don't know how important that is; I guess it's a point of consideration. I don't have a strong opinion on it.
The general idea of security level matching: whether using AES-256 or 128 where it might be more similar to the other algorithms, was mentioned by our new chair Michael. Um, I think there was a pretty long discussion on list here where um, both the author authors believe that basically the current proposals are good enough. Using the higher-key length AEAD seems sufficient and reasonable in most cases, and trying to introduce the possibility of a shorter-keyed AEAD just wasn't worth the overhead and mixing and matching and having multiple algorithm supports. And I believe that is—oh, Deb Cooley is on the queue.
Deb Cooley: I was going to ask you to go back to the previous slide. Sorry. So, so, so—so this is an AES question. So, do you not already implement AES-128?
Brian Campbell: The—there is an AES-128 and 192 algorithm for the in JOSE for content encryption or the regular AEAD there. So it is likely available, but this was just more about like trimming the cardinality and number of possibilities just in this set of new registrations.
Deb Cooley: And so are you using this AES for content encryption or for key encryption?
Brian Campbell: Both, depending on the JWE HPKE mode. So you can do either depending on the algorithm chosen. That's kind of what's represented by the parenthetical -KE for the HPKE JOSE framework underneath. Key encryption is possible where the HPKE algorithm itself, including this AEAD, is used for key encryption, which is then used—that encrypted key is used for encrypting the rest of the message per normal JWE framework. And then the integrated encryption is where it's used directly to encrypt the message itself and then that's encoded inside a JWE.
Deb Cooley: Right. So why would you add it as a key encryption? I agree with that. Like if you're not using it for content encryption, I don't know why you would add it for key encryption.
Brian Campbell: Yeah, I—don't—I don't know how often ChaChaPoly is used for key encryption. Um, AES-256-GCM is not also classically for key encryption, but um—so I don't know. Anyway, my question—my original—the reason I got in the line was just because to—to ask why you were picking AES-256 when normally for some of something and I like things to be matchy-matchy. Um, it's just an old habit. And so for the smaller versions of ML-KEM, AES-128 is more matchy-matchy in terms of security strength. Um, I just didn't know why you were picking AES-256. If you were just doing it to have a minimum number of algorithms, that's fine. If you were picking it because you thought it was—it was going to be post-quantum secure better than 128, I think that philosophy on that has changed.
Brian Campbell: Yeah, no, it was much more entirely to keep the set of algorithms down.
Deb Cooley: That's fine. That's fine. And then I think if you really want to go further, you ditch the ChaCha.
Brian Campbell: Yep.
Karen O'Donoghue: Michael.
Michael Jones: Michael speaking as an individual. Sorry, Deb's point that she just made was exactly what I was trying to get at on list. Um, I guess I'm happy with what's in there at the moment. Um, I guess the approach is slightly different to the HPKE working group draft and the non-PQ JOSE working group draft, so just kind of acknowledging that, the one you had on slide two. But if the reason is keep it simple, then that's fine.
Brian Campbell: Yeah, thank you. I tried not to misrepresent you here, but I wanted to say something anyway. But one difference with HPKE itself is it's a bit more of like an à la carte algorithm selection where we have a little bit more of a suite format here, so it made sense to reduce in that context algorithm choices as opposed to the way that basic HPKE will offer just the AEAD independently.
Jaroslav: Jaroslav. On the topic of AES-256 versus 128, one other point I'd like to make is at least in modern hardware, the performance difference is really small, so it's okay to go with AES-256, I think from that perspective at least. And when it comes to ML-KEM 1024 P-384 hybrid, my slight preference would be to keep it simply to match TLS. So when you define a policy of what does good look like in certain environments, you have this hybrid available in TLS along with two others, so it would be great to have this as an option in JOSE as well.
Brian Campbell: Thank you.
Karen O'Donoghue: All right. John.
John Grey: Yeah, hi, John Grey from Entrust. Um, yeah, I noticed I think you said the KDF is SHAKE, and my only thought there—and I'll have to look at your draft in more detail—but just thought I'd mention is like for instance in the composite KEM, we use SHA-3. So is this KDF used to combine the shared secrets together or is this something different the way it's used here?
Philip Blum: This is the HPKE KDF, so it is part of the HPKE construct.
John Grey: Okay, so it's different. I just wanted to make sure that at the crypto layer that we're compatible because we spent a fair bit of time with the HPK—I—in the different domains and all that making sure things are compatible between the two things, so I just want to make sure there's no compatibility here. Okay, so that's good. I'll just check your—look at your draft and just make sure things look right.
Philip Blum: Yeah, I—I don't think it's a compatibility issue. I may have misspoken when I said it's used throughout all the algorithms. It's used inside of the ML-KEM stuff, but I wasn't aware—maybe it sounds like SHA-3 itself is used as part of combiners in the composites. Regardless, it shouldn't be a compatibility thing, it’s still intentionally trying to just limit the number of options and pieces. But do please take a look and let us know if we're wrong there.
John Grey: Yeah, I'll take a look and just see if I notice anything. Okay, thanks. Good work.
Brian Campbell: Thank you. Okay. Mike, can you hold to the end or do you have—the same thing John said: like the X-wing stuff, it really is SHA-3, not SHAKE. So if you want to avoid introducing a new primitive in the world—oh, I'll take a look too.
Um, just we do want to trim some of the algorithms; the exact set is a little unclear. I wanted to get the temperature of the room, but I'd rather get the temperature of that on the list later. But here's kind of some of the options and how it might trim down the numbers—particularly getting rid of some or all of the ChaChaPoly variants would be great, I think in most people's opinion, or at least most of the authors' opinion. Um, just noting, a lot of work went into this where all—a lot of content automation around the generation of stuff in the document, including algorithm tables, the IANA entries, all the test vectors, the JWK examples are all code generated, and everything changes upon changing the algorithm set, which means we could regenerate all this stuff very easily and consistently if we chose to pare down some of those algorithms or, forbid, add some new ones. Adapting this to whatever we decide, whatever the consensus of the working group might be around the algorithm sets, would be very trivial and also likely not to be broken. And Philip did also put some work into a COSE variant of this work, this automation work, and if anyone's interested in that, he has offered himself up to be contacted if they want to take a look at that. Hopefully, you know where to find him.
Um, a little bit of lag there. So, I know this is being discussed right after this, but there's also the COSE-JOSE PQC Hybrid HPKE draft. This draft, I believe with Tiru and Hannes, have done a lot of work on this, but it has some differences from the work that we're proposing here. Largely, it reintroduces and rediscusses a lot of mechanisms that are already established in its normative references, specifically some of the HPKE and HPKE PQ work. There's a lot of repeated or duplicate content there. This sort of thing can be a source of like a lot of bike shedding, drift between the content of those documents, and delays in the work. It does have ML-KEM 512. It doesn't have examples or test vectors, as we have discussed for better or worse inthe context of this meeting and others. That document spans both JOSE and COSE and unnecessarily couples them together. Document two will be presented to the COSE working group a little later this week. In draft nine of this work, back in December, it didn't include any PQ pure PQ work, and then shortly after that, draft 10 in February added the pure PQ stuff, shortly after Philip and I introduced our draft to the list. In contrast, the draft that we're looking at here is JOSE only, very much intentionally. It's a straightforward algorithm registration. It introduces a bunch of very nice test vectors and delegates as much normative stuff as possible to the normative references that it makes. It tries to be very straightforward and concise in what it accomplishes.
Um, we have talked at almost no length, but Karen sent an email requesting on behalf of the WG chairs that, noting that there's a fair amount of overlap between these two drafts and made a request to consider how and if they might be combined. Also mentioned—and sorry to quote you here, Karen, but—that we would like to continue to keep COSE and JOSE HPKE aligned. I think I've already said it a few times in this meeting, but I'll say it again: I think this should be a secondary goal at most. There are times when there's a good reason to have alignment between the two, but COSE and JOSE are in fact different working groups. And for better or worse, JOSE and COSE have already drifted apart. They are in fact different, both in the way that some of the messages are structured, some of the algorithms that are even possible, as well as what algorithms have even been registered. For example, COSE has bare AES-CBC algorithms registered. It has ChaChaPoly AEADs registered. So some of the questions and arguments around what algorithm suite should be supported at the HPKE layer don't even translate naturally to what they would mean in JOSE because the underlying or side pieces of those specifications don't align already. I think appropriate alignment, appropriate levels of alignment are still possible across multiple documents and multiple documents in the working group where the expertise around that work is already existing. And I think we've seen this happen with some bumps and bruises, but relatively well already with the JOSE and COSE HPKE work, which are separate documents, came up together in their respective working groups and maintained some measure of alignment between the two but are distinct, different documents that aren't tightly bound to one another.
So with that, my proposal on a way forward here is to adopt the draft that I presented here. Keep it in JOSE, this working group where we're at right now, and keep the scope to JOSE alone. Add Tiru and Hannes as authors on this document as acknowledged to their prior work in this area and efforts in this area. And take ready cose-jose-pqc-hybrid-hpke to COSE, consider its adoption in COSE. Obviously, that's a decision for the COSE working group, but I would suggest it be taken there and narrow the scope of that document to COSE only. And if desired, utilize some of Philip's recent efforts in this area to automate and help build the content in there. But that's obviously decisions for that document and those authors if they would want to proceed with that. Of course, there's one more slide. That's what I got. Thank you all.
Karen O'Donoghue: I'd like to discuss the way forward after the next presentation. I have a slide after I saw you added that agenda item, but I wanted to speak to it. Oh yeah, no, that's fine. We did add that agenda item at the last minute. Mike, is this a question for clarification or a question about way forward?
Mike Jones: Neither. Okay. I agree that we shouldn't blindly think that we keep COSE and JOSE synchronized just for the sake of doing it because the use cases are different. That said, to the extent that the same functionality is needed in both worlds, and there will be a core overlap where it is needed, I would sure hope that it's done exactly the same way using the same algorithm names, etc. Now, how we do that in terms of the process of documents and authors, I'm not taking a position. But I do want both working groups to thoughtfully consider what algorithms should be registered in both and do it exactly the same.
Karen O'Donoghue: Okay. Thank you. All right, Tiru and Hannes. I'll present the slides. Yeah, let me get to that point. You should have control.
(Presentation on PQC Hybrid HPKE for JOSE and COSE)
Tiru Reddy: Yeah, I'll talk about the post-quantum and hybrid KEMs for HPKE with JOSE and COSE. This draft has been around from 2024 even before the HPKE working group was formed. So we were leveraging the X-wing work as a reference since that was already deployed. Because we were quite interested in the hybrid schemes as a potential transition from traditional asymmetric cryptography to using PQT schemes. This draft has been presented multiple times at various meetings, both in COSE and JOSE working groups. But at the time, the decision was deferred that the working group will not have any cycles to look into this document till the COSE and HPKE drafts were complete. But in the meantime, there are so many comments that we received and I think we published around close to 11 versions to address the working group feedback so far.
Yeah, the other draft that was just submitted was submitted in Feb 2026. We have not received any comments from the authors of the other draft to enhance this one. So they decided to go and publish an independent document. That draft only registers COSE. This draft registers both JOSE and COSE. Our proposal is a single document to review, adapt, and maintain. I mean, I mean just to make progress and without having to figure out which draft to pick. We can add Philip and Brian as co-authors and make progress on this document as hybrid is something that I see, at least, has made tremendous progress within TLS and IPsec and has already been integrated in various open-source libraries. But the hybrid schemes are not yet in a stage where even it's adapted and it's impacting us to take this work back to 3GPP, which is looking for a stable reference to discuss in the 3GPP specifications. That's it from me.
Karen O'Donoghue: Are you still talking, Tiru, or did—
Tiru Reddy: Yeah, I'm done.
Karen O'Donoghue: Oh, you're done. Okay. That would explain the silence. I wasn't sure if we had an audio problem. All right, any questions or comments?
Mike Jones: Mike Jones. So, one of the things, I'm looking at the current draft of the document. One of the things that surprises me is it's still attempting to register polymorphic algorithms. It doesn't include separate algorithms for use with integrated encryption versus the use of key encryption, which both the COSE and the JOSE HPKE drafts do. So at a minimum, that would have to happen to this draft if it's going to go forward.
Tiru Reddy: I don't know, Mike, you may be looking at the wrong version, probably. But if you look at the latest version, it has—if you look at the IANA registry, we have added two different variants, which is HPKE and HPKE Keywrap, basically just to align with the COSE-JOSE HPKE.
Mike Jones: I'm looking at 04 as in the data tracker.
Tiru Reddy: We are way—we are at 11, basically. So I think you're looking at a very old version.
Mike Jones: Oh, okay. Search failed me. Thank you. And then I'll make the comment I was going to make after Brian's presentation. On one hand, I don't think we should be blindly or sort of just mechanically keeping JOSE and COSE aligned just for the sake of doing it because the use cases are different. That said, to the extent that the same functionality is needed in both worlds, and there will be a core overlap where it is needed, I would sure hope that it's done exactly the same way using the same algorithm names, etc. Now, how we do that in terms of the process of documents and authors, I'm not taking a position, but I do want both working groups to thoughtfully consider what algorithms should be registered in both and do it exactly the same.
Karen O'Donoghue: Okay, thank you Tiru.
Tiru Reddy: Yeah, I just wanted to thank Deb, right? I think that's giving a direction for us to make progress. So we'll have meeting scheduled after IETF and then figure out a way forward.
Karen O'Donoghue: Okay, thank you Tiru. Um, so to summarize: we will continue to keep COSE and JOSE aligned where possible, but we won't be shackled together unnecessarily if it doesn't make sense. And the four authors of these two drafts will get together and figure out the way forward for these two drafts, either two documents, one in COSE, one in JOSE, or one document. And you will follow Deb's guidance on test vectors and limiting options. Um, anything else? Okay. Um, with that, I think we are—oh, wait, let me take the slides back from Tiru. I'm pretty sure we're at the end. Uh, if anybody has any last-minute questions or comments, feel free to get in the queue while I double-check that I haven't missed anything else on the agenda.
Uh, I guess that's it. So, if there's no other business, thank you all for coming. Thank you for all of the authors. Please, people, review and comment on the documents, and we will move on to Vienna. And you have an extra nine minutes in your day. I'd also like to say thank you to Brent for the notes, they were really thorough, so thank you. Yes, thank you for the minutes. And thank you for the feedback from crypto world.