**Session Date/Time:** 20 Jul 2026 12:00

[00:00:05] **Stephen Farrell**: Okay. By my clock, it's time to begin. So let's do that. Go ahead, Tom. I think you're gonna do the chair slides.

[00:00:14] **Tom Ritter**: Sounds good. Okay. Welcome everyone to this wonderful Plants meeting again. We're at IETF one twenty six. We're not at a remote location for the meeting in China on the wrong date. But, yeah, I hope everyone had a good lunch. As is tradition, and you might have seen this in the previous meeting, this might be your first session. So please note the note well. If you participate in the IETF, that means that you need to follow rules and procedures, in particular, around IPR and around being a decent human being, also not unimportant. So don't attack people. Also, preferably, don't attack people's ideas. Just assume you have a misunderstanding. Everyone is approaching the IETF with the best intentions. If you are aware that any IETF contribution so, basically, anything that is said or presented on a slide in this meeting or as part of an email on the mailing list or as part of a presentation or a draft is covered by any sort of patent or patent application that either you or your the the person paying the bills controls, then you need to either disclose that preferably through the I t ITF data tracker. There's a link somewhere, or keep your mouth shut. Then there's a please refer to the rules and procedures that's linked on the slides if you want to know more, but I think these are the two sort of most important points. This, I kind of already said it, but please be nice to each other. People fortunately, this working group has been great, but I want to extend the spirit to everyone's participation in all of the IETF that please be nice to people and assume they have the best intentions. Consider that you maybe misunderstood some something of what someone intended, and and, yeah, be pleasant. I have too many peoples that are like, oh, I don't want to go to the IETF. This is, like, the cesspool of people slinging, dugging at each other, and, we can all do better. And as far as I can tell, we have been doing better in the Plants working group, so I'm sort of proud of

[00:02:57] **John Gray**: all you guys, I guess.

[00:02:59] **Tom Ritter**: Okay. Moving on. The agenda today. So we have a number of items on the agenda. We have a little bit of Slack space, so, we're probably not gonna be too stringent unless someone talks, starts talking about something that's so technical that half the room falls asleep. So does anyone have anything that they would like to add to this agenda, or did I miss anything? Going once, going twice.

[00:03:33] **Stephen Farrell**: I guess no agenda bashes.

[00:03:36] **Tom Ritter**: Excellent. Then we're going to immediately just go into this sort of first chairs part, which is kind of already going. Where are we? Well, we have a charter, and we

[00:03:47] **David Benjamin**: have

[00:03:47] **Tom Ritter**: milestones. It's sort of the current status of the working group. This has, of course, been the case. But if you're new to this working group, we're here to see how we can integrate log transparency into certificate issuance so that we can basically make things much better. We had a bunch of milestones about which I have sort of the following to say. The but I think that in particular, the work on the second one is well underway, and we'll see an update from David Benjamin about draft-ietf-plants-merkle-tree-certs, which is, of course, the main adopted item at this moment. Although, I believe that we'll see a new discussion point brought to the group today. Since the last meeting, sort of on the chair side, at the last meeting, we discussed the GitHub policy because the there's this r c eight eight seven four that specifies all the different ways that working groups can can work with GitHub. We're operating in what's called issue discussion mode, so people can do things on GitHub. But you also find that I finally managed to set up the GitHub activities activity summaries so you get these emails I'll leave on Sunday. That's like, all of these issues were opened, etcetera. That is it from our side as far as I know. So that means that we can give the floor to David Benjamin who is hopefully around.

[00:05:18] **Stephen Farrell**: He's coming to the stage.

[00:05:21] **Tom Ritter**: Excellent. So I can only see a very narrow view of the room for, like, the first two sets of chairs to the left and to the right. So if I don't see you, that's why.

[00:05:29] **Stephen Farrell**: It's up to you. I don't know. It's

[00:05:32] **David Benjamin**: kind of entertaining. I've never given

[00:05:34] **Stephen Farrell**: a position to stand before,

[00:05:36] **David Benjamin**: but, yeah, I feel like it would probably confuse me too much. So I will I will do the stand.

[00:05:40] **Stephen Farrell**: Stand on the air. Excellent. This

[00:05:43] **David Benjamin**: is so cool even if I don't use

[00:05:45] **Nalini Elkins**: it. Alright.

[00:05:45] **Stephen Farrell**: Okay. So, Tom, could you put his slides up and give him the clicker?

[00:05:50] **Tom Ritter**: I'm not sure if I can control the clicker from this side.

[00:05:58] **Stephen Farrell**: You see the under the participants list, there's a clicker.

[00:06:03] **Tom Ritter**: Right.

[00:06:06] **Stephen Farrell**: Boom. I can do it if you can't.

[00:06:09] **Tom Ritter**: Fast slide control to clicker. Done. There you

[00:06:13] **Stephen Farrell**: go. Worked. Alright. Let's see. Did it work? It did. Is it the wrong button? It says it did.

[00:06:25] **David Benjamin**: My first this

[00:06:26] **Alexander Bokovoy**: one, I assume.

[00:06:28] **Stephen Farrell**: Alright. We're gonna take that away and just say next slide then. Alright. Sounds good.

[00:06:32] **David Benjamin**: Next slide. Oh,

[00:06:36] **Stephen Farrell**: I did.

[00:06:37] **David Benjamin**: Alright. So this presentation is just gonna This be presentation's just gonna be out what's up. Specifically, what's been going on since the previous draft. There's a little question about what's in a name and what's next. Next slide. What's been going on? Next slide. There's a lot that's been going on. That's a lot. I'm not expecting you to read that. I just copy pasted the changelog. Next slide. So, okay, what did we do? First, we finally sorted out what was a CA. In draft two, there was a big to do for defining how to represent a CA as an x five zero nine oh, yes. Sorry. Sorry. As an x five zero nine cert, which is kind of an important thing to be able to do. And I think we settled on the one where you put the key in the SPKI field, and there's a new critical extension that specifies all the parameters for an MTCCA and also tells you it is one. The original in draft o two, the specs sort of allowed you to have arbitrarily many CA cosigners per CA because it was sort of it just fell out nicely. But then when we went to integrate it with x five zero nine, doesn't quite fall out quite so nicely. The CRL and OCSP stuff doesn't apply, and so we got rid of that. There is now one designated cosigner that is the CA's cosigner. It has the same name as the CA. And now you have an obvious answer for who signs the CRL. So that all works out. You're still allowed to have extra cosigners for things like transparency or whatever other weird ideas people have. But there is one special one now. Next slide. Log generations. I think I talked about this a bunch last meeting. But as a quick recap, compared to directly signed x509, we have this whole new statefulness thing, which is a whole new set of failure modes that we need to go deal with. And so we decided to do this log generations thing where a CA operates a sequence of logs. And you're only supposed to work on one at a time. But if you wedge this one, you can go increment a number and move on to the next one. It's still an incident with all with all the things that implies. If you cannot operate a log, then the root programs might have some feelings. But at least it is sort of a policy side feeling and not a technical feeling, which makes some sort of recovery things a lot easier. To do that, we had to go jam a log number in the serial. So our once nice 64 bit serial is now a sixteen forty eight bit serial. That still should be plenty to work with. We still have everything sequential so we still get all the nice little assumptions we get from the serial number being real again. This has some transparency implications because if there is a continuum of logs, the monitors must be aware of all those logs. And so we have this max serial field and the CA cert and so the thinking is that if you're in a PKI that cares about transparency, you'll just set a budget like, okay the CA over its course's lifetime can screw up like no more than five or 10 times. And that's still a reasonably small number of logs to monitor. Next slide. Log entry extensions. So we already had extensibility by way of x5.09 extensions with all the rules that x5.09 extensions have. But that's just one particular entry type. And there were a couple of mechanisms on the list discussed that wanted to be inserted into all entries. There was some talk of maybe we randomized the hash we randomized the entry to strengthen the hash. And there was this thing from Brendan with binary search locators for these aggregate entries. And since both of these were still, like, a little bit in progress, like, was not clear whether we would need the randomizer, it wasn't clear, like, how all the pieces of the aggregate fit together, We just stuck an extensions field in there and so the thinking is we leave room for ideas like this but we don't block on them. Still expect that most cases we'll want to use x509 extensions because those have more clear semantics but this is there if we need it. Next slide. Acme. There's been so many different Acme ideas tossing about. Hopefully we have now finally settled on one. There was a sketch of something that used the alternate link relation. It had a few issues, primarily that the existing Acme clients treat a missing alternate as an error, which makes no amount of sense because the Acme client a priori assumes that this alternate is not actually optional, that maybe some client over here needs it. But we know that landmark rel=cert is optional and in fact it's definitely not going to be available right away. And so we want the Acme clients to not barf on that. And so the idea was okay, well we'll just make a new link relation. That's easy enough. There was something about the error code. The error code that is a little weird. But it turns out there's an HP error code that seems to be describing exactly our situation so we're using that now instead. And also talk about this at Acme, but here's one slide about it. Next slide. Other stuff. The signature construction got slightly tweaked to match what's happening and what the TLOG folks did for MLDSA. That way you can use your existing TLOG software to implement this, which should hopefully make deployment a lot easier. There was a bunch of placeholders in the MTC spec that has been spread out into their supporting documents where needed. So those to dos are now all cleared. There's a bunch of discussion that didn't impact the actual protocol but hopefully makes the document a little bit easier to read that all have been improved. Next slide. All right, so that's what's been going on. What's in a name? Next slide. So we need to name things. Name things are hard. We ended up naming things based on these trust anchor ideas that TLS working group has. They're basically just oids. They're relative OIDs under some arc because it turns out most of the OID space is completely useless and so might as well save five bytes and only focus on the useful part. But we need to bridge things with lots of different naming conventions. For TLS negotiation, I mean we used the naming scheme that was like fit in there anyway, so it's fine. X509 entities use relative distinguished names. They are a sequence of set of attributes. Anyone who has implemented them probably knows and loves these things. And then TLOG uses these origin strings. So the approach that MTC has picked so that we don't have to keep track of this name matches this name matches this name, which we just take our base name and then map it to everything else. Next slide.

