Session Date/Time: 21 Jul 2026 12:00
[00:00:05] Sophie Schmieg: Reflected it in
[00:00:06] Karen O'Donoghue: the notes.
[00:00:07] Yuzuru Someya: Yeah.
[00:00:08] Karen O'Donoghue: It's Brent right there. Now I see him.
[00:00:10] Sophie Schmieg: I haven't seen him all week.
[00:00:12] Karen O'Donoghue: How are you? Oh, darn it. Okay. It is 02:00. It is about time to start. If somebody in the back of the room could close the door over, that would be really handy. And while we're gathering, we have not gotten a minute taker in advance. Do we have any minute takers? I knew there were tools now that do a lot of this. Who is?
[00:00:59] Deb Cooley: Claude. Claude. Okay.
[00:01:03] Karen O'Donoghue: That's always a possibility. Anybody? I guess Ecker's tool has become quite popular. I will tell you that it does not it gets names wrong and people wrong. So if you wanna be properly attributed. In the past, I've guilted people into it, but I don't see anybody volunteering. So I guess we will actually make use of the AI tools that are available. And, it will be your responsibility to review your materials. Okay. I think we have hesitated long enough. All right, let's get going. So welcome to the Jose Working Group. This is an official meeting of the IETF. As you have agreed to when you registered for this meeting and also when you signed up for Data Tracker, you have agreed to abide by this note well. It is all of the procedures and processes that the of the IATF. If you have any questions, feel free to ask any of the chairs or Deb Cooley who's our AD or any of the ADs. But please remember that you are obliged to be familiar with and to follow all of these rules. Next. Just as a couple quick reminders, these are the meeting tips that the LLC staff have prepared as part of their standard set of slides. So you can take a quick look at those if you have any questions. And finally, these are the resources. Short reminder to use supportietf dot org if you're having any problems, technical or otherwise. That's the way to get your problems addressed. All right. And this is our agenda for today. We do have one agenda bash. We're going to move the BBS presentation up to accommodate, a conflict. So we're going to do the first two documents of our working set of working group documents first. And then we're going to move the BBS document up and then we'll move on to the rest of the documents. Are there any other agenda bashing requests? Nope. Excellent. So we have two documents in working group last call. The first one is the HPKE with JWE. The it's been a little bit confusing because we did a second working group last call after it went through the IESG. I hope between Deb's email and our email, it was clear what we were doing. There is a parallel IETF last call going on on this. It is limited to just the scope of removing those two algorithms. At this stage, on the mailing list, there have been a number of people that have spoken in favor of removing the two algorithms. There has been nobody who is opposed to, the publication of the document. And, as such, we plan to, by the end of the day, declare this working group last call, second or third working group last call, depending on how you calculate it, as closed. And we are passing the document back to the ISG with that and moving it out of that state for our working group. Is there any questions or comments? Any discussion? Nope. Excellent. So that takes us to the second one which is Neil Madden's document on deprecate none. This is also in Working Group last call. A while back you will have seen that we opened the Working Group last call and Neil was the only one that responded. And then after some, an extension of the working group last call, we extended it and asked for reviews. And Philip and Brian were both provided their comments that the document was ready to proceed. However, nobody else in the working group did. I mean, this room is pretty full. It was a really short document. And since we have no dissent and since it was accepted as a working group document, we plan to take a poll in this room. So have two hours to read we plan to do a poll and verify that there's no opposition to publishing this so that we can declare consensus. However, at this stage, would like to say it is deeply disappointing to have a working group accept a document and a fairly active working group like this one and a short document and have the lack of response to the working group last call. It makes it kind of hard to get the work done. It makes it hard to document the consensus going forward. It makes it hard to write a Shepard Reddit that says there's great working group support for this document. So please, in the future, review it and get a quick, just a really short email to the Miss that says, I see no issues with this document. It would be really helpful. I was not planning on giving them two hours to read it. We were going to do the poll now. Poll, you Oh, after can read it. So, with that, I'm going to start our poll. So every, we didn't say this at the beginning, so I'll talk while you all are doing your voting. Don't forget to log in to MeetEcho, and you will need to be logged in to MeetEcho to complete the poll.
[00:08:01] Quinn Dang: Which document was that?
[00:08:03] Karen O'Donoghue: It's the Jose deprecate-none. I'm speaking from memory but I think it's like six pages. It's short.
[00:08:17] Yuzuru Someya: Seven pages.
[00:08:17] Karen O'Donoghue: Seven pages. Oh. Oh. I stand corrected. Alright.
[00:09:09] John Bradley: No. It's not visible. Fine.
[00:09:18] Karen O'Donoghue: Alright. I think with that, we we we have done everything we can do to establish that there is consensus for this document. There's no opposition. And with that, we will close out this one as well this week. Thank you, everybody. So, Christian? Yep.
[00:09:53] Co-Chair: John clicker or shall I run it?
[00:09:56] Karen O'Donoghue: Do you want him to click or you're gonna click?
[00:09:58] Christian Paquin: Well, I can click. That's fine. Okay. So hello. My name is Christian, and this is a presentation and on BBS and modular subproofs with JSON web proofs. To give you a bit of context, the core idea is to introduce a modular proof system for the knowledge proofs built on top of JSON web proofs. So this is a rather old research concept, but for some reason, it has never been properly standardized from what I experienced. What we are seeing right now is basically people are building special purpose zero knowledge proof systems for their use case. And this is an attempt to basically build a generic mechanism for us to have different sub proofs work for the different use cases, but have one generic general mechanism that everyone can use, and then you can have your own special kind of sub proof for whatever you need. But we would like to generalize the core part of it. It's well understood. There there are some vision papers around it. It's, in in general, it's a rather old technique called commit and proof that's truly twenty years old in cryptography. It has been in all of the old anonymous credentials work, but it has never been really used in standardization from what I've seen so far. Yep. So how it works in general is you define a core proof system, and this core proof system would be your normal signature scheme over the attributes. So, for example, it could be BBBS. But normal BBS only allows you to either reveal or hide attributes. This extended version would allow you to reveal attributes. So if you want to disclose your name or whatever attribute, it allows you to hide them, but it also allows you to commit to the attributes. And those commitments can then be taken as input to additional sub proof systems. So we basically have a separation layer where we say, okay. Let's say for expiration time. For expiration time, I'm not gonna show the expiration time, but I'm gonna generate a commitment, a cryptographic commitment. And this can be then input to a range proof so I can prove it's not expired without revealing the expiration time. So it's basically a modular zonology proof system that tries to make the complexity more manageable by by having the commitment layer in between so we can properly and independently define the subproof systems on commitments and having this core proof system that kind of binds everything together. The advantages are it's we can basically define optimal instantiations per module. So for example, for range proofs, there are still things happening. Right? We might be starting with some more conservative range proof that is based on signal protocols, and maybe in a few years, people are more comfortable deploying bulletproofs or whatever. With this kind of system, we don't have to scrap the whole thing. We can just say, okay, there's a new subproof for range proofs. We cannot pull that in, and we have this layer of commitments in between that properly separates it. It allows us to to basically evolve over time. That also means we can, for example, on the crypto agility side, we can move certain things off the system already to post quantum if we have commitment schemes that that are supported by the different parts. And what we've seen is what I said before is basically we see very different requirements. For example, for privacy pass kind of use cases, you might want to have something that does rate limiting. We can do rate limiting with one of these sub proofs on some attribute that has high entropy. Other use cases might need a device binding, like the digital credential use case. We can do that with a subproof. So we can basically solve the problems that are specific for those use cases in a subproof, but we can generalize the the core construction of it. So that is the general concept, and the draft currently also proposes one initial instantiation of the scheme. Based on BBS blind signatures. The BBS blind signature draft has been extended to also include prover commitments, so exactly what we need for this one. So it's kind of like getting an extended BBS version right now. There's a new draft that is also being proposed to CFRG right now that does device binding to p two five six. So from a BBS credential, you can prove possession over public key in p two five six without revealing it. So full unlinkability guarantees for device binding. And we can do other sub proofs like range proofs, etcetera. The idea would be to create an YANA registry for the sub proofs. So we have a pluggable system and have the core like, one core system initially defined, but we can also evolve that over time into other core proof systems. So the the initial questions I tried to answer was, like, for the credential side of things, we need data model. I just tried to reuse as much as possible to to keep it as simple as possible for the beginning. So the idea was to to reuse the VC typing system of SDG. VC. We are using basically a structured JSON input right now in the header. I have an example later on that then maps to the message index in BBS. So we can basically do the same kind of JSON construction that s d dot v c is able to do. We just convey the proof differently. It's a bit of a small transformation, basically, that we're doing. We we are defining basically a mechanism where we can say, for these values, the input is a raw scalar, and we are overwriting the default hashing function of BBS to allow us for the subproofs. This might actually be be moved into the BBS line draft, so this would go out of this draft and would be solved in the the core draft, which would be way nicer for me. Remove some part here. And then some problem to figure out is the whole key binding part of it because it is a bit of a special construct. So this is an example from an s t dot v c. This is a JSON body of an s t dot v c example. And the initial proposal would be to basically have a JSON web proof issuer signed header that conveys the structural information like this. This is one of different proposals I've tried out. This is the easiest one, so this is the one I would like to start with. It's basically taking all of the JSON parts, and wherever you have a value, it gives you the index you would find that value in for the BBS message. It's the simplest transformation I was able to come up with. This is, like, implementable in 50 lines of code, and it's simple and robust enough that I believe this this makes a lot of sense as a starting point. That's basically the the general construction. Are there any questions on the constructions, is there interest in such a work? Because I my motivation is we are we are seeing ZKP related stuff pop up everywhere in ITF right now, but everyone is doing a special constructions purely optimized for their use case. And I think I believe we could benefit quite a bit from a more generalized construction and some kind of proof system registry. Any comments, questions?
[00:17:18] Brent Zundel: Brent Sundell. I said this on the list, but I read the draft. I think this is great. I'd love to help make it happen. It makes sense for it to happen here to me. So yeah.
[00:17:34] Frederik Janssen: Frederick Jacobsen, I also read the draft. I think it makes a lot of sense. My one concern is about the subprove agility. So as you mentioned Yep. You might want to remove some at some point. So currently, the draft has specific sub subproves to find in it. Even though they kinda stepped out, it doesn't actually have the algorithms as far as I know. But it might make more sense to remove that and immediately have one that's just the the framework and then one that's, like, the the base set of subproves.
[00:18:02] Christian Paquin: In my first working version, I actually defined the cryptographic subproof for some. Then I removed it again because it was like, this is probably not for Jose. And I agree with you. We should probably remove the specific definitions from this draft, and it needs to happen someplace else. This draft should register the Yunnan registry, though, in my opinion.
[00:18:21] Phillip Hallam-Baker: Philharm Baker. Yes, I like this. I can see a very useful use case for it to allow me to do interesting stuff without with PQC without it being on the critical path, but such that it doesn't do PQC.
[00:18:45] Andrey Popov: I could let you if it's really urgent. It seemed urgent.
[00:18:52] Quinn Dang: I had somebody in front. I didn't want it.
[00:18:53] Philip: Okay. That would delay.
[00:18:55] Andrey Popov: So I'll make it short. I think this is a great work. It's very important, especially having some zero knowledge proof that is more likely to be adopted in the regulated space and and just in general having an alternative to long pillow, having just two paths, I think is a good idea.
[00:19:22] John Bradley: John Bradley, I read the draft in serious wallet. We are working with Christian and prototyping all of this to try and come up with a demo later in the fall of how to do this with both p two fifty six and a Schnorr binding to explore some of the options. I think it would be good for the working group to take this up. And actually having some concrete thing for someone to do with JWP may actually motivate people to move it along.
[00:20:00] Karen O'Donoghue: Okay. Oh, Ori's in the queue. Go ahead, Ori.
[00:20:06] Ori Steele: Alright. Ori Steele. I've I read the draft. I like it. The the one kind of question I have is about the BBS sort of layer. Like, folks mentioned Longfellow. I'm not super familiar with Longfellow. Can you just say, like, a few words about the the front the the modularity of the front part as opposed to the modularity of the back part?
[00:20:26] Christian Paquin: So in principle, the front part works for any proof system that is able to do exactly this committed output. So I haven't looked into it, but it should, for example, also work with laser, which is the post quantum work from IBM for a that is based construction. I think the general construction fits very well, but it would be one of the questions I would like to figure out when when progressing this. Some of the circuit based solutions would be extremely hard because they cannot output a circuit. Others can. So for them, it's like on per per construction basis.
[00:21:00] Lucas: Cool. Thank you.
[00:21:03] Karen O'Donoghue: Okay. So the the queue is empty. We could do I'm not hearing any opposition at this point to adopting it, so we could start a working group. I keep wanting to say working group last call, but not a working
[00:21:21] Deb Cooley: group last call. That
[00:21:23] Christian Paquin: might be fast.
[00:21:25] Karen O'Donoghue: That's because working group last calls are on my mind. A call for adoption. Is there anybody that feels that it's too premature and would like to see another round of edits or comments? Okay. So we'll do a call for adoption on this document.
[00:21:46] Lucas: Thank you.
[00:21:51] Karen O'Donoghue: Alright. So now back to our our adopted documents.
[00:21:57] Sophie Schmieg: I
[00:21:58] Karen O'Donoghue: think I don't know if it's Brian or Philip. It's Philip.
[00:22:01] Philip: Go ahead, Brian. Take it. No. Let's see how this goes. Yeah. It will work probably. There are my slides. I haven't seen these slides. I've prepared them, but Brian was nice enough to actually put some imagery and flare into them. So thank you, Brian. Let's see how that goes. Talking about the HPKE post quantum and post quantum slash traditional hybrid algorithms, and these we're talking about registrations for them, building on top of the soon to be ITF last call passing and third or fourth working group last call passing HPK, who's a document. That's pretty much what it is. Some context for tourists. I don't know. Who's who's the tourist here? The room is pretty big, so there are bound to be a few tourists here. Raise of hand. What has happened since the last IETf? At the last IETf, we had two competing individual or in Internet drafts, none adopted by not adopted by the working group. Since then, the four combined authors of those two documents have gotten together and produced a single document that we, as a working group, have adopted. Before the adoption, we have applied feedback based on all the discussions that happened around those two individual documents. We have split the Jose and Jose parts apart. Does that make sense? Yeah. I think so. So the CoSE document, I believe, passed an adoption call but hasn't been published yet. That's something to happen probably this week. I'm not sure. But the COSE working group is meeting tomorrow. I don't know. So as I said, we have a adopted document combining two previous IDs. We have we have done we've managed to do that back in June. As far as the scope goes, this is a narrow document. We're only aiming to do registrations. We don't wanna define anything new. So we register the ALG values for use with JWE, and we build on top of the other documents defined key management modes. So that's the key encryption mode and so our HPKE key man key management modes. There are two of them. There's the key encryption one and integrated encryption one. We are using the CAMs from HPK PQ, same for the KDF, and we're using NAID from HPK actual. We the one thing that I liked about ten seconds ago is we are defining one new thing, and that is the JWK representation that we need in order to serialize the keys, and we provide vectors for everything. So the current proposal is five cipher suites, five HPK cipher suites split across the, the two, key management modes. So that totals out to be 10 algorithms. Here, they're on the on the slide. We are covering PQ levels three and five with the traditional floor being either one twenty eight or one, one ninety two. All the HPK cipher suites use shake two fifty six as its KDF and AES as its AAD. There is a gap. There is HPK 11 missing, and that is because the COSE draft has HPK 11 using MLChem five twelve, so pure post quantum cipher suite. We're gonna talk about that in a little bit. We chose a e s two fifty six only. Well, originally, we had both a e s two fifty six and ChaCha, but we were asked to remove options from this draft. So that's what we did, and this is what we were left with, five cipher suites, times two, ten algorithms. The COSE alignment and the HPK 11 missing, I don't know why we keep coming back to an alignment when COSE is not using our alt values. They are mainly used for I don't know what they're used for in CoSE. Nevertheless, we left a gap in there so that h so that CoSE can refer to its algorithm as HPK 11, and there's gonna be a gap in our registry. Meh. I don't care. I wanna touch very briefly on the crypto. So that's the native browser API for cryptography. I wanna mention that because Jose being a JSON based standard, it goes hand in hand with what's available in the browsers. So the support for the algorithms for the Cypher suites that we are using are being defined by myself and Daniel in in WICG. We have gotten quite a lot of server side implementations for these algorithms being defined in this extension to the crypt already, but the ones that I wanna talk about are the browsers. So there's an origin trial about to be started for Chrome or Chromium based browsers, so that would be your Chrome, Edge, maybe Opera. I don't know if they take part in origin trials as well. I'm not really sure. And what that gives us already in the browser is the is a pure MLChem seven sixty eight and ten twenty four. It gives us Xwing as a pure hybrid no. Sorry. As a as a hybrid in a single the crypto algorithm so the application doesn't have to do the combining using SHA three and shake itself, which doesn't get us rid of the need for shake because we chose it as a KDF, nevertheless. The message was also that MLChem five twelve will not ship, which is partly also the reason why we are not including it in our in our set. And the further two hybrids, so the ones based on these curves, they're not gonna ship either. So it's just x-ray, which brings me to the KDF that we use. We chose shape two fifty six based purely out of continuity with preexisting word work done by Hannes and Thiru. And for now, we're getting different signals from different browser vendors from different engines. So Chromium gave us a negative signal on including any more algorithms, at least in this origin trial. So that's not it's not saying that they may not happen in the in the future, but for now, there is no work being done on their inclusion. Safari and Firefox, as far as I know, haven't started this implementation, but they have given out a standards position. Firefox doesn't presently have any shake variants in their code base, but might be inclined to take Turboshake instead. Safari, on the other hand, is not opposed to the inclusion of shake two fifty six. I I don't know what to make of it. For now, we're sticking with shake two fifty six. Maybe four months from now, I'll be standing here presenting four different options to to go for. Either we go back to HKDF SHA three eighty four, or we go for TurboShake, or we stick to our guns and just take shake two fifty six and do what you will, either implement it in WebAssembly or pure JavaScript, whatever is available to you. This I realize this is nothing about server side implementations where where all of this is widely available already. If you're interested in seeing what your browser supports today, there is a URL on the slide that you can go to which uses only what is natively available in your browser to see which KDF, which AAD, and which CAM is available to you. Have extended the security considerations. Do I need to talk about it? We've included a lot of the rationale from and draft in in this shared document. We discuss why we omit MLKM five twelve, and we have a prose that describes, the post quantum security strength of each cipher suite. A very nice inclusion that is, that Thiro has brought up is the inclusion of a sentence saying that if you use a general JWE syntax, all your recipients must use now this is a slight change. It originally said algorithms from this document, which are all post quantum sort of resistant, But I actually changed that up to say quantum resistant key management modes because you should be able to use algorithms from other future documents. And I don't believe there's anything against using a general JWE where one recipient is using one of these new algorithms and then maybe AES key wrapping. It's strange, but can happen. We have all of most of the draft content is being automated. We've already had that the last time. What I wanna point out is that changing the algorithm set for us is mechanically really cheap, and choosing the algorithm set is up for discussion is up to a working group decision. So if there are changes, we can make them really fast. If they're not, we probably will take that as a sign of acceptance of what is in there today. Anyway, what we need today are reviews. We would like some confirmation of those five Cypher speeds. Hannes validated the examples as far as I remember. I'm not sure. Somebody validated the Coza ones that are generated using the same sort of implementation, but somebody checked them out. Ilari might have.
[00:32:56] Deb Cooley: Maybe Ilari.
[00:32:57] Philip: Maybe Ilari. Yeah. We would like you to review the document and, hopefully, unless there is anything more concrete with with the KDFs, we could start converging towards a working group last call by the next ITF meeting. I fully expect to be there in four months saying nothing changed, but we'll see. Well, four months from now, the origin trial of Chromium is gonna be ongoing, and, that's gonna give us some data. That is all I have.
[00:33:29] Karen O'Donoghue: Alright. First of all, thank the authors for all the work that was done since the last meeting. This is a lot of progress. And,
[00:33:43] Tirumaleswar Reddy: Hey. Thanks, Philip. I have one request to the working group. Right? I mean, TLS in the very late stage decided to pick one of the cipher suits as recommended, right, much later when it went to the r c d q. I think x two five five one nine and ML chem six seven sixty eight should probably become recommended plus or required. I mean, if that's an option that we should consider, I mean, that makes the life a lot easier.
[00:34:08] Philip: So you you're talking about the IANA registry Yeah.
[00:34:11] Lucas: Table Yeah.
[00:34:12] Philip: Yeah. Position. I was see how all this some thought yesterday
[00:34:16] Brent Zundel: as I
[00:34:17] Philip: was falling asleep realizing that we have them all as optional. Right. So I I think at some point, we're gonna have to do a document that updates the old entries anyway. Sure. But, yeah, we can go forward with one of ours being as recommended and the other ones optional. Yes.
[00:34:35] Lucas: That would
[00:34:35] Philip: be great. Whether whether we're gonna go for one recommended being the hybrid Xwing based one or also one of the pure ones, again, up to the working group.
[00:34:44] Tirumaleswar Reddy: Right. At least TLS has not picked any pure one as recommended, but at least to to drive parallel, basically. But yeah.
[00:35:03] Quinn Dang: I'm Quinn Dang at Nest. Our general security recommendation is use the strongest option that has okay performance to you performance acceptable to you, like level five. And if its performance is not acceptable to you, then consider use level three. And if even level three does not work for you, then go to level one. That means use MLChem five twelve. We are confident in its security.
[00:35:41] Karen O'Donoghue: The
[00:35:44] Philip: hash it
[00:35:48] Quinn Dang: on security, we are comfortable with both SHA two and SHA three.
[00:35:56] Lucas: Yeah.
[00:36:00] Philip: Thank you. Should I take that as a request to include MLChem five twelve pure? Yeah. So adding that back in?
[00:36:11] Deb Cooley: Do you need it? Yes. No. Do you need it?
[00:36:14] Christian Paquin: No. I don't.
[00:36:15] Deb Cooley: Then you don't need it?
[00:36:17] Philip: List says it's okay, but I don't need it. Does anybody else need it?
[00:36:22] Sophie Schmieg: So, fish meat, Google may say it's okay, and I do believe that at the moment, nobody can break it. I would not recommend people using MLChem five twelve. And if we don't have a clear reason why we need need it, I wouldn't put it in there if there's no use case.
[00:36:41] Philip: So we've removed it from the Jose part. It remains to be present in the COSE bit for its, you know, less footprint and more performance. I don't know. So COSE is targeting more constrained devices than Jose does, so it remains there. But we haven't had a signal for its inclusion in Jose.
[00:37:06] Karen O'Donoghue: Go ahead. Brian, you're up.
[00:37:09] Philip: Thanks for don't ask about ChaCha.
[00:37:12] Brian Campbell: I've I've three questions points. It's super interesting watching you present content you prepared that I adjusted and then hadn't done together. But it wasn't until I saw you go through it that I realized, I think, what you said that there might really be implications to the timing relative to the KDFs we include. Is there a compelling reason to use shake other than it's newer
[00:37:44] Philip: The versus availability. Given the size given the Cypher suites today, you have no reason to have SHA two in your code base. You likely already do in the library anyway. Right? But these all use internally the the hybrids use SHA three for its combiner. You have shake two fifty six used for key derivation sorry, For not like is it key derivation? If you have an IKM to derive the the key pair out of out of a nonseed. Let's put it that way. Because then you still have the seed. So it's to per key derivation. Per keyed. Yeah. Thank you.
[00:38:29] Brian Campbell: So is is that not the problem it sounded like then in terms of web browser support for those because they're implementing it internally and not exposing it?
[00:38:39] Philip: Yeah. Okay. There are various positions.
[00:38:44] Brian Campbell: But if you if you look at it from the perspective of a user of a library implementing these things, there's not really a problem of support. No. Okay. Thank you for the clarification.
[00:38:57] Philip: Yeah. You can you can get shake 256 in a browser even without the native API supporting it. It's not that hard. It's just an inconvenience. And I'm the maintainer of the library that everybody uses, so that inconvenience falls upon me. But
[00:39:16] Brian Campbell: in terms of the actual HPKE implementation, is it problematic there? No. Okay. Alright. So I read too much into that. Let's go to working group last call, the next one. Obviously, not exactly. Two other quick points. Do you find it odd that we're aligning with a naming scheme in CoSE that doesn't need to exist and doesn't make any sense in that context.
[00:39:40] Philip: I find it weird that CoSE has a naming suite that we'd have. Right? We're not aligning with them, at at least not anymore. We leave a gap in there so that if there raises if there becomes a a need for five twelve, then it falls right in place. But, you you know very well the original motivation was to keep those two aligned.
[00:40:03] Brian Campbell: Yeah. I I was asking more about the short names for something that doesn't appear in anywhere but a registry.
[00:40:11] Philip: We can pick that up at the COSE working group meeting tomorrow.
[00:40:14] Brian Campbell: I look forward to
[00:40:15] Philip: it. Yeah.
[00:40:15] Brian Campbell: Okay. Now on to ChaCha.
[00:40:19] Ritu: It Thank you
[00:40:20] Philip: very much for coming.
[00:40:23] Brian Campbell: A a serious question, though. There was a a big push. I I think in the last meeting, I've sort of lost track to to trim down the algorithm set here. As a result of that, we came up with this list. Obviously, there's some contention one way or this is right listed or not list, but part of that included the complete removal of the ChaCha AEADs. At the
[00:40:43] Philip: same which at the same time meant splitting the two documents so that COSE can keep ChaCha
[00:40:49] Karen O'Donoghue: Mhmm.
[00:40:50] Philip: And in the end, not actually keeping it there, also removing it.
[00:40:54] Brian Campbell: Oh, okay. I'm more looking for some coherency from the working group itself, and I I maintain that it's very, very odd for the base HPKE document to use the ChaCha EIDs while this document does not. And I
[00:41:14] Philip: do want me to add the chat transcript?
[00:41:17] Brian Campbell: I I would like us to have a coherent, defensible, sort of overarching viewpoint on it rather than sort of bit what
[00:41:26] Philip: Watch out.
[00:41:27] Brian Campbell: Bitmeal. Behind you. Inconsistency. And with that, I defer to our illustrious AD.
[00:41:38] Deb Cooley: I can't remember what I was gonna say. Really? Alright. Hold on. Got it. So I'm Deb Cooley. I'm your AAD. So you're yeah. That's right. AAD. No. Why?
[00:41:53] Karen O'Donoghue: AD. AD.
[00:41:57] Deb Cooley: So okay. So back to TLS for a minute. TLS did in fact decide to label MLChem seven sixty eight x two five five one nine as recommended. Yes. So if you followed along in those footsteps, I think it would be
[00:42:13] Philip: Make it recommended.
[00:42:14] Deb Cooley: It would not be terrible. Mhmm. At the same time, with the pure MLChem working group last call, TLS decided to add some notes to security considerations about the use of the randomizer sort of at what I the way I phrase it is if you're using MLChem inside of the NIST bubble, you get some advantages from selection of random sources. And then if you use it outside of the NIST bubble, maybe you need to make sure that you maintain those, requirements outside of the bubble. It's all of these are outlined in, working group last call consensus statement. There are they actually put it in two places. Sophie Sophie disagrees, and I and I agree with Sophie and that, like, we shouldn't have to tell people to, like, not make vulnerable code. But, sometimes sometimes sometimes you have to say these things. So that's one note.
[00:43:15] Philip: Can I respond?
[00:43:16] Deb Cooley: Yes. You may.
[00:43:17] Philip: Thank you. If there are if No. If come on. We can do it. If there are additions to be made, I believe they will be made in the HPK EPQ spec that we depend on. That's to probably be copied every single document that HPK Yeah. Yeah. Depends on. Right.
[00:43:38] Deb Cooley: Right. Could so you will refer to HPK We
[00:43:42] Karen O'Donoghue: we refer to security considerations
[00:43:44] Philip: already say
[00:43:45] Lucas: This is
[00:43:45] Philip: HPK and HPKPQ considerations apply to this document.
[00:43:48] Deb Cooley: This is this is absolutely true. So maybe it doesn't matter.
[00:43:52] Philip: Maybe it doesn't for us.
[00:43:53] Deb Cooley: But just keep it in mind. So we need to watch for it.
[00:43:55] Philip: For HPKPQ.
[00:43:57] Deb Cooley: Yeah. If they get their acting gear and they do it before I leave, we'll we'll talk, or before I'm recalled. Either way. So that's a joke. That's a joke. Sort of funny too. Anyway, there was something else I was gonna say. Damn it. Cha cha. Yes. So here's the here's the thing. And I understand the drive for consistency across the drafts and I do tend to agree. It is something that I would like as well. On the other hand, what I expect to see in as time moves on is that the Jose h p q e draft basically falls away because we will have a quantum computer, and you will not be using just the general traditional blah blah blah blah blah. So the fact that you've got ChaChaPoly specified there will not be an will also fall away. Right? So if it's not the plan of Jose to endorse the use of ChaChaPoly within Jose, then eventually you'll get to the point where this will be the driving standard and the HPKE draft will not be. So you will be once again back to a consistent state. If Jose decides that they want to allow ChaCha Poly as one as an a as an alternate AEAD, perhaps so that you have some sort of fallback in case there's a problem. I'm not saying I mean, AES is now 26 years old.
[00:45:33] Quinn Dang: But it's in '91.
[00:45:35] Deb Cooley: '91? Not '91. It was it was approved in 2000. Let's let's let's go there. And there's not a problem with it, but it is I mean, eventually, algorithms get long in the tooth. It's not like ChaCha's that much younger either, but you may want an alternative. I'm not saying that you do or you don't, But, where was I going with this? If you don't do it sorry. It's only Tuesday. If you don't do it, then you will eventually be consistent again. Right? Sure.
[00:46:09] Brian Campbell: I think I think that vastly underestimates the longevity of registry entries and their impact on the broader community.
[00:46:20] Deb Cooley: So so registry entries can be changed. Right? You can go back and deprecate the use of the HPKE straight up registries, which you will do when they become vulnerable. Right? So you will go back and you'll write a draft you'll write a draft that says, we would deprecate, you know, blah blah blah blah blah blah. Right? And that you use these other things instead.
[00:46:40] Brian Campbell: This is true, but the draft we started out, this conversation that only got two working group last call reviews that we're trying to do to push through an algorithm that is literally the null no signature algorithm is is having a hard time just pushing that forward. So there there again, there are, like I
[00:46:59] Deb Cooley: I can't help you. So This is not my fault.
[00:47:05] Brian Campbell: No. No. It's not your fault, but we don't need to endorse moving further into that kind of position. Yeah.
[00:47:15] Deb Cooley: Though I think I think you're I think you're okay. I think it's okay, honestly. It it's not like ChaChaPoly is a bad algorithm. It's just you haven't defined it. So it's not like it's vulnerable. If you were gonna do triple DES, I would say, no. Don't do that. But and then and I and I draw the line at I I don't unless you have a reason performance reason to use MLChem five twelve, I recommend against that as well. So if you don't have a performance reason to do MLChem five twelve, then there's no reason to put it in. It's the same situation as ChaChaPoly. If you have decided not to register ChaChaPoly, then don't put it in. That's it.
[00:48:01] Karen O'Donoghue: Horry? Are you up? Since you don't need those. I feel if you don't. Yeah. Alright.
[00:48:08] Lucas: We're still
[00:48:09] Ori Steele: to the point of, like, recommended or not, like, if that becomes, like, a big discussion around this, I would say, like, let's go back to the registry and fix, like, all of this registry stuff in one separate place so we can get these algorithms, like, up. So my only, you know, pleading is, like, there's there's a lot of, you know, details and optionality that we can discuss. But if our goal is to get PQ algorithms deployed, and we know that the registry needs some updating to address PQ or lack of PQ, like, we can we can put that conversation in a separate document where we can move it as quickly as possible while also getting these algorithms up as soon as possible. That would be my my hope. Anyway, thanks.
[00:48:54] Karen O'Donoghue: Alright. Thank you, Philip.
[00:48:56] Philip: Thank you.
[00:48:58] Karen O'Donoghue: So for the way forward for this document, we will ask for another round of comments on the mailing list, give a reasonable time frame, and then based on that, do a working group last call maybe, you know, mid September. So any questions or comments? Nope. Okay. Next. Which where are we?
[00:49:27] Co-Chair: It was this one, but it doesn't need slides.
[00:49:30] Karen O'Donoghue: Oh, yeah. The one that doesn't have slides.
[00:49:34] Quinn Dang: It's Retro, I think.
[00:49:35] Karen O'Donoghue: Retro, are you here? Oh, there he comes. So I just wanted we just wanted to close the loop on this, and he's going to verify for this group what's happening with that document.
[00:49:52] Ritu: Yeah. Thanks. Yeah. I think so this document, I think the PQ chems, JOSE document, which is the pure PQ without using HPK. I think it was sort of unanimously discussed in the working group that Jose does not want to go that way. So we will be sort of removing the Jose aspects and moving it to the COSE working group because in COSE, of course, there's a requirement from the lake drafts as well for e d hock based work. And so, essentially, the conclusion is that we'll present this draft on Thursday to. And, yeah, we sort of like, right now, it's a state. It's sort of specified towards COSI. So, yeah, that's why we don't have a slide here, unfortunately. Yeah.
[00:50:42] Karen O'Donoghue: Oh, yeah. No. No. No. That's fine. I just wanted to be sure that the working group was paying attention to the fact that provided COSE decides to accept this, this document is moving from Jose to COSE, and the Jose pieces are coming out. Alright?
[00:50:57] Ritu: Thank you.
[00:50:58] Karen O'Donoghue: Thank you very much. Composite signatures. There he is. Oh, yeah. The slides.
[00:51:15] Philip: Thank you.
[00:51:16] Karen O'Donoghue: So hello.
[00:51:18] Lucas: This talk is is about the post con term traditional hybrid composite signatures working group document. It was already presented several times during IETF meetings. It was adopted by the working group in January this year, and it has been updated earlier this month. So to begin with, just a quick reminder of what this draft is about. So it defines post quantum traditional composite signature algorithms for both Jose and Jose, more specifically combination of MLDSA and the classical algorithms ECDSA and EDDSA. It also describes how to handle the composite key key generation, signing, and verification with alignment in alignment with the construction described in the LAMPS composite draft, which is now within ISG. In the draft, we used the algorithm key per key type and the pseudo representation for the MLDSA private kines in alignment with the COSE MLDSA RFC. And we have a section about security considerations, and we provide test vectors for all combinations in the draft. And since the the previous meeting, we we had some updates to this document. So we removed point compression for EC DSA because it wasn't compatible with the serialization subroutines we have in the draft. We also removed ASN one. I have a draft specifically to discuss about it. We had an unnecessary base 64 u r URL encoding step that we removed making the test vectors correct. And we updated the COSI algorithm values because they were they got already allocated. And, also, I wanted to briefly mention the post quantum interoperability hackathon project that happened this weekend, but the project has been going on for many years now. So the objective was to test interoperability between multiple algorithm implementation. Originally, it was for x five zero nine certificates, but this weekend, artifacts for Jose and Jose were added, in particular, for the composite algorithms defined in the draft. So feel free to to participate by adding your artifacts in the GitHub repository if you have the possibility. But the main thing I wanted to discuss today is how to encode the ECDSA component in our composite keys and signatures. Because in the LAMPS composite document, it is requested to use ASN.1 DER encoding for ECTS eight keys and signatures. While in the current version of our Jose document, and this is just a starting point and not a settled decision, We use a raw fixed length encoding for this eCDSA component. And though so currently, there is no ASN one DRR encoding in the draft. So this leaves us with two paths forward that you can see at the bottom of the slide. So there is a first option, which is to keep the document as it is without any ASN one Doctor encoding. So this is more natural for Jose and Cozy, as traditionally, they don't use ASN one at all. But we end up with two different encoding for the same composite algorithm, one encoding for Jose and Cozy and another one for x five zero nine and CMS, which is defined in LEMS. And so a second option would be to align with LEMS by reintroducing a s n one, which would give us a single portable composite format. But that implies that we add extra ASN one. However, it is not necessary for implementers to implement a full ASN one parser, and we could imagine providing the extra the needed the required extra tags and length in the in the draft to make it easier for implementer. And so I think both sides have good arguments. If we had the ESN one, then there is, yes, a little bit more complexity. But we also received a message on the mailing list yesterday saying that we have some already OS based cryptographic library that already implemented the LAMPS DER encoding. And so there is an incompatibility between the current encoding in the document and implementation that have already shipped. And so we are we are open to to any option, and we we will we will update the track according to what the working group thinks is the best solution. So if you have any opinion regarding this issue, you can speak now or send a message on the mailing list.
[00:56:36] Philip: Hi, Lucas. This is Philip. I did an implementation of this. It was really simple without ASN one. That being said, I don't think it would be way too much work to to make it go in the other direction.
[00:56:52] Deb Cooley: Mhmm.
[00:56:54] Philip: Either way you look at it, either way you skin the thing, you're gonna make somebody unhappy. I already have an implementation that doesn't use it, and it was really easy. It's gonna be annoying for me to edit in. There's some other open source out there that relies on open source or on crypto libraries that have it the other way. And if we keep it the way it is, you're gonna annoy them. So either way, it's a coin toss. As far my my implementer's feedback, assist me. I I don't care.
[00:57:26] Lucas: Thank you.
[00:57:29] Andrey Popov: Hi, Andrei Popov, Microsoft. So we already have an implementation of the libraries of the lamps serialization format. The nice thing about this, it's not just question format. Right? Like, to me, a composite is an atomic entity, and we want to discourage people from taking it apart and trying to re encode or to redo something because with that comes the risk that people will start, for example, coming up with different users for the component keys and so on. So I would rather keep one format, and I would rather just stick with whatever LAMP's defined. Not that I prefer ASN one. It's just like it's an already defined format, and I would rather have one than two fewer implementation bugs.
[00:58:08] Deb Cooley: Can I quickly count that? Sorry. Yes.
[00:58:11] Co-Chair: Yeah. Go ahead.
[00:58:12] Deb Cooley: At the mic.
[00:58:17] Philip: I get that we don't wanna have encourage people to decompose ASM one, but already those implementations based on the crypto, for example, are gonna have to do that. There is no way to verify a signature that is that is inside an ASN one container in the crypto. So I'd either way, as I said, somebody's gonna be unhappy.
[00:58:44] Co-Chair: No for me. I guess I just wanted to point out that this working group recently published RFC ninety nine sixty four, which is the pure MLDSA one, and that doesn't use ASN one DER encoding. I think that's quite a good argument to have consistency over what comes out of this group. So that that would be my preference is to is to not do the DER encoding.
[00:59:12] Karen O'Donoghue: You're in the queue.
[00:59:18] John Bradley: So I promised Akshay from this is John Bradley. I promised Akshay from Microsoft I would ask a question for him. They have implemented or Microsoft in some portion has implemented, MLTSA 65 plus p three eighty four, and he would like that in registered in this draft. So we should either, explain why we think that's a bad idea. Now I'm I'm sort of hybrid skeptical myself, so I think they're all a bad idea to some extent. But why specifically that combination? We're not registering that combination because from a a sort of a high level, that seems like an obvious one. But there may well be very good reasons why that doesn't get you what you think it's going to get you. That and I have seen the I understand that we're doing taking the same approach as LAMPs, but I have seen criticisms of the way that we're combining the the two things. I understand that this allows us to do things in parallel that you wouldn't otherwise be able to do, but do we have, a rebuttal to the potential reduction in security that other com ways of combining this might might provide us?
[01:00:55] Lucas: Good question. There were long discussions in the LAMPS working group regarding the combination and the the right parameters. So I think if we begin if we begin to discuss about this I mean, I think the the discussions already happened in the LAMPS working group regarding the security and the best parameters. And for the list of registered Write
[01:01:14] John Bradley: it down.
[01:01:15] Lucas: Yes. Okay. And we wanted to keep the list shorter. I think most people want it.
[01:01:22] Brent Zundel: So Yeah. Yeah. I can just I can speak on that. I'm on the thing next. Know? It's John Gray from Entrust and composite author in Lamps. And, yes, we had many debates about how many combinations and all that stuff, and we tried to reduce it as much as we could. And every time we tried to, then someone came along and said they needed this combination or they needed that combination. And that's why we ended up with 18 combinations. So I think we have six now because we think those are good ones. Obviously, if people need other ones, they could be added. We prefer not to add them because you wanna keep things as simple as possible. That's always a good thing. Right? So that I I guess that would be the main reason. But, I mean, you know, if you have big organizations that come along and say, we wanna use this one and we're planning to use it, I mean, why can't they use it? Right? So that's why they get added. In regards to your question, versus one and two, I know I've talked with you about this, but, yeah, I do prefer number two. We have at Entrust two implementations of the composites. I know OpenSSL is doing one as well, so they're doing it based on the LAMP's draft. I just think it's not like someone else said. It's not that hard to do the little it's just a sequence with the r and s values. And you just have the tag value and then just figure out the length. It's very easy to do that extra bit. So you don't have to have an a s m one parser. It's just very simple. Right? So just let's let's not have two key formats just because, you know, there'll be some edge case somewhere where an implementation is using it, and then it'll it won't interoperate or something will happen, and it'll be because of this one little thing. Right? So let's just keep it the same and just keep things as simple as possible. Thanks.
[01:02:52] Karen O'Donoghue: Philip's next.
[01:02:58] Phillip Hallam-Baker: Yeah. I might be changing my mind.
[01:03:00] Mike Jones: Yeah. On the d d e
[01:03:02] Phillip Hallam-Baker: r thing, you're not really doing DER here. You're doing the smallest possible subset of it. And in particular, you're not doing the one thing that makes DER absolutely horrible, which is variable length encoding nested inside variable length encoding. That was the biggest blunder that made ASN one DER such a pain to do. You don't need to do it for doing the key formats. So, you know, I would tend towards saying DER sim you know, I've implemented both. The the problem is if you're going to do this, you've got to do all your public key things the same way. And it's not just a question about this particular set, it's what we do after. And if you if you move from how it is defined in the source standard, there are all sorts of tricky things to do with does it matter whether it is signed or not. And sometimes it does and sometimes it doesn't. And
[01:04:11] Lucas: Thank you.
[01:04:13] Karen O'Donoghue: Mike.
[01:04:18] Mike Jones: Hi, Lucas. Mike Jones. When we started on this whole Jose journey, I mean, one of the goals was to not have to implement or use any ASN dot one or certificates unless you chose to. And the JWK format, yeah, it defined alternate representations for keys that were not x five zero nine certificates or parts thereof. And it's worked out okay, I think, that the structures have fields which are the component parts of the keys. So, I mean, this is almost philosophy of what we're trying to achieve. But to the extent that it doesn't cause interoperability harms, I think we would default to not using any ASN dot one in this particular case either.
[01:05:32] Karen O'Donoghue: Thanks. Sophie.
[01:05:37] Sophie Schmieg: Go ahead, Sophie. I think that this has been one of the big mistakes in JDUK. Technically speaking, if you look at things like MLChem, MLChem also consists of multiple things that you could put into, like, in into the JSON format. Doing that would be a horrible mistake, but you could, like, you could have, like, a a list of of of integers, which is, like, what's technically in an MLKM key. But, yeah, please don't do that. Don't think of it as an ASN dot one encoded something. Think of it as an opaque blob. Like, I do think that trying to decode what's in this key format is a very like, is is already a fool's game. Like, I've been guilty of the same thing. It's a bad idea. I've regretted my life choices whenever I've done that. Deal with the keys as a as an opaque blob. And, like, yes, it's technically asn.one, but you don't care about that. You pass it off to some crypto library that deals with lam sinks. You don't actually do it yourself, at least ideally. So that that would be my preference to just keep it the same as Lam's does and its maximum compatibility. You can use the same crypto libraries. And, yes, it's asn.one, but, like, pretend you don't know that.
[01:07:11] Lucas: Mhmm. And, yes, indeed, if we choose the second option, I think we we can provide the necessary needed information in the draft to make it opaque and without any knowledge of ASN one necessary.
[01:07:27] Karen O'Donoghue: Go ahead, Mike.
[01:07:28] Mike Ellsworth: Mike Ellsworth. I'm gonna say mostly the same thing Sophie did, which is, yeah, the option two, your there will be some Jose libraries that are not code shared with x one nine libraries, but I think a lot of crypto libraries are just crypto libraries. And so to me, when I read option two, that says library must have a DARE to to JSON transcoder is what that says. Not won't have DARE, but needs to be able to internally translate from a library that uses DARE to a protocol that doesn't. And I get that you've, like, solved that for for ECDSA and and RSA in general in this protocol. But, yeah, to me, it's it's you're just moving where the encoder needs to be, not removing it. Thanks.
[01:08:14] Brian Campbell: I I kinda don't care either, but wanna reiterate that it really depends on what's already provided, and you're moving it one way or the other. And it you're gonna you're gonna piss somebody off one way or the other. So, like, all these arguments that come up and say, well, mine does it this way, so everyone should do it this way, are exactly falling into that trap. Like, let's not do that at least. Let's at least be honest about the decision we're making.
[01:08:42] Karen O'Donoghue: Alright. I think you want a discussion, so we've we've gotten that.
[01:08:47] Lucas: Yep. Thank you, everyone. Should we organize a poll maybe? Because it's
[01:08:55] Karen O'Donoghue: Do you wanna do a poll? Do you wanna do a poll here, or would you rather do it on the mailing list? We can do we'll do one here. Okay. So we have we always do this better when we do the questions in advance, but, so we have a proposed question. Don't it has to be okay. That's good.
[01:09:38] Sophie Schmieg: That's that's
[01:09:38] Yuzuru Someya: just You have to say one is yes. One
[01:09:40] Andrey Popov: is Yeah.
[01:09:40] Co-Chair: So we're we're gonna say
[01:09:41] Karen O'Donoghue: Right. So so the question we're proposing is I prefer aligning with LAMP's composite document and using ASN.1 DER. And so the yes will be the first
[01:09:55] Lucas: The second one.
[01:09:56] Deb Cooley: The second
[01:09:58] Co-Chair: Sorry. I prefer aligning with lamps. I prefer aligning with lamps is
[01:10:01] Karen O'Donoghue: is the last one. It's the first one. The the the left. Just aligning with lamps say I and get the rest of it out
[01:10:08] John Bradley: of there.
[01:10:10] Deb Cooley: Yeah.
[01:10:12] Karen O'Donoghue: Alright. So yes is lamps. No is the other one. Excuse me?
[01:10:38] Co-Chair: So prefer aligning with lamps is the option on the left of the slide.
[01:10:44] Lucas: And it's option two.
[01:10:48] Philip: Sorry.
[01:10:53] Co-Chair: Yeah, the order on the slide is left box
[01:10:57] Ritu: rather than number one and number two. The
[01:11:02] Philip: screen's left.
[01:11:06] Karen O'Donoghue: Alright. Okay. Don't stop this. So with lamps
[01:11:14] Quinn Dang: question was serious because lamps but
[01:11:17] Karen O'Donoghue: with lamps, so that part's not too hard. The lamps composite document or the Jose document? Yes is Jose. Is lamps.
[01:11:26] Co-Chair: That's true. That is yes. I
[01:11:28] Mike Ellsworth: agree with yes.
[01:11:29] Quinn Dang: Open here. Just say one yes or go. That's yes. Okay.
[01:11:33] Mike Ellsworth: Guess is your family isn't about what?
[01:11:37] Karen O'Donoghue: That's that's and this is why I don't like doing questions on the fly. So how's our poll going?
[01:11:51] Philip: It's kinda stabilized. Yeah.
[01:11:53] Karen O'Donoghue: Okay.
[01:11:54] Co-Chair: Preference for preference for yes. Alright.
[01:11:58] Karen O'Donoghue: So we have a a preference for yes, but when you balance out the no and no opinion
[01:12:08] Philip: we'll get on the list. Alright.
[01:12:11] Karen O'Donoghue: So we will follow-up on the mailing list, but, you got your feedback for here.
[01:12:16] Lucas: Okay. So, yes, let's so we keep the discussion on the mailing list, or should I update it
[01:12:23] Karen O'Donoghue: following the No. No. I want you to I want you to ask the question on the mailing list. You do it. Okay?
[01:12:28] Lucas: Okay. Perfect.
[01:12:29] Karen O'Donoghue: Yeah. Yes.
[01:12:32] Lucas: So, yes, I will I will yes. Let's continue the discussion on the mailing list, and, hopefully, after we find a good option, we can proceed to a working with SaaS call later.
[01:12:45] Karen O'Donoghue: Okay. Thank you.
[01:12:48] Co-Chair: Okay.
[01:12:52] Karen O'Donoghue: Mike? Oh, yeah.
[01:13:16] Mike Jones: Hello. I'm Mike Jones. This is work that I've been doing with David Waite for a while, and in fact was the original impetus for re chartering this working group sometime before COVID. So what have we done with the JSON web proofs drafts since we met in Shenzhen? All we've really done are reading it, making editorial corrections, making it more correct and easier to read. In some cases, we had already automated the build processes so all the cryptography happens in a repeatable way and not subject to human cut and paste errors. So what comes next? Those of you in the room who've been following along at home already know this. But reality is we have a normative dependence on the CFRG BBS algorithms for some of the core functionality that we expect to be used in the draft. And those are not moving very quickly. Without getting into speculation or conjecture about reasons why, my request would be for those of you involved in the CFRG work or would like to be involved in it, to the extent that you can see those drafts progress more quickly, that would be helpful to this working group and some of the goals that we've stated. It would be helpful to some of the things that Christian talked about. And these slides were written before we reordered the agenda. But by all means, do participate in the discussion and issues raised by Christian's draft as well. So part of the back story is we do have the BBS extension drafts and modular BBS. So that we do have an infrastructure to start experimenting with blind signatures and per verifiable linkability. And we have Christian's draft. The CFRG extensions require verifiers support for all the extensions in the issued message. And so just finishing the core BBS draft, which has been stable for something over a year, doesn't complete our journey with respect to JWP. And I know, for instance, ML has implementations. Others can speak to that as well. DW has an independent implementation. There is one open question which was opened the last time. Which is how do we want to represent a portion of a claim as a payload? So the classic example is maybe representing your country out of an address or the zip code out of an address. And there have been a few takes on how to do that. That's not a settled question. If you have thoughts on how we should be doing that, by all means, participate in the issue. And with that, that's all we have to talk about today, unless there's things you would like to tell us that you would like to have happen with the drafts. I don't know. Emil, John, not chair hat on, do you have any comments?
[01:17:59] John Bradley: Not that I prepared. When has that ever stopped you? There is that of it. I I I certainly, you know, my hat as a a a wallet curious person who has an implementation. You know, we are working with both Google around Longfellow and with various German entities around BBS. Both have pluses and minuses. You know, we were sort of hoping that, JWP would be kind of a common container format that we could do. There's problems with Longfellow around that, though I keep advocating that perhaps Longfellow, which is circuit based proofs, could be improved if their container format was more favorable than, MDoc. It you know, progressing this to the point where we can actually start using zero knowledge proofs as presentations in verifiable credentials would be a beneficial thing for the world where we're you know, there's, child protection, age verification, things that, are keen interest by various governments around the world, having, being able to do pseudonyms, which is, part of the work that we're doing, to show at GDC with with Google, coming up in September. You know, the these are the things that zero knowledge proofs give us that the that traditional credentials don't. And, if we don't have a standardized format for doing this, you know, we'll never actually get to the finish line with having interoperable implementations that that people can actually do.
[01:20:11] Karen O'Donoghue: All right. Are there any other questions or comments? Oh, there you go, Hannes.
[01:20:17] Brent Zundel: Hi, Hannes. I was wondering whether you, as chairs, have spoken with CFRG to expedite the processing of the BBS document. Because it seems like regardless, like, we had this presentation earlier from Christian, and no matter what, there seems to be that seems to be the blocking factor, ultimately. And so, like, how do you plan to proceed on that?
[01:20:42] Karen O'Donoghue: We have not spoken to the CFRG I I have not chairs.
[01:20:46] John Bradley: Recently. Not as chairs.
[01:20:48] Karen O'Donoghue: Not as chairs. Deb, did you have something you wanted to say on this?
[01:20:54] Deb Cooley: So I have talk I have this is Deb, and I'm going do this if I can stand it. I have talked to them in the past about that. I've not talked to them recently, but I can. Like, normally, talk to the CFRG chairs during the week, but, I have not done that yet. So Or John Bradley can do it.
[01:21:13] John Bradley: I've I've yes. I've I've been out of action recently, but, part of previous discussions with c with the CFRG chairs was to have a more dedicated focus on some of the zero knowledge stuff, and hopefully, we we will have more conversations.
[01:21:31] Deb Cooley: And some of that's in already adopted too. Right? But the BBS stuff is I think you have to sort of keep your the pressure on
[01:21:38] John Bradley: the Right.
[01:21:39] Deb Cooley: To keep it on the top.
[01:21:41] John Bradley: Right. There's BBS, BLS, BLS curves and I mean, there's a whole whole stack of things that need to be completed in CFRG for
[01:21:51] Lucas: for For every
[01:21:52] Christian Paquin: some
[01:21:52] Phillip Hallam-Baker: of this and
[01:21:53] Karen O'Donoghue: For every
[01:21:55] Co-Chair: So I think there was active development at least on GitHub of the BBS document in in June. So it it hasn't been forgotten. But, yeah, maybe we can have a conversation with CFRG.
[01:22:05] Deb Cooley: Some of it's not necessarily the chairs of CFRG
[01:22:08] Lucas: Right.
[01:22:08] Deb Cooley: To keep your thumbs on. It's actual authors of the BBS spec pushing to have CFRG actually progress it. Yeah.
[01:22:16] John Bradley: Unfortunately, BBS has been around the BBS drafts have been around long enough that some of the authors have had change of life issues and things. So they'll so trying to keep their focus over this amount of time has been a challenge.
[01:22:36] Mike Jones: Okay. With that, that's what I had to say. Thank you for your attention.
[01:22:43] Karen O'Donoghue: Thank you. I I just wanna point out what Ori says in the chat about any offers to help would also be great. I think it helps. So if if we're concerned about the progress, maybe we could help move it along over there. With that, we come to our last agenda item. Oh,
[01:23:22] Yuzuru Someya: Hello. I'm. This is my first IETF, and this is my first draft. Today, I talk about the long term validation for JSON web signatures. I'm also also of this draft, and I'm ISO profile project leader. Is the XML long term validation for XML signatures And also for editor, so parties profile. Parties profile is a long term validation for PDF signatures. Okay. What is the LTB JWS? So at first, I have to say about the maybe different use case. So about the on original JWS because my plan is the use case is a PKI based document signing, not Internet. So we have this is old under legacy. Maybe certificate is RFC five to 80. And very important technique technology is the timestamp, RFC three one six one. And these long term validation means offline validations. Sometimes, so PKI world needs offline validations, not Internet. So this extension of the database is two key features. Why is the archiving documents? This means using the recursive archive timestamp. Did you all extend the validation period beyond the certificate expiration? And another one is the renewal of algorithm. This is mainly very important because PQC, after PQC, so update document signature timestamp. So up up to that to the. So key feature too is the trusted time. Many times our signature is very important. It's assigning time. So trusted time is very important. So so these two feature is most big. Another feature is the optional hash list for external references in payloads in the payload. This means many documents have the outside the JWS. So this hash list is external reference to commission, so by hash values. And this extension or extension is a common LTV extension container in the protect header and protect header and the payload. Okay. Database LTV JWS level is four. Yeah. Four. SigB is a signature base. This is almost a JWS. A SigT is a signature timestamp. This is a trusted time out to JWS. So next level is a SigLTV, long term validations. This is a this level is offline validation because the embedded or validation data into JWS, general extensions. Last one is the SigLTA, long term archive timestamp. This is protected new algorithm and long term protection. Yes. So this is a structure of this. Do you
[01:27:24] Karen O'Donoghue: do you wanna do questions at the end or four questions as we go? Okay. At at the end? At the end. Okay. So, Stefan, if you can wait. Okay.
[01:27:40] Yuzuru Someya: Not the new algorithm. This is only covers a new algorithm. So using the after, like, the PQC or the the other any algorithm is okay. But the new algorithm accepted this extensions. So next. So maybe some guys know that JAdES is a European JSON long term validation system format. So I mister is all set. My project is in Japan government system using the some interconnect we need to sign to monitoring the datas. So at first, we're planning to using the XML. But today, you know, XML is a legacy, so I would like to use the JSON. But JSON, nothing the long term validation signatures. So we checked the JAdES is but JAdES is very difficult. Is it because this is the full spec. So legacy document for. So my LTP database is the most simple simple simple lightweight, implement easy and alright. So this Japanese government project, so accepted the AWS. So I did the hackathon. So today, I have the Java reference implementation for verifi verifiers. So and I support the test vectors, so all levels. Result is the so some hackathon participants, so interest to the this specifications. So and another like the including the host token status list specifications said to this interest this specifications. And another participation first one, so interest are possible to see implementation based on d b j w t. Okay. Last slide. Is a lightweight JSON just a native extension for long term validation of JWS is a Yuzuru. And is there interest that develop developing this work in this? Thank you.
[01:30:36] Karen O'Donoghue: Go ahead.
[01:30:39] Stefan Santesson: Hello. Stefan Santos on. I just wanted to point you out to some other work in this space. So there is r c 9321, which is the signature validation token that it can be put in a JWS in order to with just one signature, do long term validation. Then there is a work in the lamps group called the one signature search that will also solve basically the same problem by tailoring a certificate at signing time that includes information that it's bound to this document, and it's a certificate that doesn't expire. There's one thing with the signature, and that is that you're interested in the status at the time of signing. And if that is the same as the time of issuance, there's no need for revocation because revocation is always gonna be after the signing time. So you can actually get rid of revocation also and make it really, really simple with the one signature certificates. The the SVT follow the same principle that you're actually interested in the validity status of the signature at the time you receive it. And so you can make a proof that it is valid at that time and attach it to the JWS. So that's already in r c nine three two one. Just so you know that there are other simpler simple solutions around that address the same problem except for what's going on in Etsy, which is very complicated. I agree.
[01:32:19] Philip: Scott? Oh.
[01:32:30] Scott Fluhrer: Scott Fluor of Cisco Systems. I'm just thinking out loud. In a certificate, the the attributes in the certificate actually come from the certificate authority. Here, you're these are actually being generated by the signer. How does that change the trust model? You designer could put in any timestamp he wants in there. What does that mean? I'm just thinking out loud. I don't know what the what the answer is.
[01:32:58] Yuzuru Someya: Timestamp is so only count the signatures. So originals those originals signatures.
[01:33:09] Scott Fluhrer: That is what the if you trust actually trust the signer, yes, that is a valid that is trustable if but the signer could also put in any value he wants in there. And
[01:33:21] Yuzuru Someya: Yeah. That is that PKI best. No. Yeah.
[01:33:25] Scott Fluhrer: No. In a a PKI, you trust you're trusting a certificate authority or or the registration authority, not the actual the the holder of the Leaf private key. Mhmm.
[01:33:39] Yuzuru Someya: Yes. So trusted so each time stamp. Yes.
[01:33:43] Scott Fluhrer: Yeah. And be honest, I have it's not clear to me how that changes things in terms of trust or how that can be misused.
[01:33:54] Yuzuru Someya: Okay. So that's after mailing list, please.
[01:34:00] Karen O'Donoghue: Alright. Are there any quest any other comments on this document? So we'll take discussion of it to the mailing list if anybody ask people to take a quick look and see whether you think this work is appropriate or not. Is that okay?
[01:34:14] Yuzuru Someya: Okay. So I I hope any sort recommend and please, negatively okay or positive okay. Please talk to me. Thank you.
[01:34:29] Karen O'Donoghue: You're welcome. Thank you. With that, we're at the end of the agenda. Is there anything we've any other business? Anything that we've missed? Excellent. Well, with that, we give you twenty six extra minutes in your day. Thank you.