[00:12:37] **Stephen Farrell**: Wait. I thought this was a topic relative OIDs are not supported by a whole bunch

[00:12:43] **David Benjamin**: of work. Is what the next slide is.

[00:12:45] **Devon O'Brien**: Okay. Yeah. Exactly.

[00:12:49] **David Benjamin**: So t log origins, their strings, whatever. We can map them. For x5 and nine names, we made a new RDN attribute so that wraps the trust anchor ID. Since those are relative oids and ASML1 has a type for relative oids, the natural thing would be to just stick relative oids in there. And so that is what we did because it was an any defined by type and so you can stick any type in there. Very early on in the experiment, we hit a compat issue with Go. That will be fixed in the next release. But because of that, the experiment temporarily, or so we thought, switched to a UTF-eight string with a dotted decimal form. But in the spec it still said like use relative OID. It seems more natural ASM one wise. This is just sort of a one off temporary thing or that's what we thought. Then there was a present there and there was some email threads. Next slide. So we should pick which color to paint the bike shed. We can either go with relative OID. It's slightly more compact. Someone on the list said it's good to fix get people to fix their RDN parsers and, you know, basically the same code. On the other hand, we know there's at least one compat issue. Maybe it's temporary. And because of that compat issue, we haven't really exercised it in the early experiments. Or we could go with the one that we've used with experiments where we use a UTF-eight string. That's much, much more common in attribute value assertions today. So hopefully, there's less likely to run into issues. It's a little less compact, but not much so. It's unlikely to force people to fix their RDN parsers. Whether that's a positive or negative, I will leave to readers choice. Let's see. And it is like slightly more placed we have to go convert from ASCII form to like the binary form, but it's just a function call. So I would like to get a sense from people who are involved. Which one do you prefer?

[00:14:42] **Stephen Farrell**: Anyone wanna come to the mic, or do you want me to do a show of hands thing?

[00:14:49] **Bob Beck**: Bob Beck open SSL, relative OID. It's not that hard.

[00:14:56] **Stephen Farrell**: I'm pretty sure that's what I said on the mail list, and a bunch of people said, yes, it is.

[00:15:03] **David Benjamin**: But it's not. About fifty fifty when I last I looked and I was like, I will leave this as a poll. Someone someone pick one.

[00:15:10] **Stephen Farrell**: Okay. K. I'm gonna ask whether you prefer relative OID. And if you do if so, if you prefer the string, say no. If you prefer the relative OID, say yes.

[00:15:45] **Tom Ritter**: This seems to have a strong direction.

[00:15:47] **Dmitry Belyavsky**: Yeah.

[00:15:52] **Stephen Farrell**: I'd say it's pretty definitive.

[00:15:54] **David Benjamin**: Yeah. Alright. Relative what it

[00:15:55] **Stephen Farrell**: is. Okay. Thank you.

[00:15:58] **David Benjamin**: Alright. We have painted the bike shed. Great success. Next slide. Alright. Well, now that we painted the bike shed, what's next? There's that architecture document. We should get on that. Hopefully, next IETF, we'll be able to excitedly tell you that there's an architecture document. In the meantime, the main priority, at least on my end, was to get this back into something that was at least a complete thing that could be an implementation target. And we have that now. So it's time to go build it and flag anything in the spec that's unclear or broken. I can only speak on behalf of people I work with. So we have an email list for Chromium's side of things, other people who have exciting announcements that do not want me to speak for them directly. You should yeah. Also, as a shameless plug, you should come to SAAG on Friday. I will be talking to something potentially related to all of this stuff.

[00:16:51] **Stephen Farrell**: Bob, are you still in queue? Okay. I'll take your hand down then.

[00:17:02] **Bob Beck**: Bob Beck, OpenSSL. Because people keep asking me. OpenSSL will implement. We will make no guarantees on what release it will be in or time and when. No time or date promises yet, but OpenSSL will be implementing.

[00:17:23] **Stephen Farrell**: Anyone else? Like, Claude, I ever wanna say something?

[00:17:28] **David Benjamin**: I mean, there have been some blog posts. Just, you know I don't I'm not directly associated with them, so I feel like I shouldn't myself say things.

[00:17:41] **Bas Westerbaan**: Was this the one, Claude? How are we going to implement this?

[00:17:47] **Tom Ritter**: Big surprise, Miles. Yeah. The meantime, I think we will have, at the end of today, also an implement someone from the hackathon who's gonna I mean, that was Acme rather than Right. Sort of the user side. But if we do get more people working together on related subjects at the hackathon or whatever, I would be very happy to invite those people to also talk about that in next planned sessions.

[00:18:16] **David Benjamin**: That does remind me. I was going to mention so the spec repo has this demo tool that can generate certs. It does not yet have something that can verify certs. I'm probably gonna put something in there maybe, like, next week or so. And so when when that's there, I'll send it out to the mailing list, and hopefully that will make it like, give like at least one thing everyone can interrupt tests for sure. And then, you know, because if you're doing certain stuff, sometimes you have to go figure out how this particular system takes a new CA and like

[00:18:45] **Stephen Farrell**: Yeah. Alexander, your hand's up.

[00:18:48] **Alexander Bokovoy**: Alexander Bokovoy, Red Hat. So I will be talking about

[00:18:53] **Stephen Farrell**: Raise the mic to your mouth. Closer? You have to point right to it. Yeah. Okay.

[00:18:59] **Alexander Bokovoy**: Yes. Yes. Alexander Bokovoy, Red Hat. I will be talking about the Akamu, which is the the one that has a report from hackathon. We already implement MTC draft five there. Unfortunately, comparing it with something else is hard, but relative OIDs are there already. It

[00:19:28] **Tom Ritter**: can be done.

[00:19:33] **David Benjamin**: Well, that's all I had. So yes.

[00:19:35] **Stephen Farrell**: Okay. Thank you.

[00:19:41] **David Benjamin**: Alright. Let's also

[00:19:44] **Tom Ritter**: let me take this moment to remind people that they should register in with MeetEcho and sign in to the meeting. Also, if you're present in person, that helps us get the right size room the next time.

[00:20:01] **Stephen Farrell**: Okay. Would you bring up the next slide deck while I adjust the microphone?

[00:20:05] **Tom Ritter**: Let me that will be log reconciliation. Brandon, welcome.

[00:20:14] **Brandon Sloane**: Hello. Can you hear me okay? Yep.

[00:20:18] **Tom Ritter**: Let me pass control.

[00:20:21] **Brandon Sloane**: Great. Okay. Cool. So hi, everyone. My name is Brandon, and I'm gonna talk about log reconciliation, which is this idea that's kind of developed through conversations on the mailing list and on the GitHub. But yeah. So for a little bit of background, so in transparency systems, we generally expect logs to be linear, meaning that they go from one state to the next state to the next state, and everybody can agree on what the order of those transitions was. So if you have, like, a certificate transparency log, you add certificates to it. Everybody can agree on what order those certificates were added. And and and typically, that works. Logs generally are able to be linear, although not always. Sometimes they work. And a fork is essentially when a log tells some people that a log contains certain information, and it tells other people that it contains different information. And that is bad because now everybody doesn't agree on what is in the log. And there are lots of reasons that forks can happen. Generally, it's because of either, you know, one incorrect handling of network partitions. So if you have a log that is built as a distributed system and that system gets partitioned somehow, the different sides of the partition might have different views of what the log is. It might tell people different things. Or the other common reason is accidental data loss. So, like, maybe a log says, yes. The certificate is absolutely in the log, and then something happens where all record of that certificate is just gone. Like, maybe the process terminates before it makes it to disk, or maybe the disk just, like, disappears or, like, fails or something. And then because the log doesn't know any better, it doesn't have the certificate back. It doesn't, it essentially put something else where it said that certificate was. And in either case, you have the problem of you told different people different things about what's in the log. Now in in Merkle tree certificates specifically, because logs are always pushing their their contents to mirrors to get cosignatures. Whenever a log forks, what happens is it shows that fork to some mirror, and mirrors that saw the, quote, unquote, wrong fork are essentially lost forever, and they can't be used to produce cosignatures anymore. That's because mirrors try to enforce this idea of, like, this this linear order the log's supposed to go one after the other. And so if I show a a mirror a fork, then the mirror is gonna start refusing to to cosign any new versions of the log unless they are continuations of that same fork that we decided was a mistake and that we don't actually wanna continue anymore. So the the kind of problem statement here is, winner, if there is a fork, what do we do? And, specifically, what do we do to recover these stuck mirrors so that they can be useful again and not be just, like, stuck on a fork forever? Like Benjamin talked about or or David talked about, since last IETF text was merged for what's called log generations. And, essentially, the idea here is converting a single transparency log into a series of generations, where each generation is kind of like its own independent log. So before, a CA was just one log, and now a CA is a series of several logs that you go through in sequence. And that's meant to to correspond kind of roughly to this idea of, you know, before CAs had one chance to run their log correctly, and now they have several chances. So if they mess up on generation one, they can move on to generation two. And if they mess up on generation two, they can move on to generation three and keep going like that. The the issue here and the reason why I have been kind of critical of this approach is because it has this attitude of, like, if a log forts, then we have to throw it away because it's it's garbage and it's not useful anymore. And I don't think that's really true. Like, people could have been and probably were shown certificates that ended up on this fork. And even if the plan is to immediately revoke all of the certificates, the certificates were still issued and they were still used. And because of that, I think that they should probably still be subject to the same transparency guarantees as all of the other certificates in our system. And kind of as a take as as kind of a digression, I think the the temptation in this approach and why people like this idea is because it's really a continuation of what happens in CT. When a CT log misbehaves, you just immediately disqualify it. But a log in CT is not really analogous to how a log works in Merkle tree certificates. So, like, in certificate transparency, when a CA messes up, you don't have to immediately distress the CA because you can say, well, everything is logged and published, and so we can make it right. Know, that's why we built the whole CT ecosystem is so that when CAs mess up, we can correct it in a reasonable way. But when a CT log messes up, you lose the guarantee that everything is logged and published, and so that's why you have to stress the log. So when a CA messes up, you can say everything is published. We know what it is. When a log in CT messes up, you can no longer say everything is published and we know what it is. And so going back to Merkle-tree certificates, the role that logs used to do in CT is now what mirrors do. So it's the mirror's job to make sure that everything is published. And so when CAs mess up, the mirrors are what's there to help you recover. And so when the CA messes up, it's not like you have to throw the whole thing away. You can use you can rely on the mirrors to get back to a good state. And to kind of justify why that might be important to be able to recover from a a fork log. So when you have certificates that get issued on a fork and then you kind of just decide we're gonna leave them on this fork, those certificates are a lot more likely to be missed by monitors. So if the monitor is not capable of ingesting forks, which could happen because, generally, we don't expect forks. So it's very easy for a monitor to justify, like, not writing that code that identifies, oh, this mirror is forked at some point. I have to go crawl that fork from that mirror specifically. It could also happen that that certificates are missed if a fork is in a mirror that was trusted relatively recently. So maybe the monitor just doesn't know about that mirror yet, and so that mirror gets shown to four q. The monitor never knows to go look at that, and it never sees those certificates. And, also, because forks sort of by design only exist on a subset of mirrors or on maybe just one mirror, the certificates there are more likely are more likely to be deleted or lost. So it's kind of worth reflecting on to improve this, we can we can ask ourselves what's the property that we actually want from locks. And it's easiest just to say, well, okay. We want logs that keep all of this data in a perfect line, like kind of how we traditionally understood CT logs. But that property itself is not really what we care about. What we care about is this idea that everybody can see everything that's been submitted to a lock. And those two things are not really the same, like keeping data in a perfect line, having this linearizability property is a really helpful tool that can help make sure that everybody sees everything that's been submitted, but it's not itself the goal. And so if we say, you know, okay. We can let go of this property that everything has to be in a perfect line. What can we actually do? Well, we can do something called reconciliation. And reconciliation is this idea that, you know, if a log presents one fork to one mirror and a different fork to a different mirror, the log should be able to merge those two different views so that the mirrors agree again. And the way that you would do that is something like this, where we have our fork. And then, you know, basically, we just take the certificates from work, and we pop them onto the end of the other fork. And now everybody is is happy because everybody can see the same certificates again. Both of the mirrors agree again. And so these mirrors are essentially useful. They can both be used equally, and everybody knows everything that's been issued. And you may be thinking to yourself, isn't this just git rebase? And, yes, it is. And that is actually the totality of my argument that this is not an insane idea. There's precedent. So how could it possibly be insane? You maybe even did it today. And more specifically, like, implementation wise, how we would implement the sort of rebase or, like, reconciliation idea. Well, from Miro's a perspective from Miro a's perspective, who saw the kind of simpler version of the fork, you just submit the the certificates that run the fork. And so this is not special for mirror a at all. Mirror b is a little bit more interesting, a little bit more complicated. So mirror b, step one. Mirror b has to see a fork that is, inconsistent with what our other mirrors have been shown. Then in step two, essentially, what the log does is it goes to the mirror and then ask the mirror to go back to some kind of regressed view. When this happens, the mirror doesn't just delete the certificates that were submitted after this point. It moves them into a backlog where they're not, you know, in the log anymore, but they are safe and the MIRROR still has them. And then once those certificates are in the backlog, the log resubmits any missing certificates to the MiR that it needs. And it's important that, you know, while this backlog is nonempty, the MiR never issues any new cosignatures. And that is it's necessary to make sure that there is actually an incentive to empty the backlog. Because if the mirror was willing to keep operating in this mode, you know, maybe the backlog just never gets emptied, and those certificates don't end up where people can see them. But yeah. And so then once we've added once we've added any kind of missing certificates that we need, we go through and we resubmit all of the certificates that are in the backlog, taking them kind of like a queue, resubmitting them in order. And once the backlog is empty again, then you're done. This mirror is reconciled, and the mirror can start providing cosignatures again, and it has the same view as all of the other mirrors. So that's how it works for the mirror. From a monitor's perspective, if a monitor happens to be, you know, crawling some mirror that goes through reconciliation, all it really has to do is jump back to some some common ancestor point, and that can be signaled through, like, an API with the mirror and then start crawling again. And that obviously does result in processing the same certificate multiple times, but you get this really nice guarantee that every certificate that's been issued on any fork, your monitor will see at least once. And monitors can also either trust the mirror to do reconciliation correctly, which is kind of everybody trusts the mirror to do reconciliation correctly because that's his job. But the monitor can also check that reconciliation was done with a typical kind of consistency proof. So that's also pretty easy. So to to recap and to kind of fully compare this with the idea of, like, we're just gonna throw the log away if it ever is operated incorrectly, and we're gonna move on to the next generation. I think the reconciliation significantly simplifies monitor implementation. So with the log generation idea, essentially, each mirror could potentially be shown a different fork, and monitors need to be able to essentially look at every single mirror, identify if a mirror has been shown off work, and then identify where the fork happens, go through and crawl that fork from that mirror specifically and, like, have some way to represent forks internally. That can all be relatively complicated. Whereas with reconciliation, logs are essentially always in a linear order from the monitor's from the monitor's perspective. It's just that sometimes the the monitor has to go back and start over a little bit, but it's always in a linear order. And, also, it doesn't matter which mirror the the monitor actually uses. You can call it linear, and as long as they all end up reconciled in the end, the monitor will see every certificate. Reconciliation also ensures that forks are mirrored equally as well. So with, if we're just gonna leave kind of forks out in the world, then certificates may exist only on one fork that's only in one specific mirror, and it's, more likely to be lost or deleted. Whereas with reconciliation, if you issue a certificate on a fork, that certificate just gets, you know, put back into every other mirror, gets put back into the same view that every other mirror sees. And so that is is guaranteed to last a little bit longer. And then the third thing is that reconciliation makes monitors more resilient to still configuration. So that's what I talked about a little bit before where if a if a new mirror becomes trusted and the monitor doesn't know about it yet, then any certificates on a forks into that mirror specifically, the monitor will not know about. It won't see them. And so those would be missed. Whereas with reconciliation, even if a fork is sent to an unknown mirror, if that unknown mirror is reconciled with the known mirrors, then our monitor will still see it. So that's quite nice. And so next steps, if this is kind of an idea that we wanna move forward with or feel comfortable with, then, actually, the majority of the work would just be a proposal to CTSP to the the TLOG specification there. That's not in the IETF at all. And then the only work in the IETF would be maybe backing out the log generations text as it would, be redundant at that point. But, yeah, that's all I have. Thank you so much.

[00:34:43] **Stephen Farrell**: Questions for the presenter? I'd like to know if people wanna go forward with this proposal.

[00:34:54] **Bob Beck**: Brendan, quick one. I might have missed it because I'm dumb. Was there a limit to how many times this could fork and resolve? Like, just in case your CA decided to be a bastard and just fork repeatedly and force to redo it and redo it and redo it and it constantly?

[00:35:13] **Brandon Sloane**: No. There's no limit at all to to how many times you can fork and reconcile. And it's also kind of up to what happens in C2SP with the MIRROR specification, how how sophisticated you wanna be and how you let logs reconcile. Like, in get their different merge strategies, you can have this very simple kind of rebase thing, or you could do things that are more complicated. So there's no limit, and there's also no limit to the complexity of how you can reconcile except, like, what you're willing to implement.

[00:35:46] **Wes Hardaker**: Wes? Yeah. Wes Hertaker. And thank you for that because I think I'm gonna follow it up with something similar. But my my original question was more along the lines of, I mean, monitors are still stuck if they're not monitoring all mirrors and they get they're doing monitoring in the middle before the mirrors reconcile. So there is a a timing window where things may not match. Right? But I I think my follow-up is when you I'm I'm picturing I'm dating myself. For the days that that people knew of IRC net splits and what it was like to be on one side of a net split versus another when things separated, this at least reconciles that. You could actually go back and fix IRC too. But I I think the complexity that you're gonna hit is what happens when you have, you know, five mirrors and some of them are beginning to merge and other ones don't. And, you know, it'd be interesting to see the analysis of that sort of more complex situation on how you resolve two mirrors and two other mirrors that have each reconciled with each other and then need to reconcile as a whole or something like that.

[00:36:52] **Brandon Sloane**: Yeah. That's a good point. And to oh, I forgot what I was gonna say. I'll say it if it comes back to me.

[00:37:03] **Dennis Jackson**: Dennis Jackson, Mozilla. Yeah. I I I'm maybe more worried about complexity in the mirror implementation than I am about complexity in the monitor implementation. It seems like if monitors go a bit wrong, that's gonna be an issue, but it's a fixable issue. And we'll regain observability when the monitor's fixed. Whereas when mirrors go wrong, there's potentially a pause of issuance and an outage. And, you know, generally, if we want a robust mirror ecosystem, the mirrors really have to be able to, you know, agree on consistent state. So keeping that as simple as possible seems like a real priority.

[00:37:45] **Joe DeBlasio**: Joe Blasio. Excuse me. Joe Blasio, Google Chrome. I actually, I shared Dennis' concern about complexity in in general. But in in particular, in this case, I'm a little bit worried about the the operational realities of on the the CA issuer needing to to readd these entries after the fact. I you know, one thing I've heard from a number of CAs who are experimenting with MDCs right now is, you know, how how tightly coupled their process their their, like, their auditing pipelines need to be with everything that's gonna get logged into this log. And I can just I can imagine this causing some real operational headaches. So just something to keep in mind as we as we go down that road.

[00:38:29] **Brandon Sloane**: What kind of operational headaches do you think?

[00:38:37] **Joe DeBlasio**: I would rather than than put myself out there, I'm gonna just say that, like, I I I would wanna hear from from CAs before before going forward because that's that's not my expertise. But I hear their pain even if I don't understand it well myself.

[00:38:59] **Aaron Gable**: Hi, everyone. Aaron. Let's encrypt. My primary thought about this, I I definitely share some of the already expressed concerns about, like, where does this push complexity in the ecosystem. But the other concern that occurred to me is that I I kind of want it to be really clear when this happens. I don't think it should be possible for a CA to sort

[00:39:30] **Bas Westerbaan**: of

[00:39:31] **Aaron Gable**: transparently recover from a fork and rebase its set of forked leaves and have everyone just sort of move on as though nothing happened. And so I'm contemplating two things. One, which is what if this isn't entirely in the t log mirror spec? What if this is in the Merkle spec itself itself by virtue of having a new leaf entry type that is, like, a rebased forked TDS log entry type? And the only way a fork the only way a log is allowed to unfork is by sequencing a bunch of leaf entries that are specifically this, I'm in the process of rebasing a fork, sorry, everybody, entry type, and then it is in the permanent record that these were part of rebasing a fork. Every year he becomes aware of the fact that these were part of rebasing a fork. Maybe those log entries are somehow never trusted by browsers at all because they bear a entry extension or I I I don't know the exact way that we would semantically indicate it. The other thought I had is, hey. What if there's a merge strategy instead of a rebase strategy? And there's a different log entry type that is the, hey. Here in one individual log entry, here's everything that got forked. And then if that were the case, it would be much easier it it would be much simpler for a fork to mirror to unfork. It would just see, oh, there is one log entry that takes care of everything that I have after this specific point. And now I can continue catching up from there. And there wouldn't have to be extra t log mirror shenanigans. There wouldn't have to be mirrors maintaining a a a backlog that they have to work through and refuse to sequence anything unless that backlog is full. It would just be, yeah, I have seen the one entry that tells me everything about what just happened, and now I can move on from there. Again, still concerns about complexity, but I think building it directly into log entry types as opposed to just hoisting all of the complexity off to the t log mirror protocol might help reduce some of that complexity.

[00:42:03] **Brandon Sloane**: I think that that idea is really, really good actually. The idea of moving the whole backlog into a single log entry that can be verified essentially, atomically. I think that's a really great idea.

[00:42:17] **Rich Salz**: Rich? Yeah. Rich Sauls. One of your previous slides, there's no page number so I can't tell you which one. It said, you know, when there's when there's a backlog, the mirror doesn't issue any signatures until it's caught up. What if yeah. This one. And you can just assert that it's not an issue rather than try to prove it here. What if there's two or three logs that are out of sync? Could you get in could you end up with a dead log a deadlock?

[00:42:46] **Brandon Sloane**: No. You can't end up I mean

[00:42:50] **Devon O'Brien**: You know?

[00:42:50] **Brandon Sloane**: The the action of kinda merging the fork is pairwise, but you can always do these pairwise merges to get to a point where everyone agrees again. So the action of reconciling, can think of it as being like a pairwise operation, but you just keep doing these pairwise operations until everybody gets to the same place. So you never really have a deadlock.

[00:43:10] **Rich Salz**: Well, I was thinking suppose a and b have different sets of certificates, then there nothing happens until they're all synced, or can people sync and get their backlog from the other one? You know? Okay. As I said, I'll take an assertion that it's not okay. But I'm not thinking of multiple parties. I'm thinking two parties that are each have to sync up with each other.

[00:43:37] **Brandon Sloane**: I mean, there's like a a semantic thing where you say, okay. This one fork is correct, and we're going to rebase what's different from the other fork on top of this.

[00:43:47] **Rich Salz**: Yeah. But I no. I suppose both forks are corrupt.

[00:43:51] **Brandon Sloane**: Well, yeah. That's what I'm saying.

[00:43:52] **David Benjamin**: It's a

[00:43:53] **Rich Salz**: three way merge as opposed to a rebase.

[00:43:59] **Brandon Sloane**: I would need to think more about that. I don't think that that's an issue. But yeah.

[00:44:10] **David Benjamin**: David Benjamin. So I I also share the complexity concerns. I realized something while Aaron was suggesting the merge thing that we actually have like, it is actually really important that the rebases are visible because at least I mean, unless we redo a whole bunch of other things, the when you rebase them, they're gonna have different positions in the tree, which means they have different serial numbers. But serial numbers are the handles by which we revoke stuff. And so if once if it is now unclear to everyone whether or not certificate 42 is, like, the sketchy one or the okay one, we might not be revoking the right things. And so in the, like, just abandon the log and move on to a new one model, we can see that something went wrong in this log because we can go look, oh, this mirror is here and this mirror is here. And so that we can go, okay, we're gonna revoke everything because we know that these indices are in question. But if we try to just transparently, rebase it, then we don't actually have the evidence that some indices were in question, so we won't know to revoke them.

[00:45:08] **Brandon Sloane**: Yeah. I think that you're right about not knowing whether or not you can revoke them. With any sort of strategy for revoking by serial number, you're gonna have, like, this collateral damage effect where I wanna revoke certificate 42, but 42 exists on two different forks. And so you're gonna revoke both of them. And then when you rebase, you have to revoke whatever 42 on the bad fork gets remapped to its new serial number. And so you still have that collateral damage. But, yeah, you do definitely need to know that something happens so that you can revoke those things.

[00:45:41] **David Benjamin**: Right. The the issue is that the the folks doing the rebase are the mirrors, but the folks doing the revoking are the, like, relying parties and their vendors. And they're not gonna talk to each other necessarily mean, you could have the mirrors go say, hi. I rebased, but there's no, like, evidence of this fact. You just have to hope that they remember to say it. Mhmm.

[00:46:01] **John Gray**: Yeah. Devin

[00:46:06] **Devon O'Brien**: O'Brien, Apple. I was actually gonna say something very similar to what David did, but I also wanna talk about just this only works I know this is like a a technical specification, but this will only work if every MTC user agent in the ecosystem allows it and permits it. So there's sort of like this consensus thing that we've had to do for things like that. So I'd really wanna make sure that this is a palatable thing for all of them because that could sort of make something dead in the water after a lot of effort. But one of the things I wanna think about was you you you talked about that the rationale for this was sort of like trying to address the failure mode wherein we have to distrust a log or an MTCCA because of because of this and introducing sort of a recovery path. But in my experience with CT, one of the things that has plagued us are things like bit flips with no known pre image or think think, know, there are other non recoverable failure modes here that occur with transparency logs. And as best as I can tell, we still need to go through this burdensome path the undesirable churn to address those failure modes. And so one of the things I think would be worth exploring is whether or not there are other mechanisms like lifting overall ecosystem agility or support to make churn less bad. That was sort of treated as an invariant justifying this. And so I think in order to evaluate this, we maybe not be we may not be able to treat that as as a ground truth, and we may need to be able to explore, are there other solutions to making that less of a bad thing? Because, you know, this is complexity and this introduces more interesting failure modes. I understand Git is a thing that exists and the metaphor I think is apt, but I think Git also has some failure modes that in distributed systems may make it more difficult in practice. And if we commit to this path, we may have some sharp sharp edges that we find ourselves poked by.

[00:47:59] **Brandon Sloane**: And I really didn't talk about it in this presentation, but something that Merkle free certificates, I think, does right that gets rid of a lot of these, like, bit flip error conditions is we have the log, and then the log is fully mirrored. So a log is not gonna be able to get a cosignature on just any kind of junk. The log has to actually submit certificate a b c, and then it gets a signature on that. So the the use of mirrors reduces the air conditions a lot because you're only going to get valid cosignatures on certificates that actually exist, if you know what I mean. You're not gonna, like, sign some junk, and then there's, like, a there's a hash with no known pre image out there with, like, valid cosignatures.

[00:48:52] **Stephen Farrell**: Okay, Jay.

[00:48:53] **Jay**: Yeah. I think the previous two speakers sorry. I have a little back, background noise here. But I think the previous two speakers said most of what I wanted to say, and I just wanted to sort of reinforce that from a, you know, concern around malicious issuance. The Git rebase analogy is a nice one, but has anyone here tried to do Git rebase on a malicious Git history or malicious or conflicting Git history, it's not like, certainly, just for a for a non malicious conflicting Git history, Git rebase is a nontrivial thing. And if it's generated maliciously, which a you know, we're trying to detect malfeasance here. I think there's a lot that can go wrong in attempting to, you know, smooth the path for a simple rebase. And, I'm I'm I'm very dubious that this is as easy as let's just shrug and say, hey. We all do get rebase all the time. It must be fine. I think that's I think that's really unlikely.

[00:49:58] **Brandon Sloane**: I'm not sure how you would make the rebase malicious, but one of the big advantages of the strategy to me is this middle point as well, ensuring that forks are mirrored as well. So when you have a malicious issuance, I think it's very important to make sure that that malicious issuance doesn't end up on a fork that somebody can, like, ignore or get deleted or disappear from the world. Like, that fork and that malicious certificate should be repersisted in every mirror and not not subject to weaker transparency guarantees than everything else.

[00:50:37] **Stephen Farrell**: Joe?

[00:50:39] **Joe DeBlasio**: Jim Vazio, Google Chrome. I think part of what I'm struggling with as I think through this is that, you know, I think your system, if you go back to the slide you run just a moment ago, sort of at its core, it's saying a mirror notices that it is itself on a fork and then takes some action. And, like, I you know, how did the how did the mirror discover that it was on a fork? If it figured that out, you're already in a position where it could make all sorts of noise about it, and we could take some sort of policy action or whatever else. If your if your threat model is that any mirror can disappear at any given time, then as soon as this mirror discovers that it's on a fork, like, it could disappear off the face of the earth, and it would lose its backlog, and we wouldn't actually get the benefit. So I'm just I'm struggling a little bit because we're not I'm not convinced we're getting dramatically more visibility with this model than we do in the status quo because we haven't actually increased the, like, the we we have eventual consistency with this model, perhaps, in a way that we don't with the current model, but not at any given point in time.

[00:51:49] **Brandon Sloane**: So operationally, I picture this as being something that is driven by the transparency log, so it's driven by the CA. So the CA goes and says, oh, I accidentally did a fork. Now I have to get these mirrors aligned again. And just like the security model of of Merkle-three certificates is collusion security. So if we're gonna say, okay. The CA is, quote, unquote, malicious even if they're accidentally malicious by issuing a fork, we have to assume that all of the mirrors are not malicious. And so all the mirrors are gonna try to hold the CA accountable. If we're gonna say, okay. The CA is malicious, and one or more of the mirrors is also malicious, that's outside of the threat model. Or the mirrors are not completely following their obligations to the ecosystem.

[00:52:34] **Joe DeBlasio**: But if the mirrors are available and non malicious, then they are there ready to serve the evidence of the misissuance to begin with. Right? Like, you either have the mirrors serving the data so that everyone can see the the misissued misissued certificates, or they disappear off the face of the earth and they can't participate in the recovery story.

[00:52:59] **Brandon Sloane**: I mean, yes. The purpose of this is not to cover up evidence of misissuance. It's just to get the mirror back to a good state. I did make the point that when you have a certificate that's only on one mirror, that certificate is potentially more likely to be deleted or get lost. That's more of, like, a long term thing if you say, like, this certificate is only, like, hosted on one server on the Internet, like, it's not necessarily an active maliciousness. It's like maybe that mirror, like, retires after a while. But if we say there are certificates that only exist here specifically, that mirror can never retire. Because if it does, the certificate's gonna go away.

[00:53:41] **Stephen Farrell**: Okay. The queue is empty.

[00:53:43] **Brandon Sloane**: Thank you so much, everyone.

[00:53:46] **Stephen Farrell**: Thank you.

[00:53:58] **Tom Ritter**: Some long discussion there. Let's continue that on the list. We're gonna continue with MTC deployment use cases by John.

[00:54:15] **Stephen Farrell**: This is supposed to work now.

[00:54:18] **John Gray**: Hello? You guys can hear me? Okay. Good. Okay. So I'm gonna talk to you about MTC deployment use cases. So that's people working on this, myself, Jan Klasner, who's actually here, El Tindil, who's here today, and Ganesh Meletta, he's not here to I don't think he's here. If you're here, anyway, put up your hand. And then, of course, we had support from Bas Westerbaan and David Benjamin, who you all know. So the motivation for this work was so the Merkle tree certificates, mean, what we've been talking about, this whole working group, right, has three kind of main several benefits, I guess, for the WebPKI that have been shown. So there's the certificate size reduction. So that's the public key inclusion proof. You get better performance. Those really small landmark certificates. That's a really cool thing. Right? So there's and there's downgrade detection, especially in the context of PQ. So the transparency logs and all the stuff we just heard and we're talking about, that's a really kinda a cool thing as well. And then the batch signing. So reducing the load on the CA because you can have a single signature that kinda represents, you know, a whole bunch of certificates. So that's an interesting efficiency as well. So our kind of motivation on this was the question was, could these types of optimizations benefit other types of deployments? So specifically, think about, like, the private PK use use cases or community of trust PK environments, those kinds of places. So can some of this Merkle tree stuff apply to this? So how this all started. So since the plants meeting in March 2025 yeah. So, I mean, it's it's really recent. We just we got together, a couple of us, to cultivate a discussion around these use cases. So I tried to make things a little bit fun, too, using, you know, the plants, puns, and the little pictures as well. So hopefully, you know, if you're falling asleep after lunch, this will hopefully be a little bit entertaining, too. But so the result is a draft that has taken root, and then it's growing. And it turns out there's actually a whole garden of ideas to explore. So I'm just going to go over a couple of things that we found. I'm not going to really go into the technical details because one of the things, it's very easy to get into the weeds. So interesting thing. So the use case that we identified are the landmark certificate verifying mechanisms. So places where the WebPKI and private PKIs kind of intersect. And we're going to see those things. Right? Like I I work on a crypto library, and suddenly I come across this landmark certificate. How am I going to verify it? I'm not a browser. Right? Like, I don't have access to all the details to do that. So how would you do that? So so that's kind of the question for the for this type of use case. So we actually started talking about this. We had, I think we've had four or five discussion meetings. So we started working on defining something we're calling a landmark distribution point fetching mechanism to distribute landmarks with subtree proofs. There's a number of ideas in the draft how to do this efficiently. Obviously, it's not it's not at a state where you could implement it, like, you know, in a production environment, but we're trying to get something that's not gonna be too complicated, but also efficient, And that would be doable. Yeah. So, yeah. And the other kind of hope, you're in we're trying to carve out these things. So perhaps this is doable to get the efficient landmark certificates without requiring, like, a transparency log, and what would that look like? So that's all part of this as well, right? So basically cutting out pieces of this thing and seeing if they can be used in these kind of use cases. Then there were some other ones that were identified as well. Actually, at pretty much the last minute, we were about to submit the draft. Ganesh submitted at least three other use cases I'm just going to talk about now briefly. So one was code signing and software supply chain integrity. So that one is about using the the efficiency of the batch signing operations oh, sorry, batch signing optimizations and using the transparency log to detect tampering. Yeah. And it also has, it pretty much goes into a couple weeds too about an information model for code signing and log entry and how, yeah, it could be done, right? So it discusses that. And then there's the private PKI PQC migration with downgrade detection. So there's that use case. So a lot of the PQC migration's going to happen. You're going to probably set up, you know, a classic PKI and then have a new PKI. But one of the issues is that once you have that downgrade, attacks can happen, right? Because you might think that old stuff isn't being used, but it is. So the interesting thing is, obviously, with this with the log the whole log capability in that feature, you should probably use it to detect that in those use cases. So the draft has some discussion about that. And, yeah, and then a constrained device. So if you're in an offline environment, or maybe the device doesn't have as much, you know, power or whatever, is there a way to do that? And you can see that the trees there and that are kind of wilting, or it's a bonsai tree, right? It's a constrained environment. So anyway, so that's the use case that's discussed as well. And then we haven't actually put this in the draft yet, but revocation is an interesting one. So we actually did I think our last meeting, we started talking about it a bit. So it was after the publication deadline. So we don't have anything there. We did a couple of us with you've probably heard the Merkle-tree ladder stuff. So at LAMP's meeting at IETF one twenty one, we had some, discussion about that as well. But, again, that's again, using Merkle-tree kind of batch signing for the efficiency. So if you think something like OCSP, you have proofs. They all have to be signed. Well, in a Merkle tree, they wouldn't have to be signed. They basically turn into signatures. So you get a really great optimization there. You know, discussions on that would be around how to when you when these things are issued, how efficient can it be? How's the client verifier going to do this in a way that they don't have to download, you know, the full sign tree head that often. Right? So that's the kind of thing that would go into that. So that's another use case. Even since then, I thought about because I mentioned the Merkle tree ladder. There's Merkle tree ladder. There's Merkle tree certificates. You know, those have slightly different structures. They're both using Merkle trees. Maybe that's something else to discuss in this draft. You know, maybe there's maybe using one is more amenable in certain use cases. Maybe using another one is more amenable. Right? So that could be something discussed, too. So next steps. So we think there's a lot of seeds that have been planted in this draft. So I think we would ask for adoption because there's a lot to discuss. In fact, there's so much to discuss and so many things I think we've turned up. So we're just kind of I was gonna say scratching the surface, but I think a better way to say it is just turning over the topsoil. Right? Get it? Yeah. So, the draft's already 25 pages. Right? We've had done a lot of brainstorming. There's there's probably a lot more use cases that these efficiencies could apply. And but one thing, we did start digging into weeds very quickly. It was very easy to start looking, you know, at like their landmark distribution point mechanism and those kinds of things. And to the point where we're at, want to ask the working group, assuming this is things, and I think it makes sense for the plans charter that we want to talk about, should we break like, have one high level use cases draft like this one, and then maybe, you know, what I say in here, branch off other drafts for more details.

[01:01:46] **Stephen Farrell**: Right?

[01:01:47] **John Gray**: I think that's what I say there. Branch off more drafts. We think there's a lot of fruit there. So even, like, the landmark distribution point mechanism for verifiers, I think that could probably be its own draft. Revocation could be its own draft. Some of these other things could probably be their own drafts, right, that would go into the technical details of how these things could be done. So so yeah, that's so that's kind of the direction that we're looking at from the working group. Just want to ask those questions. So, yeah, that's that's basically it. We've identified these use cases, and, I was gonna say thank you and hoping that things will continue to grow as new seeds and ideas are planted. So questions? I guess, Dmitry?

[01:02:25] **Stephen Farrell**: Dmitry.

[01:02:28] **Dmitry Belyavsky**: Hello? Dmitry Believsky here at Cut. Could you please scroll back to the slide that covers downgrade protection? Yeah. Yeah. So when we live in the phase of parallel PKI setup post quantum and traditional, heavy having to have having go reissue reissuing the traditional certificates, so not in sync with post quantum. Having a traditional certificate issued after the post quantum does not indicate the downgrade attack if a resource is interested in providing access for all clients. So I'm not sure that this can be used for downgrade protection. Could you please elaborate?

[01:03:28] **John Gray**: Yeah. So the the draft discusses ideas on how that could be used. Doesn't mean that it's gonna be set in stone or hard. Go ahead, Dennis.

[01:03:39] **Dennis Jackson**: Dennis Jackson, Mozilla.

[01:03:40] **David Benjamin**: I would probably be

[01:03:41] **Dennis Jackson**: in favor of moving, like, high level use cases into the architecture document, even if it's in an appendix, sort of keep it separate as, like, alternative deployment models.

[01:03:51] **Jay**: Okay.

[01:03:51] **Dennis Jackson**: And then focus drafts for the mechanisms that you think are valuable in the order that people are interested in them.

[01:03:57] **Brandon Sloane**: Yeah. Yeah. Honestly.

[01:03:57] **John Gray**: We need people to help. Right? There's Yeah. There's four of us or whatever, and there's just there's a lot of things we've turned over. Right?

[01:04:03] **Dennis Jackson**: Yeah. Which helps which helps sort it out. And then profiling it for a specific kind of PKI deployment

[01:04:09] **Stephen Farrell**: Yeah.

[01:04:09] **Dennis Jackson**: Can then be a document that's like both use case and exactly how to do it, referencing those other bits. But sort of, you know, arise at the end when we're actually confident we know what we're doing.

[01:04:18] **John Gray**: Yep. Yep. That's exactly the direction we're looking for. And we think that makes sense too. So, Aaron?

[01:04:29] **Aaron Gable**: Hello, Aaron. Let's encrypt. Two maybe quick questions. I know we don't wanna dive, like, too far into the technical details right now, but landmark distribution point is the current thought that this is basically in a extension that gets baked into the cert, like, a CRL distribution point, and then anyone with their hands on that cert can, like, hit some API to get the necessary information?

[01:04:55] **John Gray**: Yes. Or is there there a question there? Yeah. I mean, landmark distribution point. Yeah. CRL distribution point. I mean, I guess it's it's it's similar. What we have in the draft right now is an it's it's an extension on the issuer cert, and then it uses the the proof that that's already in the landmark certificate to to form, like, an URI and that kind of thing. That's what's in there now.

[01:05:17] **Alexander Bokovoy**: Okay. Sweet.

[01:05:18] **John Gray**: Similar idea, but not exactly the same mechanism. Yeah.

[01:05:22] **Aaron Gable**: And then idea that I wanted to ask whether it was already in the draft. I I haven't read the the drafts draft that you have. For revocation, are you talking about things like potentially extending adding an extension to existing CRLs that lets us revoke contiguous blocks of consecutive serials? Because that would be a really efficient way to mark, you know, whether a CA is getting rid of an entire log generation and moving on to the next log generation or whether they just had, like, oh, yeah. We had an incident for six hours and all certificates issued during that six hours need to be revoked. If you can put one CRL extension that says, please revoke everything in this range rather than putting a 100,000 entries in the CRL. That's a useful way to take advantage of consecutive serials.

[01:06:26] **John Gray**: Yeah. I mean, that I mean, we there's different ideas that have been bounced around. So one is, like, a batch signing, like, a a thousand at a time, for instance. Another one that I'd had a couple, what was it, two years ago. I mean, you have like one Merkle tree. I mean, we should probably talk because there's probably better ideas. And yeah, there's, it's an interesting space to think about, especially in terms of like, you know, between OCSP and CRL, I think there's probably an interesting middle ground where you can get the a system that's more efficient for both. And again, that would make sense for private PKIs because replication is important for private PKIs. So thanks. Thanks.

[01:07:03] **Stephen Farrell**: Back to Mike. Yep.

[01:07:08] **Omri**: Amari, Microsoft. To your point of sorry.

[01:07:12] **Stephen Farrell**: Hello? You you have to get real close.

[01:07:14] **Omri**: Sorry. To your point about software supply chain integrity

[01:07:18] **Jay**: Sorry.

[01:07:20] **Omri**: There's been some work that's been done in a working group called SCITT. And there is an RFC nine nine four three, and there's a COSE Receipts, RFC nine nine four two, The defined formats are already being used for this to some extent. Along the lines, the same lines using Merkle trees and transparency logs and so on.

[01:07:36] **Rich Salz**: So Okay.

[01:07:37] **Omri**: I don't know if you're aware of this or

[01:07:39] **John Gray**: Yeah. I wasn't. But, yeah. Okay. Have a good that's good. Thank you for that. Yeah. Sean?

[01:07:45] **Sean Turner**: Hi, Sean Turner. I just want to say I'm supportive of doing this work, because all the private PKI people that I talked to are like, what about me? Because everybody's like, the cool kids are doing that. When do I get to do that too? And so, this would be really great. I think the fun thing you're gonna have though is you're gonna have to figure out how to scope what you do Yeah. Because like, gonna, like, let's redo it all. Like, good luck. Don't don't do that,

[01:08:05] **David Benjamin**: I think, is the

[01:08:06] **Stephen Farrell**: Yeah.

[01:08:06] **John Gray**: So if anyone wants to be an RFC author or draft offer or work on this, like, there's I think there's a huge design space there.

[01:08:13] **Sean Turner**: Yeah. I can help you, but I don't necessarily need to be another one.

[01:08:16] **David Benjamin**: So You

[01:08:17] **Stephen Farrell**: might need a backhoe.

[01:08:18] **Dmitry Belyavsky**: Yeah.

[01:08:22] **John Gray**: Victor. Victor.

[01:08:23] **Victor Dukhovni**: Sure. I've given this problem some thought in the past. To me, this feels more like a trust anchor distribution problem than it is, you know, in real time, every application going out and hunting for landmarks. They just look to me like trust anchors that change a little bit more often than we're used to. And so because trust anchors today are often distributed as essentially operating system updates. Right? Infrequently, you get an update of your CA bundle, and they're updated centrally separate from the various applications that consume them. It also feels natural perhaps to think here about some sort of system wide service that manages these for you and APIs for that, so that applications don't end up in the business of having to know how to fetch these, needing to embed engines that know how to fetch these. Every application suddenly has an HTTP client inside it or whatever. Ideally, we should be able to get to a state where if we need to regularly, you know, make landmarks available outside of browsers, hopefully, we can design that in a plan like plan nine like manner where there's a local system service that does that for you, and you can just query it and obtain the most recent versions of all the things you need. I don't know if you've been thinking along these lines, but that's what kinda naively seems to be the the way I'd want this to go.

[01:09:53] **John Gray**: Yeah. I think we if I understood, I don't know if it was really a question, but what you were saying, is that's kind of the direction, like, for the landmark verification. Efficient we're trying to come up with efficient way to do that, right, at the local client and distribute those landmarks. So, yeah. Well, I think we've thought about some of those things. And we can talk more, Victor, too. If you have ideas, that would I'd love to hear them.

[01:10:20] **Stephen Farrell**: Okay. The queue is empty.

[01:10:22] **John Gray**: Thank you. Okay.

[01:10:31] **Tom Ritter**: Then clicking one button, finding a new button. Next up, measuring deployment characteristics by Nalini.

[01:10:52] **Brandon Sloane**: And we

[01:10:57] **Tom Ritter**: try to yeah. Yes. Clicker should be working. Take it away.

[01:11:06] **Nalini Elkins**: There we go. Okay. Alright. So this is from the point of view of large enterprises who have to use PKIs and, you know, deploy them and stuff. I'm talking about, like, the large financials, insurance company, and so forth. So such kind of organizations, they use certificates, I suppose, outside the the TLS handshake. What they use them for sometimes is as a part of forensic evidence to say that such and such a person hacked in or, you know, so on and so forth. So the question is, do we have everything we need? I mean, what do I do if I take this cert to the to the judge and it has a tree hash in it? I mean, really? So and what else I mean, don't get me wrong. I'm not saying that we don't wanna do this or anything, but how do we do it? What do we need to make this all work? There's all kinds of other things too, is a lot of times enterprises have lots of subject alternate names, SANs. And in fact, that's kind of one of the reasons I started looking at this too because I was thinking, I know, you know, this whole business about keys and signatures, how that might work in a non enterprise world or somebody who didn't have a bunch of SANs. But, like, lot lot of enterprises have SANs. I mean, it could be because, like, they might have, like, one thing that only the teensters get or something like that. Or they may have bought, like, five other banks, and they still have stuff with that. So that was another reason. And so I'll show you some numbers. I did some real real world monitoring of exactly what we've got here. So I guess that's that's one of the questions. Mean, those that whole thing, how do we do this? Do we have all the information that we're gonna need? And and if not, then how do we do it differently? I mean, how how do we do this? So for example, you may remember Stuxnet, and one of the forensic pieces of forensic evidence for Stuxnet was two x five zero nine certificates that were stolen, and that's how Windows trusted it. And clearly, they've since been revoked, but you can see this is a real world case of where certs were used. So what I did, I did real world monitoring. I took financials horizontally. That is, I took, like, 50 or so large US financials, about 40 or so large Indian financials, and then I think 40 or 50 in Latin America to see exactly what they were doing in terms of both PQC cam and also what their certs looked like. And then health care, I did it vertically. We have in The United States, we have private health care. And so private health care insurance, that is. We also have private health care. So so insurance I did vertically, the health care insurance hospitals, and then a lot of the government agencies that deal with health care, which is Medicare that's for older people, health and human services and so on. And the reason I did all this is because if a quantum computer were to be developed that was capable of breaking encryption, the kind of organizations that it would likely go after are organizations that are holding on to money and health care data, secrets, such like. And those are the kind of organizations that I am talking about. So one of the things I'll show you first is high PQC hybrid adoptions. And there's a tons of more data in the back of the presentation if you're interested, you know, TLS versions and so on. But you can see here, a lot of people talk that, you know, they say, oh, 67% of of organizations are doing p q c. Well, that's only true if you talk about the large Internet companies. I think you can put my right. Yeah. So one thing I measured is, like I can't do two things at once nor can I think and talk? Okay. Alright. So here's the Internet companies. That's about, like, 30 or 40 of the large Internet companies, you know, the Googles, Facebook, Amazon, etcetera. And, indeed, you can see that about 63% of them are doing PQC. But if you come to like, for example, the medicare and such like of the world, then we're only talking about 18% or like India, the Indian financials are at 23%. And and as I say in the back, you'll see even like folks who support only TLS one point two and one point one. But we're interested in CERT composition. And so this is this is of course clearly a pre MLDSA. And and I I only did MLDSA and one signature type. I didn't do I mean, there's I mean, we can do all kind of combinations. This is what I did. Okay. So because I was concerned. I was concerned about SANS and if what applied to the Internet companies applied to everyone else. And you can see basically for the Internet companies, we're talking probably about the currently, the other stuff, the metadata framing and so on is about 70%. And and it's maybe closer to 65% for others, which is not bad. Then clear if you if you use MLDSA 44, I just used MLDSA 44 signatures and keys, clearly that that range, you know, you you just have a much bigger cert. So okay. I mean, it looks terrible kind of. Right? I was like, this is bad. But then what I did is I just I looked at timings. This is the percent of the the handshake time that the cert transfer takes, cert transfer processing. And you'll see it's running about a quarter, about a quarter of the handshake. This is not MLDSA, about a quarter of the handshake. And then when you add MLDSA, again, it don't look so good, you know. It's like we're talking about 50% maybe. But if you just look at the actual absolute times, you know, we're talking about maybe a 150, 200 milliseconds. And so, you know, you know, now I'm starting to think, you know, I am lazy person. I'm thinking, well, how much work am I going to do for two hundred milliseconds? I don't know. I have to think. As I say, I am lazy person. So the other thing I did is I started looking at certificate chains because I thought, well, you know, maybe we have a way to optimize there. And you can see that probably about a third use three certificates. I mean I mean, two certificates, about 50% use three. And I do not know who is doing this four certificate business with two intermediates, but there we are. Because I was thinking to myself, well, I mean, you know, what if I get rid of one or two of those intermediates? I mean, did I buy myself back a hundred milliseconds, hundred and fifty milliseconds? I mean, you know, I don't know. I'm just saying. I'm just thinking out loud, thinking out loud. So one of the things that we need to do, I believe, is validate exactly how certs are used and what are they used for at these companies. And then I think the gentleman after has an MTC server. I really need to see what a cert looks like that's using MTC, and maybe we've got everything we need in that. But then, you know, I'm just I as I say, I'm just talking out loud. You know, maybe we don't need intermediate certs. No. I I don't you know, as I say as I say, I'm just putting out some putting out some issues. The other thing that I think is maybe a problem too is that in the enterprises is probably we're gonna have a bifurcated world. We're not gonna stop just just because we say for our enterprise servers, we don't wanna do you know, we'll we'll do the full certificate because we need, you know, the forensic logs, this, that, and the other carrying on. But if the browsers are doing it, we still have to deal with MTC and and what do we need and do we have our enterprise OIDs and all this kind of stuff that we've spent years developing. And then how's it gonna work at the CDNs and how much choice, you know, do we have? So yeah. So one of the things that we're thinking about doing is we'll definitely keep monitoring if you guys interesting. Let me know if there's anything else that you think we ought to monitor. And our nonprofit industry network technology council, we're thinking about putting up some more public test points for for MLDSA in particular, and I would love to have an MTC server. Anybody wanna help? Please. By all means. Love to have you. Yeah. That's it. Thoughts? Questions?

[01:22:22] **Devon O'Brien**: Devin? Devin O'Brien, Apple. Merkle tree certificates, if you squint at them, are a SIGALG and an X509 v three certificate. So I'm curious if you could there was a lot of questions about do we have x? Do we have y? Do we have z? What so I I I would try to flip the question. What is it that was there something removed that you you you care about from these things? Because there's there's still certificates. Like, I'm I'm trying to understand Right.

[01:22:53] **Nalini Elkins**: What you're What's missing?

[01:22:54] **Devon O'Brien**: Yeah. What's missing? So there's there's there's x 509 certificates. They have all the fields. There there are new signature algorithm within this, and most of the specification of MPC is defining issuance flows and the transparency logs and the cosignatures and the thing. And so there there there are different formats of things in here, but there's SANs and extensions and OIDs and things. And so I'm trying to, like, get to the thing you're concerned about. And the only thing I can kind of think about is possibly MTC ecosystem in reality would lead to a more femoral logging of things. Like, you you gave a Stuxnet example. And and the the other sort of, like, orthogonal access to this is NPCs are primarily gonna be deployed in in TLS certificates. They're like the the the value proposition of NPCs is a size gain with integrated transparency for interactive protocols. Right. Things like SMIME and code signing certificates don't have that intrinsic trade off here. True. And the the ecosystem is largely moving towards partitioned purpose specific PKIs. So I don't think the existence of MTCs affects that in any way. Or could you could you explain to me a way in which that could possibly affect these things?

[01:24:03] **Nalini Elkins**: Yeah. Yeah. No. No. I I totally get what you're saying. So let me go back to one thing. Let me go back to one thing. So this this Stuxnet example is is probably not a great example in this case because that was, as you say, signing.

[01:24:22] **John Gray**: Sure. Sure.

[01:24:22] **Devon O'Brien**: But let's pretend it's a TLS certificate that you care about.

[01:24:25] **Nalini Elkins**: So so we are we are caring about TLS.

[01:24:28] **Stephen Farrell**: Of course.

[01:24:28] **Nalini Elkins**: I mean, enterprises use TLS.

[01:24:31] **Devon O'Brien**: Of course. Yeah. What what are you worried about? I guess

[01:24:34] **Nalini Elkins**: what So what I'm worried about is that, for example, if there's a hacker or something, that certificate that came in and was verified and everything, that's part of the the chain of evidence that you take to the judge.

[01:24:53] **Devon O'Brien**: Are you saying that a hacker compromises a certification authority or hacker compromises a web server?

[01:24:58] **Nalini Elkins**: No. It's the whole TLS handshake and all of it together, you know, that's used, you know, to to go to the to the judge with.

[01:25:08] **Devon O'Brien**: So so I'm gonna interpret that as being you're concerned about the between the client and the web server, not the CA, not the issuance process, not

[01:25:17] **Nalini Elkins**: Well, yeah. Because I mean, right because because the question is, right now, we've got we've got the public key, you know, that's in there and the signature. And you can tie all that back directly to a CA and everything. But after MTC, my question is really what exactly do we have?

[01:25:41] **Devon O'Brien**: Same thing. Nothing. Same exact thing.

[01:25:45] **Nalini Elkins**: We have the public key and signature.

[01:25:47] **David Benjamin**: Yes.

[01:25:47] **Stephen Farrell**: Yes.

[01:25:48] **Nalini Elkins**: And so what have we saved in terms of the the handshake size here?

[01:25:53] **Devon O'Brien**: So the so there's a couple things that we've we save here in two categories. The first thing is is because they're flat hierarchies, you basically get what we would call today intermediate elision for free. You no longer have to transmit two certificate CA certificate the CA certificate in addition to the client certificate for a client to be able to build a trusted path. Now clients who do preloading and intermediate elision, there's there's there's multiple proposals that have been proposed here and elsewhere to sort of address that. So so there's a huge amount of savings of just not shipping another certificate down the train because they're trusted directly. The second thing is that, as I mentioned, NTCs are a x five zero nine v three certificate with a new signature algorithm. That's where the savings occurs within a single certificate. You have maybe 600 bytes of hashes. Standalone certificates are different, right? Those are just moving signatures around, but for the landmark level certificates, you just have a new signature algorithm that's a bunch of hashes that for which an inclusion proof to a trusted tree head serves that sort of purpose. But it's, for all intents and purposes, it's an x five zero nine v three certificate. It has everything you would ever put in a certificate. You could put a CRLDP, could you put certificate policies. You could put it you you can put AIA, OCSP, AIA's. You you you can do all of the things, and that was an intentional decision to slot MTCs into these. So these these aren't a wild, wild west kind of thing. The wild west aspect of MTCs is all of the things that it takes to get the transparency and the, like, landmark distribution out of band and then some some clever Merkle tree stuff inside of the signature algorithm. But if you just cover the signature algorithm, you're staring at an x five zero nine v three certificate more or less.

[01:27:31] **Nalini Elkins**: No. That's great. That's great. So are you saying that we're gonna have, like, if I see a certificate chain, we're liable to see fewer intermediates?

[01:27:40] **Devon O'Brien**: Intermediates. None.

[01:27:41] **Nalini Elkins**: No. No intermediates. I got my my hundred and fifty eight milliseconds back.

[01:27:46] **Victor Dukhovni**: Yeah.

[01:27:47] **Devon O'Brien**: Yeah. We browsers and clients care about that a lot as do CDNs, which was also a motivating factor. And if you go back to some of the earlier justifications for why plants exists at all, it's because moving to PQC introduced tens of kilobytes to handshakes, which leads to material failures, degradation of TLS, packet fragmentation, all of the failure modes, you know, these tldr dot fail like things. So I haven't seen a concern articulated in this that MTCs doesn't, that that that MTCs alides in a way that I would be concerned about, but maybe I'm not fully understanding.

[01:28:24] **Nalini Elkins**: No. No. No. I think it's it's a it's a lot of it is me not understanding how MTCs work. Mhmm. You know? But I'm gonna say that I'm not gonna be alone in not understanding it. And so maybe we need like a you know how they did a PQC terminology for for engineers, something like that? I mean, I just think I think we need more guidance. Maybe that's more it than anything else. Like, how is this gonna affect me? Because those are the questions that I was getting. It's like, hear we're doing this kind of stuff. I'm an enterprise x doing this. Do can I still do everything that I used to be able to do?

[01:29:07] **Devon O'Brien**: Yeah. I think I think there's there's two aspects of this. One, the design is still being iterated upon, and that form of guidance tends to come later. And secondly, I think that guidance may not exist because it doesn't change the status quo. I think we have an obligation to say where things are different, but there was a very intentional design decision to make this as slot into the existing x five zero nine world as possible. So that's sort of We need to wrap this.

[01:29:37] **Nalini Elkins**: Okay. Yeah. So Well,

[01:29:41] **Alizia Cario**: technically, I do have Alizia Cario Red Hat. I do have one thing that does actually make it slightly different in that you may have may see something that is looks like a signature, like it's in a place where there there is a signature. But to verify it, you need to have some kind of data that is normally external. So you need to have that landmark to which that landmark relative certificate has been created. Only then you are able to verify that signature. And that part is not part of the certificate, that the the CA certificate or the n a entity certificate. You need to have, like, some additional information to be able to verify that signature.

[01:30:24] **Nalini Elkins**: I I see. And so so the enterprise I I that means that's where, like, as this thing settles down, then then we need to come up with a, you know, like a deployment guide for people to say, you need to save this information or this is how you get it. Yeah. Thank you.

[01:30:41] **David Benjamin**: Mhmm.

[01:30:41] **Nalini Elkins**: Yeah. Great. So yeah. If people are interested, I can keep continuing to do measurements for when and how people are using MLDSA when they start, as I say, if that's of interest to people.

[01:30:59] **Bas Westerbaan**: Thank you for coming. I think it's an important thing that I haven't heard said explicitly. Oh, thank you. Thank you for coming. I think it hasn't been said yet as explicitly, but I think it's good to say. Merkle-two certificates is not for every use case. For the WebPKI, I think everyone agrees it's a lot of people agree that it's important. But for instance, in a lot of our own private PKIs at Cloudflare, we're just going with non MTC MLDSA because that will work fine enough in these specific use cases. And then somewhere, let's see what the data says. If the performance is valid, we'll use MTC. And I think it's really important that we have good guidance, and I was hoping that the I've envisioned that the draft that John was writing would also contain that, but this is really something we do need a good basic explanation, also guidance on when would you need this for your own private PKI or not. Yes.

[01:31:59] **Nalini Elkins**: Right.

[01:31:59] **Bas Westerbaan**: So thanks for

[01:32:00] **David Benjamin**: considering.

[01:32:00] **Nalini Elkins**: Yeah. Yeah. Yeah. No. That's a really important point is like, do you need this? But I mean and how do you and people but people I mean, some people again, browsers can do it anyway. So we need to understand what it is that you see in the browser even if the enterprise doesn't do it. Yeah. Thank you.

[01:32:17] **Stephen Farrell**: Thanks.

[01:32:31] **Tom Ritter**: Okay then. I think that also as part of the guidance, it will be very interesting to figure out if transparency can be brought to places where it wasn't before and what that will do for people's security. But that aside, we're now getting Alexander on stage who will be telling us a little bit about what happened at Acton. The floor is yours.

[01:33:03] **Alexander Bokovoy**: Thank you. Thank you for giving me this opportunity. This is not exactly the plant thing, but I was given an opportunity to give this talk here. So a camo is a new experiment, which is part of this research project that European Commission happened to fund this year, and Brett Hart is part of it. And it's heavy work in progress. What it tries to do is modernize how we deal with certificate issuance and distribution in private enterprise environments with FreeIPA, which many people call, like, active directory for Linux, which is not exactly correct name, but gives you a feeling of what it tries to to do. And certificates are often used for non TLS cases there as well as TLS ones. And so it's open source. The Acamo itself is on the g p l v three, but the stack that that we build is under MIT and Apache tool licenses. And it all started with an attempt to do the ASN one from scratch. You know, this is famous last words. And using agentic tools. So we build up the infrastructure and all is code generated and then everything is built on top of it. And it does a lot of parsing and verification that exposes this to Rust and Python applications. I come up doesn't do Python stuff. It's only Rust, but yeah. So for the hackathon, the hope was to maybe do some Merkle-three certificate implementations interrupt testing, but unfortunately, there were none at the hackathon. So we did ACMA interrupt with Corey Bonnell remotely with his upcoming ACMA client. And Corey found few issues and I fixed them. So, hopefully, the interrupt could go there. We preliminary tested with and Seroport and so on, and things work it. So some clients are more detailed have more detailed attention to the RFC statements than the others, and that's kind of the purpose of interrupt testing. And then I did also some agentic review of, like, statement by statement from RFCs, how the code stands towards the meaning of those, which is hard to do, but at least this is now possible to do with agentic tools and have a pull requests that try to address some of the minor statements. Generally, this is working well. On the Merkle three certificate support, so I started with the draft two and then gradually went over months to current draft state. So it supports draft five. There were a few things missing in the t log format, so that's what was done over this weekend. And most of the time was spent talking with David and others about the future of MTCs, how to use them in the private enterprise setups with the private PKIs and so on. And also what the value of using trust anchor IDs in old classic and MTC environments. I think it's a really good improvement on both distribution point and and making the clients and servers to tune to each other. We also ran few experiments with the contributors that tried to use the infrastructure that that was built to see how this is extensible. So one of the things was to add FNDSA certificate issues while using still using the open SSL stack, which doesn't have FNDSA support. So we were successful in making the use of Rust based Aurora framework to plug in the FNDSA implementation and then successfully issue actually do cross sign in with the FNDSA issued certificates through a camel in, like, half a day. The one thing that I try to do is improve on the visualization of what MTCs are in the actual CA interfaces. So this is kind of an example of where we don't show really a tree. We show a timeline of issuance and reworking and so on. And that's probably doesn't scale well if you'd start doing millions of certificates per year and so on. But for the private enterprises, it might be good to show something like that to the administrators and allow moving as a scope across that line to to give something. But, again, this is this is the result of the hackathon. It's not the final point. I think it's worth looking not only at how we technically implement things, but also how usability of of these thing towards the users would look like. And that's effectively all I have. Thank you.

[01:40:12] **Stephen Farrell**: Any questions? Okay. Thanks.

[01:40:23] **Tom Ritter**: Thank you for the presentation. I invited Alexander to give this update, what they've been up to, basically, also as an opportunity to remind people that the hackathon exists And if people working on implementations of anything MTC related, the hackathon is a great opportunity to get people that work on the same kind of stuff together and see if your tools are actually interoperable, which will also certainly help with, like, getting RFCs done, etcetera. Inevitably, the IESG is gonna ask, did people actually implement this? And then you can say yes, which is great. That brings us to the end of today's scheduled program. So this is the point where I ask people if they have any other business or forever hold your silence.

[01:41:22] **Stephen Farrell**: I don't see anybody running to the mic.

[01:41:26] **Tom Ritter**: Then I think we'll see each other on the mailing list.

[01:41:30] **Stephen Farrell**: Alright. Thank you all, and we're gonna break a few minutes early. Thank you.

[01:41:36] **Tom Ritter**: Bye, everyone. Enjoy the Internet.

[01:41:45] **Stephen Farrell**: I'm sorry?