Session Date/Time: 16 Mar 2026 08:30
This is a complete verbatim transcript of the PLANTS working group meeting at IETF 125.
Tom Ritter: Okay, I think we're firmly at time. So, what do you think, Russ? Let's get started.
Russ Housley: Absolutely, let's go.
Tom Ritter: Well, welcome to the first official PLANTS working group meeting here at IETF 125, wherever you are. Obviously, this session is being recorded, not just for the Meetecho staff that allows us to bring me to you over this video screen, but also this will be posted on things like YouTube, I believe.
In the IETF, we have this thing that's called the Note Well, which means that you need to take note of this really well, which means that you agree by being here that you're following the IETF guidelines for professional conduct, i.e., be nice to people. We are talking about people's ideas, not people's identities or person. And if there is someone that is not behaving accordingly, please reach out to the chairs or the ombuds team.
There's the rules around IPR, so if there's anything that's covered by a patent or a patent application that is either by you or by your employer or anyone who's paying you to be here, then you need to disclose that or keep your mouth shut, both on the mailing list and in this meeting. And that is I think the most important stuff that I need to say here. Of course, there's a full version of this that you can find by scanning this QR code.
Also useful is that if you're in person, please sign in to the data tracker. There's a bunch of QR codes posted around the room, and what this helps us do is that when there's a next meeting in the next location, they will make sure that they don't put us in a broom closet because only five of you said that they were present and then the scheduling team says, "Oh, PLANTS is only five people, so we can put them in the broom closet." So, please sign in. You can also use that to join the queue when you want to ask questions. If you are not in the queue, we will not let you ask a question.
Remote participants similarly use the tool that you're viewing this on right now when you want to send voice or video, but please get in the queue first. And for those that will be presenting, we can give you control over the slides via the same tool. And for everyone, please—although for the people that are remote, their names will be nicely written down in the system—it's still nice to state your name so that the people taking notes and also EchoBot will have that context.
There's a bunch of links, but I think that's more or less useful for after the fact. Yeah, we're underway.
We have a charter now. There was extensive discussion on that on the mailing list. Unfortunately, some plant puns had to be trimmed, but that is the nature of things. Unfortunately, sometimes you have to let business come in front of fun. But we will have committed to delivering two documents per our charter. One of these is the more or less the actual Merkle Tree Certificates system draft (draft-ietf-plants-merkle-tree-certs), but in front of that actually is a deliverable that describes the architecture, etc., for these logs that are based on transparency stuff like that. That work has not really started yet, but the first discussions on how to spin that out of the existing drafts have been happening on the mailing list.
So, yeah, that's I think the most important thing to say on the charter. For the other thing is that the draft that was sort of the center of the BoF and everything has now been adopted as an official working item, and thus is now with working group control rather than the authors. So that's also exciting. Anything to add, Russ?
Russ Housley: Perfect.
Tom Ritter: Moving on, we have the agenda for today. We have this, the introduction. Then I'm quickly going to open up a—well, start with what the options are and then very quickly bring up the fact that we have to make a collective decision on how to interact with GitHub. I say collective, but the chairs have a big say in this, a little bit more than the average participant. Then there's a document update on the recently adopted draft (draft-ietf-plants-merkle-tree-certs) by David Benjamin. Brendan McMillian has put together some slides on monitoring issues and what we can do with that, maybe improve the draft in some way. Then we'll see some reporting from Chrome and Cloudflare, and Filippo Valsorda has graciously offered to help clarify some how MTC can work in varying settings for the PKI. And that is it for this set of slides. So, unless anyone has anything for the agenda, for which now is the time to speak up. Going once, going twice.
GitHub. Yes, I do want to move to the next deck. So, GitHub. There's this draft that was written a number of years ago that has the helpful title of "Working Group GitHub Usage Guidance," a set of guidelines for working groups that choose to use GitHub. We rolled into this sort of by default because the authors of the Merkle Tree Certificates draft were using GitHub, but now we're a real boy working group, we need to actually make a decision on this.
So there's this nice bit of text that says that working groups—the chairs are responsible for determining how a working group best gets their stuff over the line and that we should talk to the area directors on how to do this. So we will definitely be getting in touch with Deb here as well. But more or less this document, so the RFC, lines out three different approaches.
One of them is just the document lives on GitHub and is GitHub is used for change control, but other than that any sort of discussion on "how do we do this, how do we do that" will be resolved on the mailing list or face-to-face in meetings such as this one, which has the upside of maybe things getting in more people's inboxes, but the downside of maybe being a little bit more clunky than other approaches.
The issue tracking mode is basically the authors create issues and fix small things on GitHub, but anything substantive must be resolved exclusively on the mailing list.
And finally, the issue discussion mode is more or less you can just do triage of basically anything on GitHub, although it's still very much encouraged to bring substantial discussion points to the mailing list, even if that is just "we're discussing this item here with option X and option Y, the discussion is over here on GitHub," that sort of thing would still need to happen.
But yeah, those are the options. We have a GitHub organization, so that is where things will end up being, but for now it's not been set up by the IETF Secretariat yet, so I need to poke them again on this. But once it's set up, that will get like the Note Well in place and stuff like that. I also think we want those summary emails on things that have happened.
Following other working groups, I'm proposing that we do the issue discussion mode, so substantive technical matters will be allowed to be discussed on these GitHub issues. I think that that is fine, but of course this is the time for people to weigh in if they have another opinion about this or support this. And we will be confirming this on the list and the ADs before we actually set things in motion in this way. So, everything clear?
Russ Housley: I guess the real question is, does anyone object to this direction? Seeing nothing in the chat and no one getting in the... okay, go ahead Mike.
Mike: Um, yeah, I like GitHub. GitHub is great. I do think the list gets more attention. It's easier to sign up for a list than it is to sign up for, like, if you want to be notified when there's new stuff, it's easier to sign up for the mailing list than it is to sign up for like individual GitHub issue watcher things. So, like, I mean I love long discussions on GitHub, they thread nicely and blah blah blah, but I do think we need to be coming back to the mailing list to let the mailing list know that a discussion is happening on GitHub so that people who want to be involved can be involved.
Russ Housley: Okay, any other concerns? And we'll be asking the authors to bring big decision points or summarize those long threads as you described them back to the list.
Tom Ritter: Yeah, I think that that is also part of the trade-off with this is that the chairs of the working group will also need to be watching that this is actually happening.
Okay, then, next deck. David Benjamin, the first official working group draft update. Let me try to give you the slides somehow. I think you need to press a button to request that.
David Benjamin: Oh boy. I see request screen share... oh request slides.
Tom Ritter: You can, all you have to do is next to David Benjamin's name is a little piece of paper with a plus sign in it. If you click that, it'll give him control of the slides.
David Benjamin: Oh, yeah. Excellent. I was looking at his video screen which had some buttons but not all buttons. Many buttons. There are many, many buttons. For sure. Take it away, David.
David Benjamin: All right, let's see how this works. Um, yeah, so I'm here with a document update and no plant puns whatsoever, and we'll see if advancing the slides works. It does. Great. All right, we have a draft (draft-ietf-plants-merkle-tree-certs). I think I can speak for all of the authors that we're really excited to see how far this has grown. So now what? Well, we got to get to work. A few topics to go over, most of which hopefully you've all seen on the mailing list, but seems worth going over them here.
There's a draft 02. The main—the only real differences between that and what was adopted are we had a discussion about what to rename the really terrible terms that I started with, and there were a lot of options in discussion, but the option that folks seemed to most either prefer or be happy with was to turn "full certificate" into "standalone certificate" and "signatureless" into "landmark certificate." I've started using these terms and they seem to work pretty well in context, but if I've read folks' opinions wrong, please holler and we can go rename them.
And the other change is that there was a thread about putting public key types in the certificate log entry. There wasn't a whole lot of discussion, but everyone who said things either on or off list was in favor, so we have gone ahead and done that. But if you disagree, please holler.
All right, now onto the architecture document. We said in the charter we're going to write an architecture document and then we adopted one jumbo document. So we got to go do something with that. I think other than, you know, finding the right way to split the document up, I think this is a good opportunity to clarify the kinds of applications where this work is or isn't applicable, and also sort of where this fits into a broader story around log transparency and such. Filippo has a great talk coming up about the first one, so I'm just going to talk about the second one. And for that, I'm going to go on a whirlwind summary of what has happened with CT since that has caused a bit of confusion from talking with folks.
So CT started with RFC 6962. I don't think we knew it at the time, but it actually has turned out to be two fairly independent suites of protocols. You've got the sort of structure of the log, the format of the log entries, and the log artifacts that go into X.509 certs or SCTs inside them, how you use them in a protocol like TLS or something else. This sort of impacts your day-to-day interaction with CT. And then you've got like the stuff that happens asynchronously in the background: how monitors see the log, any kind of auditing schemes that clients might do asynchronously and things like that.
And these two suites turn out to be fairly independent. The log artifacts don't really care how the log is being served; it's just like we kind of hope it's available in the background somehow, but you're not actually—it's not going to impact directly using it. And conversely, the serving stack doesn't care too much about the details of the log application. A lot of the sort of stuff that you do around monitoring and such is pretty independent; it doesn't even care what the format of the entry is, it just needs to be able to process them in some way.
And a lot of CT evolution has kind of reflected this split, with the exception of this first step where we did an update of 6962 to 9162 and it didn't really get deployed in practice. It turned out the kinds of problems that we were trying to solve in 9162 and the ones that were interesting for the ecosystem ended up diverging so, well.
Then the next thing that happened was the so-called static CT API. And this replaced the sort of log interface with a different API that is more scalable and low-cost than 6962 or 9162. Structurally, 9162 and 6962 asked for the server—the log server—to dynamically construct all these proofs, which made them not very friendly for things like caches and all kinds of stuff. And this new one is a bunch of immutable cacheable files, which you know, works a lot better with folks' server architectures.
This is part of this like whole suite of Tlog work that gives you not just sort of serving APIs but also stuff for like mirroring and witnessing the log and all kinds of cool stuff that is happening there. And the nice thing is that we were able to do that without changing the core part of 6962 that protocols actually interact with because, again, the protocol parts don't really care how they're being—how the log is being served or anything that happens asynchronously behind the scenes.
And the sort of Tlog suite of stuff is independent of what the log application is. In fact, there's a couple of different log applications that all use this same infrastructure. I think the Go module database is one of them, and Filippo probably knows all the other ones; I'm not quite as plugged into that. So this was a nice sort of artifact of doing this split that one side could sort of be evolved while keeping 6962 unchanged and without having to cycle the ecosystem.
Well, so if we change the right half with static CT API, Merkle Tree Certificates is changing the left half. We improved the log entries to scale to post-quantum better, we changed the way that the log artifacts are used in certificates in this interesting way with cosigners. That structure was actually inspired by some of the stuff in Tlog, but it's not directly using it. It's sort of intended to be compatible with it, but you don't have to use Tlog if you want to use Merkle Tree Certificates, so it's sort of like a standalone thing on its own.
But you know, if you want to build a sort like within the context of a larger system that wants to use all of this stuff, like, you probably do care about either Tlog itself or something in that shape. And so the proposal is the architecture draft probably wants to give sort of this like rough overview of what's going on, kind of a non-normative overview of like the kinds of things that are available and say, like, okay, so this is where this work fits in. You can use it with this stuff if you want to. You can use it with something else. Maybe if you're in like a private PKI and you only care about batch signing, then you don't actually want to serve the log at all, in which case none of this sort of the yellow box matters to you at all. But as part of a helping understand how this system works, it seems useful to talk about it more.
And then, you know, we need to actually like split apart the document. I started some discussion on the list and in the GitHub, which I guess we'll sort of sort out with the new GitHub working mode. And I guess, you know, folks who have opinions on what should go in what, please go holler and then someone will go do the work of splitting them up so there's concrete text for the working group to consider. I suspect if no one else volunteers, the authors will jump on that hand grenade, but you know, don't let me stop you. Yeah.
All right. And then next topic, I'll try to be a little brief because I made way too many slides as usual, is sort of ACME and TLS integrations, which is also mentioned in our charter somewhere. The MTC draft is a little interesting in that for a single issuance event, it produces not one but two certificates. There's sort of the standalone certificate is the one you sort of expect, and then the landmark certificate is this optional weird one that needs to somehow get from the CA to the servers. And so protocols like ACME will need some way to like smush it in.
And this has some interesting properties. The landmark cert isn't available until a delay, even though it's part of the same issuance event. But we don't want to like delay the whole order processing; otherwise, we'll delay the main certificate and that was—and we want the main certificate to come in immediately after the standalone certificate. And we also need to attach whatever metadata ends up being needed to help the server decide—help whoever's presenting the certificate decide which one to use. The draft has sort of an initial proposal buried in a section somewhere, and I've forwarded some stuff to the ACME list to go discuss there. And so I think there's like a thread on each list that folks can go join.
Speaking of certificate selection, the other funny thing about landmark certs is they are not usable by all relying parties. So somehow the relying party state needs to get communicated to the serving—the server or whoever's serving the certificate so you can select which one. And this needs to happen robustly. The relying party might have different state for CA. You might have some CA be temporary unavailable. It would be really bad if like one CA cannot be accessible, suddenly this optimization breaks for all CAs. You don't really want those kinds of things in a widely distributed system.
So you can kind of model this. Fortunately, there's some work in the TLS working group that fits this exactly, not entirely a coincidence. You can model a landmark as kind of a funny trust anchor which matches just this little subset of certificates. The IDs we have over in TLS are based on OIDs, so you can just append a number. This is also not a coincidence. And then, yeah, that ends up just working. There's a change we can make that was actually originally in the plan but we like took it out of the trust anchor IDs draft because it was a little hard to motivate until this work got off the ground, which is to encode in the system the fact that if the client knows this landmark, it also knows all the previous ones. There's a typo on the slide; I should also have a dot 399 in there. Started discussion on the TLS list and also there's a pointer to it around the PLANTS list, so go join them, have fun.
All right. Some stuff that happens in this working group. We've got log generations. I think Joe started a thread about this recently. So the current design roughly looks like one CA instance is one updatable rotation, cosigner key, and also one issuance log. In log generations, the idea is that we switch it so that you can have N issuance logs for some CA. Why do this?
For Merkle Tree Certificates deployment that uses cosigners, we have a lot of new failure modes that we have to go deal with. An MTC CA signature commits to the state of the log, and then those the cosigners will take those commitments and and lock onto them and not let the CA not move backwards from them. But the CA might accidentally make a bad commitment because, you know, it had a bit flip or you know restarted its database and something went back—something went wrong. It might commit to two versions of some checkpoint, and then some cosigners are locked onto one branch and some cosigners are locked onto the other branch. It might commit to an impossible checkpoint where pre-images are not known, and then it really really is sad.
And all of these failures break the assumptions behind transparency that there is a sort of globally consistent view of the log. So it is kind of by design that the cosigners lock the CA out of doing anything. But when that happens, we need to also think about how what's the impact to sort of the broader PKI. And generally, when in an incident like when when you have an incident in a PKI, if a CA instance has done something irreparably broken, you need to stop trusting that CA instance and move onto another. If it was just an issue within one particular piece of infrastructure and you still trust the CA operator, maybe it's a different CA instance for the same operator. If you no longer trust the operator, maybe it's a different operator, and so on. Still CA stuff.
And then whatever changes you make, those—that needs to reconfigure the relying parties. But sort of by construction, any relying parties that haven't gotten the update are not going to take the changed behavior. And servers often need to serve both the old and the new ones. If the old ones only trust the old CA instance, you have to do something interesting. In X.509 today, the old CA when it goes wrong is still functional; like, it can still call the sign function on its key. New relying parties might not trust it, but it is able to generate signatures to make old relying parties happy if that is a thing you need to do.
With these new failure modes, the CA is stuck and maybe unable to issue because it cannot get cosigned sufficiently to make the old relying parties happy and now the servers that need to serve both old and new ones are very very sad. So how do we fix this?
Well, in general, what you need to do when you like recover from an incident in PKI, you want to get the up-to-date relying parties to be servable and also secure, so we need to like update them past whatever broken state they're in. And the up-to-date relying parties—I mean, ideally we'd also keep them secure, but if we absolutely can't, the one thing that we need to make sure is that they can still be served. And right now we've broken that.
So how do we fix this? Well, let's give the CAs a way mechanically to move on from broken logs. Instead of saying a CA is one log, it's a sequence of numbered logs with single shared cosigner. So before the issuer field of the certificate identified a single log because that's what a CA was, and then the serial number identified an index within that log. And now instead, the signature—the issuer identifies a sequence of logs and then the serial number now needs to tell you both what log it's in and what entry it's in. We can just sort of encode it in like a tuple in, you know, your favorite encoding.
And so, you know, that lets the CA recover, but now we need to go back and make sure our transparency goals are still satisfied. And in particular, we need to ensure that whatever generations—log generations—the relying parties accept, the monitors will still see it. And sort of a priori, that is a little difficult because the CA now might just go mint a new generation for every single certificate, and now this defeats the entire purpose of all of these trees and we lose all of the like efficiency things the—the efficiency gains on the monitoring side the tree gave you.
But this seems to be solvable. We have sort of a range of options from like we can kind of really trust the cosigners and just say, okay, the RPs they'll accept all the generations and we're just going to assume that like a quorum of trusted cosigners and the monitors will coordinate and we trust the cosigners are not like doing anything sketchy. We could have the RPs enforce sort of a maximum generation number. As soon as they do that, then the monitors can key on that rather than the state of the cosigners. But then, you know, as the CAs have their incidents, then they need to update that. Older relying parties won't have this. We could have the older relying parties shut off enforcement, which is a little bit scary, but it is something that the CT ecosystem does today, so it's not totally unheard of. Or maybe we can say that like, eh, 64 is more than enough for anyone; no CA is going to screw up 64 times in its lifetime. That's probably good enough, and then, you know, you just sort of say, dear monitors, please look at all 64 of them, I'm sorry.
The good news is, whatever sort of point in this spectrum we—like a deployment ends up picking, it doesn't actually change the certificate wire format. This is just sort of a local decision on like whether what the RP trusts and like what the sort of CA can get away with. And so the proposal is let's go spec the sort of certificate format and then leave room for deployments either afterwards or in the experiment phase to sort of iterate on that strategy so we sort of have a better sense of how this will work.
Yeah, okay. I'm also going a mile a minute, so if folks have questions, feel free to interrupt me, but otherwise I will sort of keep babbling.
There's another thread about—oh, Victor's in the queue.
Viktor Dukhovni: Um, sure. Um, what happens if there are no cosigners, right? If I'm one of these relying parties who just, you know, works with the CA exclusively.
David Benjamin: Yeah, so if you—if you trust the CA exclusively then—then none of this matters. Like you—the—the CA at least at a technical level is able to reset its state whenever it feels like it. Um, so then—then we sort of don't really have any new failure modes in terms of like instant recovery. The—the sort of locking behavior only happens if you have an independent cosigner that you're required to like keep the thing going forward. And the reason that makes incident recovery hard is that in order to recover without changing the protocol, we would have to tell the CA, okay, hold your horses for like the next week you're not going to be able to issue certs so we need to go talk to all the like cosigners and be like, please reset your state. We know that like condition of you being trusted was that you weren't going to reset your state, but we're going to forgive that now this time, please go reset it so the ecosystem doesn't melt down and like that's a disaster. Um, so—but yeah, if it's all within one party then this doesn't move.
Hopefully that answered the question. It seemed that it did. Viktor's no longer in the queue.
Okay, so another thing is we need some way to represent a CA. X.509 sort of did not really bother defining a trust anchor format and so everyone used the self-signed cert instead. And for better or worse, there are a lot of existing applications that do this. And you know, if you're—if you're like a very fancy RP that's doing all kinds of stuff, you can just design a better format. Like this is ultimately application-local configuration and so it doesn't really matter.
But given that there is a long tail of clients out there, like command-line tools on random, you know, machines and whatever else, that are all based around like being able to find root certs as certificates in this like one directory on their Linux system or whatever, um, it would be useful if we had a format for this. Um, the draft has kind of a to-do and we should go do something about it. At minimum, we should probably make sure that the there's some format that satisfies a non-transparency enforcing standalone certificate-only relying party, because like the—the sort of analogous relying parties today are generally not enforcing CT and like they probably do not have like a yet some pipe to like pick up like up-to-date revocation information or whatever else they're doing. And we need to encode this is a Merkle Tree Certificates CA, please don't do the other thing. Information for the cosigner, signature algorithm, and possibly some bounds on the like generation number and entry index, possibly.
So broadly we have kind of two directions we could go here. Um, we could leave the SPKIs as is and stick the cosigner keys in there and stick anything else in kind of like a critical extension. Um, this means that we have this one extension on the side which changes the kind of signature the SPKI makes, which is a little weird, but you know maybe okay. And it does seem that relying parties use trust anchor extensions, which is mostly fine, but because X.509 never really defined a trust anchor format, like things vary widely on whether you believe that the self-signed cert is a like dummy container for just the name and the key or whether it's like a whole cert in its own right.
The other direction we could go is we can say, okay, well, because of the funny signature algorithm this means we have a funny key, and what is a key? Well, it's the information about a cosigner. So we've got like all this stuff and we just jam it in the SPKI under a new type. This is I guess this this sort of fits the like new signature algorithm model, but it means you've got this like two-level SPKI where the SPKI's body actually contains another SPKI, which is a little bit odd. Um, and I guess we might need to define a similar two-level PKCS8 format and sure. Um, I don't have much of a horse in this race, so I guess folks who have opinions could should make them known.
Yeah, all right. And then looking further ahead, um, there's an issue in the tracker from before adoption that we should probably be a little bit more opinionated about our ID allocation. Right now we're just like, yeah, all these things get different IDs, if you're a CA you should pick like 7 or 40 or something only 2.
Um, that was mostly because at the time we were like, we're not quite sure what the structure of things are. Um, you know, log generations will change this a bunch as we sort of figure out what the structure is. Um, I think we should be more opinionated in either um—either like prescribe an allocation or like strongly recommend an allocation method just so it's a lot easier for folks to set these things up.
There's a whole lot more to say about how to actually transition to PQ. Um, for specifically sort of the browser world, there's this document here that is not like directly related to Merkle Tree Certificates but since I imagine a lot of folks here are like interested in doing PQ transitions, I thought I'd mention it here.
And kind of like future thing that isn't like blocking sort of our minimum deployment, it would be nice to have some kind of negotiation for cosigners so that when you have to use the standalone certs, the servers don't have to send all the cosignatures and waste a bunch of bytes. Um, this could be useful to help the analog of what will become the—the analog of the CT ecosystem today, if I bit. Um, every CT enforcing client today has to show up enforcement if it doesn't get updates in 10 weeks, um, which works because there are not a whole lot of them and we all coordinate on like, "This is how we're going to evolve the ecosystem," but we have to do that because otherwise we cannot cycle logs in and out very well. Um, hopefully MTCs will make some of the cycling less dramatic, but given that we are talking about like which servers are trusted, that will always like need to happen, and so having some release valve for like you can collect extra cosignatures and not pay for them on the wire will be very useful.
And I got to fill my plant pun quota, so here's a plant pun for you. Any questions?
I think that plant pun might have been too encrypted for most people. Well, apparently you were very clear.
David Benjamin: All right, great. That that that never happens.
Viktor Dukhovni: Right. I just want to get a better sense of the immediate priorities. You know, so you laid out priorities on various time scales, but what really should be happening now, in your view?
David Benjamin: Um, I think probably roughly the order of what was in—let me go back to the table of contents so I remember the order I put in there. I think this is probably roughly... so we we need to get things going on the architecture document just because that's like a thing we put in the charter. I think getting to—getting on the same page with log generations is probably the next big big thing because that sort of changes structurally what a CA is. I think at that point we should be it should be pretty easy to represent a CA and probably also fix up the ID allocation stuff. And then the ACME TLS connections can probably sort of happen orthogonally. Um, yeah, so I guess maybe move ACME TLS to the end of the list. Otherwise, that was probably the order in which to do things and anything at the end of that unless there's other exciting things. This seems to be what to do.
Russ Housley: Okay, people seem to be happy with that. The queue's empty, so I guess we're ready for the next presentation.
Tom Ritter: So Tom, click on your own little document thing to take control back from David Benjamin. And then you can close this briefing. Or, yeah, I don't know, however that worked. I'm too tired for this. Yeah. You get Dieder in the queue. Why is Dieder in the queue? Oh, wait. Monitoring.
Deirdre Connolly: Can you hear me? We can hear you. Yeah, okay good. We weren't sure.
Um, do we need to start whipping up some documents for TLS and LAMPS to encode the using of any of these types of Merkle Tree Certificates? Or all? I know there are some, you know, prototypes working in certain places, but I feel like we all need to plug them into TLS in some fashion and we need—this is in LAMPS, oh sorry, this is PLANTS, but it feels like there will eventually need to be a LAMPS document as well. Yes?
Tom Ritter: I don't know exactly how change control there works, on what pieces of LAMPS we can sort of plug into and what not. Russ probably has a better idea of that.
Russ Housley: Well, I'd like to hear David's answer.
David Benjamin: Sorry, I wasn't sure whether this was a like question that I was supposed to answer or the chairs were supposed to answer so I was like "Uh, oh." I guess...
Deirdre Connolly: It just seems while we're prototyping and iterating, there do seem to be points in these other areas that we eventually need to inject into. And they might just be a "I support Merkle Tree Certificates, here's the codepoint in TLS" or vice versa in LAMPS. So I just wanted to flag that as like, maybe we should just start. Do we need to?
David Benjamin: Yeah. Well, I guess that was sort of why I started those threads already. Um, I guess I didn't start a LAMPS one. Um, I figured, I mean, like, Russ you should definitely tell me otherwise if like if you think this is not the right way to go about it, but I figured that the the X.509 connections are sort of like, okay, we'll define a signature algorithm and stick it in there, and so probably that would stay in this working group, but we would like go tell LAMPS "Hey, we're doing this, tell us if you think this is a horrible encoding" rather than having a separate document.
For the TLS stuff, the like trust anchor IDs sort of fits this already pretty nicely. I think the the one extension is not—is not Merkle Tree Certificates-specific; it's just sort of much clearer why it's useful. And so my plan was to get that put back into that existing TLS document. Um, on the ACME side, I think there's some catching up on that discussion, but there's some discussion going on now. Um, I figured naively that like if it turns out to be a like very simple "Yeah, use this existing feature this way, maybe send this HTTP header," then probably we can just put it in here, and if it's something bigger then put it over there depending on whether or not the ACME folks think that is also reasonable.
Deirdre Connolly: Okay. Just wanted to flag it like if we realize we can't—like trust anchor IDs might be insufficient to negotiate like "Yes, I support Merkle Tree Certificates that trust ML-DSA standalone or whatever," it smells to me that we might need to serve up new documents that touch TLS to communicate that sort of stuff. On the connection level, not the trust level.
David Benjamin: Yeah, I don't think—so we shouldn't need to negotiate like different flavors of Merkle Tree Certificates because it turn—the negotiating by algorithm is kind of like—like while TLS does have a way to negotiate by cert signature algorithm, it is basically never used because it's kind of insufficient. Um, it like knowing that you support this ECDSA CA—like knowing that your X.509 stack is able to verify ECDSA signatures does not tell you that you support this ECDSA or this ML-DSA CA. And conversely, once you know that you support this CA, you could infer that you know you could support the algorithm that CA needs. So...
Deirdre Connolly: Okay. Then we might be fine for the indefinite foreseeable future.
David Benjamin: That was the intention, but you know.
Tom Ritter: So I think what we need to do is when the documents are like getting close to working group last call, we just let the other lists that are affected know so they can weigh in on the last call.
Okay, then. Brendan, why don't you go now.
Brendan McMillian: Okay. Can you hear me okay? Perfect. Okay. Well, my name is Brendan and I'm going to talk about server monitoring. Um, and I think to frame this topic, for me it helps to think about what is the security guarantee that we want Merkle Tree Certificates as a whole to provide. And I think that at a high level, what we want is for browsers to know that they're not accepting misissued certificates. Um, but of course, a browser doesn't know on their own whether or not a certificate is misissued, so what browsers do when they interact with a Merkle Tree Certificate is really they're asking, "How do I know that the certificate is published somewhere?" And the draft (draft-ietf-plants-merkle-tree-certs) describes sort of proof structures and information that is provided to browsers to convince them that certificates are actually published. And that's good, but it doesn't totally get you what you want, so there's a second step as well, which is where a site operator comes online and goes to wherever the certificates are published and asks, "Hey, what certificates exist for my website?" They can then go through all of the certificates and they can check if anything was issued without their knowledge or without their permission, and if they find something they can be mad about it or try to revoke it or something like that.
Um, now unlike the browser portion, where we're proving the certificate is published, this part is not actually specified in the draft and the plan is basically to leave it for future work. That said, even though it's not being specified right now, the security of the whole system still depends on both of these parts equally. And that's because, you know, you can attack the browser side and you can try and convince a browser that a certificate is published when it really isn't, or you can attack the site operator side and try to prevent a site operator from learning about a malicious certificate. Uh, but both of those are equally valid and they both have the same outcome, which is that you get a certificate that the site operator doesn't know about.
Um, and so it makes sense to ask, you know, why are both of these different portions of the system secure? And so starting with the browser portion, why is the browser portion secure? Well, it's secure because when we give the browser a certificate, we also give it this inclusion proof in a transparency log. Well, okay, how do we know that I'm showing you the same transparency log as everyone else? Well, because the root hash is cosigned. Why is that cosigner trustworthy? From the browser's perspective, the cosigner is trustworthy because its public key is like hard-coded in the source code, and so that's a pretty compelling reason to say that something is trustworthy. Um, but essentially what we have here is—is collusion security, so this is secure as long as the transparency log and the cosigners don't collude to try and trick the browser into thinking that something is published when it actually isn't. And so that's pretty straightforward.
And then moving on to the site operator portion, we can also ask why this is secure. And the answer obviously depends on how we intend to fill in this like "to be determined" portion of the system. Um, in CT originally, the idea was always that site operators would just download the whole log and they would filter out the things that were relevant to them and look through all of that. Uh, we know now that that is way too inefficient, both for the site operator and for the transparency log. So site operators are just not going to download that much data. Uh, but also like the transparency log like just doesn't have enough bandwidth for a significant portion of site operators to download all of that data from them. Like they just don't have that much bandwidth.
So okay, so what if instead of that, we have some kind of service, like a third-party monitor that downloads the log for us and a bunch of other site operators and it just emails us if it sees something related to our website? And this is in practice how CT actually works today, where basically everyone uses a monitoring service, and the security of this basically just comes from trusting the monitor to be honest and to provide their service the way they say that they're going to do it.
Um, and so given that, if we take a step back and ask, if this is our system, what's the security of our whole system? Uh, this is the answer that we get. So if we say that a successful attack is getting a misissued certificate without the site operator knowing, what has to happen is that a certificate authority has to misbehave to misissue that certificate, and then either a quorum of cosigners have to misbehave and sign some kind of fork to keep that certificate secret, um, or our third-party monitor has to misbehave and just not tell us about that certificate. And that's kind of really deeply unsatisfying because, you know, you have this quorum of cosigners that they are like vetted by the browser, if they misbehave and sign a fork you can like show the signature of that and you can prove they misbehave. Uh, that whole kind of system is undercut by this monitor where none of that is really true. So the monitor is not vetted by the browser in any real sense. It's also really hard to prove that they misbehaved, like if you say like, "Oh, the monitor didn't send me an email about this certificate," like how do you prove that they didn't send an email? That's like really squishy. And so that's kind of not great.
Something that we could do to potentially make that better is we could replace our third-party monitor and we could do something like a verifiable index. And the verifiable index could have cosigners as well. That is better for sure, but from a security perspective, really what you've done there is you've replaced your third-party monitor with this verifiable index system. So really what you still have is this kind of auxiliary system that is outside of the web PKI, it is outside of any kind of formal root program, and it is directly undercutting the security of the web PKI. And so all of the work that browsers put into designing their transparency policy or all the work they put into finding trustworthy cosigners kind of doesn't matter if this verifiable index system is not also holding up its end of the deal. Um, and that really sucks.
However, there is one kind of loophole here that we can work to potentially make this better. Um, and that is if we know that the cosigners are the exact same in both cases, then we can kind of simplify. So if we know that the same cosigners that sign the CA logs that the browser sees also sign the verifiable index that the site operator uses, uh, then it kind of doesn't matter whether those cosigners misbehave when they sign the CA log or when they sign the verifiable index. You know, it's the same cosigners in either case. And so this kind of fake math expression, we can simplify it and we can say that the security of our whole system just depends on, you know, the CA not misbehaving or this quorum of well-known vetted cosigners not misbehaving. And I would argue that this is a lot more intuitive and it's also probably closer to the security model that we actually want for our system.
And so how do we actually do that in practice? Because, I mean, the problem there is that we're saying that the server when it's doing monitoring needs to be able to verify cosignatures in the exact same way as the browser it cares about. However, a server is not a browser, so the server doesn't have the benefit of having like the CAs and the cosigners and the cosigner policy being kind of pushed down in its source code for free. So you know, in general, with that kind of problem, the best you could do is have the site operator basically track the development of every browser they care about. So they would have to like go find documentation or source code and try to manually replicate how the browser is configured and how the browser verifies cosignatures. Um, that's obviously really brittle, it introduces a lot of manual labor and also like a lot of room for mistakes, especially when you consider being able to track how these policies evolve over time. That could be a big source of issues.
So, you know, we could potentially add some kind of explicit protocol mechanism that directly solves this by having like browsers advertise their cosigner policy or like confirm it in some way to servers so that servers when they connect to a browser actually know what the cosigner policy is. That is an idea, but it's also probably pretty brittle and not really going to work. So the best option actually is probably this last one, which is where we add a—a new log entry type to the CA logs. Uh, and that log entry type contains the verifiable index root hashes that we want to convey to the server, uh, and that we want cosigned by the same cosigners.
And the reason that this works is because, you know, every certificate that the server has contains this kind of inclusion proof to a tree head. And if the server advertises a certificate to a browser and the browser accepts it, that tells the server that that tree head was like cosigned or authenticated correctly according to the whatever the browser's policies are. And if we know that that tree head is cosigned correctly, then that also means that our special log entries with our verifiable index root hashes are also cosigned correctly. And so that's a pretty clean—that's a pretty nice clean solution.
Um, the only real remaining problem that you have there is that, uh, when the server is doing monitoring, it needs some way to actually find these log entries so it can get those root hashes, right? Uh, and the log could potentially be very large, it could have a lot in it, and so we want to be able to do this efficiently, so not just like download the whole log. And we also don't want to reintroduce any new trusted parties that are going to work their way back into our uh security model like the third-party monitor kind of did. So the easiest way to do that, I think, is probably just to like add a counter uh to each log entry that contains the total number of these special accumulated type log entries that have been sequenced so far. So these accumulated log entries contain the verifiable index root hashes, and then we have this counter in every log entry that tells us how many of these have been added so far.
And what that lets you do is it lets you do a kind of a verifiable search through the log entries for either the most recent one of these log entries, uh, or, you know, a specific one if you want to look at a specific one you can do that instead. So whenever the server wants to do its monitoring, it does this search for the most recent accumulated type log entry, it looks in that log entry, it gets the verifiable index root hashes, and then it's good to go actually talk to the verifiable index and look up uh the certificates that are related to it. And I opened a PR for this that is open and ready for review, and that's all I got. Thank you.
Filippo Valsorda: Um, Filippo Valsorda for the notes. Um, I like it. I, um, I need to flip it in my head a bit before I can decide if the transparency part uh makes sense, but you thought about it and I think uh I trust that. Uh, the only thing, this requires uh CAs to operate their own verifiable index, right? Because we're not defining a way for the CA to accept without making a uh an as- like, there is no way for third parties to add these verifiable index tree heads to the CA's log. Is that correct?
Brendan McMillian: So—so the CA has to cooperate in adding those log entries with the root hashes, but I don't see why there's a reason why the CA has to run the verifiable index. So you could have the third party run the verifiable index and just submit those tree heads to the CA to be logged.
Filippo Valsorda: Uh, but who is taking responsibility for the correct construction of the index there?
Brendan McMillian: Uh, so basically the CA's role here is just in cosigning, so just in making sure that everybody has the same view of the verifiable index. In terms of making sure the verifiable index is constructed correctly, that would be done by basically anonymous people that are crawling the CA log and reconstructing the verifiable index.
Filippo Valsorda: Uh, okay, so the entry would have like an identity of the verifiable index operator. Okay, that's the part I was missing. Um, and I assume the CA will want to have some level of rate limiting for that, like not get spammed and so on, right?
Brendan McMillian: Yeah.
Filippo Valsorda: Uh, and don't the accumulated counters though need to be per verifiable index operator?
Brendan McMillian: Uh, I don't think—I think that I would just batch all of all of the different verifiable indexes together into one log entry and just add one log entry with all of them, you know? And so you lose a little bit of granularity, but that's kind of the cost.
Filippo Valsorda: Oh, I see. Okay. Yeah, simply because there's such a chance that, if it's not the CA, a verifiable index operator will just, you know, mess up or lie and we will want to not use that one and at the same time still be able to find the other ones. Um, cool. Yes, thank you.
Brendan McMillian: Thank you.
Luke Valenta: Hey, Luke Valenta. Um, yeah thanks Brendan for the—for the talk. Um, so I think yeah, maybe you just answered this question but so the verifiable index has to cover all CA issuance logs that could potentially be covered by, or that could potentially be trusted by clients, is that right?
Brendan McMillian: Um, I have some thoughts on that, but I don't think that this locks us into any particular decision there. So I think what you're asking is, does the verifiable index need to cover all CAs or just one CA? And my perspective on that is that I think probably the best decision in the end would be to have the verifiable index cover all CAs, but this—this PR doesn't lock us into that decision. You know, we could do it with just one CA.
Luke Valenta: Cool, thanks.
Deirdre Connolly: Um, yes. Um, we're—I'm hearing a lot about uh servers and browsers and things. Um, where do client certificates fit into any of this? I don't even know if it's a question for you or for David or for for whom. But is there a place in Merkle Tree Certificates and transparency for uh client certificates?
Brendan McMillian: That's a really good question that I am surprised by how surprised I am by. Um, I don't see why this would not work for client certificates, but I don't want to promise, that maybe David can say.
David Benjamin: I guess I'm in the queue. Uh, yeah, I think like mechanically client certs would work here. I think the main—like there's a lot of different client cert PKIs with different, you know, requirements. And I think probably some of the questions would be around like uh, I guess, like what are you trying to get out of Merkle Tree Certificates? Are you trying to get like like batch signing just? Or are you also trying to get some kind of transparency story? And if you're trying to get a transparency story, do are the identifiers in your client cert secret or not? Because on the for for sort of like CT-style transparency, we can play on easy and assume that all the identifiers are public. Um, if they contain people's email addresses, maybe not so much. Um, I guess and then the sort of the like various points in between that space that uh Filippo will be talking about. But I don't know if that answered your question.
Deirdre Connolly: Um, that's that's a big part of it. Uh, but if somebody does want to, you know, leverage this stuff in order to get to PQ without monstrous certificate chains on either side, you know, do they fit into this story in some manner, maybe without transparency, don't know? Uh, you know, what's the—I guess in the architecture doc there should be some thought about client certificates.
David Benjamin: Yeah, okay. Okay. Okay, so I guess so not—I don't want to steal your time slot, Brendan. Right? Uh, but so because I guess this is like not not directly related to transparency, if you want the size optimization then like I think that probably does not require that you publish the log or do anything if you just have some way to get the hashes down. So that's probably doable, but I'm not going to like design things on the fly. Um, yeah.
What was my question? I had a question. Yeah, okay. So I guess so it looks like the shape of this thing, like, you know, I imagine that figuring out the right sort of like authenticated index type thing will be like a whole work in itself. And so I guess the question is like, how—what is the minimum thing we need to like stick in here to make this later work possible, um, without sort of committing us to too many things we're not sure of yet. Um, one thing I'm slightly unclear on is like so you've got this like accumulated type enum, but I imagine that if, especially if you're imagining that different people operate different V-indexes, that it's not so much a type but like a—like, you know, a type is a small set of codepoints, but there might be like multiple V-indexes of one type. We might need to like update the indexing function if we like find a bug in the previous one, or someone invents a new way to stick DNS names in certs or whatever else you want. Um, and so I guess I'm not—like how do you see those sorts of changes interacting with the like accumulator type thing and also this like all-in-one count?
Brendan McMillian: I think that like my default solution in all of these cases where, like, we have multiple V-indexes or we have multiple indexes of different types, I think my answer would be we just have, like, the accumulated log entry type, we just have it break down everything by—so we just have like one big log entry that contains a list of everything, and then we like maybe have an identifier of whose log it is, we say what kind of log it is, and we just have this big list. And I don't right now see a reason to break the that log entry up across different types of log entries.
David Benjamin: I guess in that case, why do we need the accumulated type in there? Like the—the sort of dichotomy between there being lots of different types but then one shared counter is the thing that's like very much confusing me about this. Because, I mean, I guess you'll be binary searching to find the next one or the previous one and then you'll have to like keep bouncing back and forth—or bouncing back to the previous one if like you didn't find the right one unless they're all sort of batched together, but then the CA might not be able to batch them together if like one of them's being really slow. Um, so I guess it's sort of those dynamics are very unclear to me.
Brendan McMillian: Right. The purpose of the accumulated log entry type is just to get that counter, which makes it efficient to find specific ones. So you have this big log with a bunch of different things in it, maybe a bunch of certificates, um, and so that counter just makes it easy for someone to go in and verifiably find a specific accumulated log entry type. Um, and I think the rule would be within a specific accumulated log entry type, you would want to keep it relatively small, understanding that people are going to have to pull that out and like pick whatever they want out of it, you know? You wouldn't unnecessarily split it up across different log entries. Um, but yeah, the the purpose of the accumulated log entry type is solely that we can have that counter, we can get it in the protocol now, and then we can figure out later what do we actually want to put in that in that in that space.
David Benjamin: Oh, I guess because you need like if you're going to define a counter and say it counts something that we haven't even defined yet. I mean, we could just have the counter and be like, "It's going to be zero, we'll make it non-zero later, please ignore this for now." Um, kind of weird. Um, is it possible to just stick the like in the counters in like a—oh, we'll just say every every 100 type every 100 or every like 256 entries, please go put one of those in there and then you can just sort of jump over to find the other one? Or does that just end up being too goofy?
Brendan McMillian: I think that that does introduce a lot of problems because you don't know how fast the log is going to grow. Um...
David Benjamin: But you as the CA get to control how fast—like you can just be like, "Oh, I've gotten to 256, it's time for me to punch out a like summary."
Tom Ritter: Maybe we're getting a little bit too in the weeds here, um, and approaching the point where people are starting to pull out whiteboards to keep following what what you guys are talking about. So, um, let's uh maybe park this for now and continue this on list or or on the the GitHub pull request as linked on the slide in front of us, and uh move on to I think John Gray who's in the queue.
John Gray: Yeah, I was just wanting—can you hear me, hopefully? Yeah, I was just going to say I wanted to respond quickly just to what Viktor was saying because I've had the same kind of trying to wrap my mind around how these things could be perhaps used, you know, in client certificate use cases or, you know, private PKI. So I just posted an email on the list like I don't know an hour ago, um, so Viktor that might be something that'd be interesting to discuss then and talk about maybe it ends up being something that's put into an architecture document if there's something that can work, because I'm not sure yet if if all this complexity or whatever is worth the effort. I, yeah, I don't think we would need monitors or logs to do it, but there might be a way to do it that's going to get some efficiency, especially with larger PQ algorithms. But I think that's something that might go into an architecture document. So just wanted to mention that.
Tom Ritter: Bas indicates he's also—Bas Westerbaan in chat also indicated he's very interested in working on this.
John Gray: Yeah, so—so great, so let's talk on the list then.
Tom Ritter: Okay then. Filippo is in the queue.
Filippo Valsorda: Filippo for the notes. Um, feel free to tell me, "Oh, this is handled, I'll just read the PR," but if the CA is adversarial, which I think it is here, can't the CA not collaborate to publish those verifiable index tree heads, uh, and hide those from the—from the servers?
Brendan McMillian: I mean, the—the CA can not accept those those requests to log the heads, but that all that results in is like an authenticated negative. So the server whenever it tries to do monitoring, it would be able to authenticate a negative result that there are no recent tree heads that it can look at.
Filippo Valsorda: And I assume that would, you know, lead to the conversation uh and so on. Um, and if it chooses winners and losers, we're not really worried because either the indexes are correct, uh, or it's the same thing as not accepting any to only accept like bad indexes. Right?
Brendan McMillian: Yeah.
Filippo Valsorda: Okay. Cool. Yes, thank you.
Brendan McMillian: Thank you.
Tom Ritter: On the uh private PKI thing, lots of people are chiming in that they're very interested in in discussing this issue further. So we'll see probably some activity on the list on that, at least I hope so. Um, thank you Brendan for this presentation. Uh, and since the queue is empty, I uh should be moving over to the next deck, which will be four Luke Valenta. And I'll press the button. I have pressed the button. Take it away.
Luke Valenta: All right, great. Thanks Tom. Uh, so Luke Valenta. So we're um, we're really excited to get uh get some get some running code with Merkle Tree Certificates. So we uh started I guess working last year, um between Chrome and Cloudflare to uh get an experimental deployment up. And what I have here today is just some early results from that experiment and um let's get to it.
Oops. Okay. Uh, so we wanted to evaluate the just make sure Merkle Tree Certificates was going to be feasible in a real deployment. And and also to check that the performance actually matched what we kind of expected. So in the experiment setup, uh Cloudflare is the server, um currently have it enabled for 1,000 Cloudflare proxy domains. Um, Cloudflare is also running the NTC CA in and sort of this funny bootstrap mode. Um, we wrote a blog post about it with with some more details, um but since Cloudflare is not a a real CA, we issue NTCs that are backed by a existing traditional cert chain signed by a um browser trusted CA. Um, this kind of being tied to this bootstrap mode, um restricts us to only experimenting with classical signature chains because that's what we have in the web PKI today. Um, and we're also using this like seven-day cert validity um for the MTC claim. So a bootstrap cert might cover multiple um NTCs I guess that are split into seven-day chunks.
Um, we're also just looking at landmark MTCs. Um, the standalone I guess in terms of—in terms of like performance and stuff, it should be closer to traditional X.509 + CT chains. Um, but yeah, so we wanted to look at landmarks where the real optimization from MTCs comes in. Um, in terms of experimental parameters, um we're issuing landmarks every hour from the CA. Um, and then the the in our experiment the largest proof sizes we get are about 512 bytes. In a real deployment uh at web scale, this would be I don't know, seven or eight hundred bytes. So we're a little bit lower than um than you'd expect in uh than we'd expect in real life.
Um, Chrome is running the TLS client, currently enabled for 50% of of Chrome beta and it also runs the service that um that fetches and validates the landmarks from the CA. Um, and the client state for storing all these landmarks is about 10 KB with the current parameters. So all of these parameters can be tweaked a bit to get the client state to to something you're happy with along with um I don't know, all the other parameters in the system. Uh, and then here is a screenshot, this is from uh from Chrome the certificate viewer of a real NTC being served. Um, you can see the the kind of funny um certificate issuer there, um which is the the OID we're using for the experiment. And this identifies the the um CA that we're using for the experiment as well. And then in the signature value field, you can see this uh encoding of the inclusion proof and um which is instead of a of a signature.
So we looked at the performance. So this is the um well, this measurement we have here is from on Cloudflare servers, the total time it took us from when the handshake was initiated to when the connection was passed on to the um I guess after the TLS handshake is completed and the connection is passed on to the next um service in the in the stack. Uh, so we found that at the median, the um NTC group was about 9% faster than the control group. And this is with classical signatures, so once you drop in post-quantum signatures, we expect the performance gap to be even bigger. Um, we think yeah, so NTCs don't grow as quickly with post-quantum signatures as traditional cert chains do. So this is this is kind of what we expected, but great to see it in the um in the early results from the experiment as well.
The other question we asked was, do clients can clients keep up with the landmarks? Are they able to get these frequent updates um to make sure they're they recognize they have up-to-date landmarks so that they can um actually be served CAs NTCs that they trust. Uh, and so this—this is just showing from some internal dashboard uh after we um enabled NTCs for a whole bunch of of domains, how quickly clients were able to um start using those NTCs. Um, pretty quickly most clients were able to update within a few hours uh to get the um the recently issued NTCs. And then the steady state in the experiment was about like 1% of clients were were stale. Um, and we expect this to be kind of an upper bound just just due to quirks of how the experiment's deployed. We think it'll be a little lower for a real deployment.
So I think the most important thing that we showed with this is that NTCs actually work. Um, they are used to deploy or to secure real traffic today, um albeit in this kind of bootstrap mode. Performance was um I guess we showed there's a a latency improvement in the TLS handshake over using a a classical signature chain. Um, so that's I guess it's—I mean, the reason for that is just because we're sending fewer bytes over the wire over like RSA um plus ECDSA cert chains. Um, and it's generally not a not a problem for clients to stay up to date with the landmarks. Um, in terms of operational experience, we've had a shake out a few bugs on both the client and server side, um mostly due to mostly related to the bootstrap mode. Um, and middle box uh interference is another thing we wanted to look at, and uh so far haven't hasn't been a factor, um mostly because this is encrypted uh or the the server certificate is encrypted in the in the TLS 1.3 handshake. So that's what we want to see. And I think this is I don't have any more slides, so uh happy to take questions.
Tom Ritter: No one else, then I will ask a question. Um, so this middle box issue, um, it is true that TLS 1.3 encrypts everything after server hello, but there are also middle boxes that decrypt people's traffic. Um, have you got any clue how many of those sorts of corporate spyware networks, um, this experiment would be penetrating right now?
Luke Valenta: Um, no. I'm not sure exactly. Uh, I guess in yeah, I think that's something we'll look at a little bit more later, see see how many I guess you'd we'd see a a downgrade I guess essentially from um yeah, from NTCs to just a normal normal handshake from the middleware. So, um yeah, at least server-side we don't have those metrics, but we might be able to see some more from the um from the Chrome or the client-side metrics.
Tom Ritter: I guess that makes sense that it would be a downgrade. And also, I mean, intuitively probably there's not a lot of beta clients inside inside banks highly controlled networks. But um yeah, interesting to see how this develops.
Deirdre Connolly: Um, what's your policy for eviction from cache for landmarks? Is it just last-in last-out? First-in first-out? You know what I mean, the oldest one gets evicted first?
Luke Valenta: Uh, on the I guess for on the server-side of like when we're reissuing the landmarks?
Deirdre Connolly: On the client-side. On the browser-side. You said you have 10 KB of cache stored.
Luke Valenta: Oh, oh I see. Um, yeah so this gets pushed down um by the browser update service. I think, yeah, I'm not sure exactly how the mechanism works, but I think they just uh every every time there's a new landmark they recompute the bundle and send it down to clients. Um, so I don't know if it's just sending down 10 KB every time or if it's an incremental update. Um, yeah, maybe David can answer definitively.
Deirdre Connolly: So this is kind of up to the implementer of how exactly they want to manage the the pushing and management of landmarks on the client, um and in the case of Chrome, they basically were like, "Ah, the whole browser gets a fresh view of landmarks and gets shipped with it every time you fly a browser update," which has its own diffing and smart data update stuff.
David Benjamin: I actually don't remember offhand like how the update service like I assume it does diffing things. Um, it does diff very nicely in that like, you know, if you if you're like here and then you move forward an hour, all the ones in the middle are the same. So if we're not diffing we really should be diffing. Um, in terms of like when things fall off, the the sort of window of landmarks that you want is should be sized such that all unexpired certificates are covered. Um, and so part and like the parameters we tune are like you tune the the time between landmarks and the max cert the max cert lifetime such that like the the number of active landmarks you want is bounded because it is really annoying for like certificate usage if like, you know, before the cert expires it might fall off on clients. Like, it's a lot easier if it can just be like clients up-to-date enough, it's good. By the time it's not good, you had to get a new cert anyway.
Deirdre Connolly: Uh, is there anything written up with the with the finding that sweet spot as a client in any of these documents?
David Benjamin: I think the document currently has a—the document has a recommended allocation scheme, uh, which I think you set the number of—the time in between them, although I think that probably could be tuned a bit. So there are some like example numbers but there's not like "you should maybe use these numbers." Um, probably what we should actually write is like "this is the number of active landmarks you probably want to have and then you scale everything from there," like if your cert lasts 45 days, you know, 45 divided by N. If they last a year, do one year divided by N.
Deirdre Connolly: Yeah. Exactly. Correct. Okay. Thank you.
Guilin Han: Uh, Guilin Han, yeah from Huawei international. I just have a question about the middle of these slides. Yeah, from from the data you show, um something like uh the performance is for classic signature is 9% or 10%. So does it mean this is a significant uh latency improvement? Or maybe I missed something? But of course, I agree with you, yeah once PQ signature used, the the gap should be bigger. Yeah.
Luke Valenta: Um, yeah that—that's right. I think you interpreted interpreted it correctly. Um, so the um the raw numbers here, so at the median for the NTC group, the the TLS connections for which a NTC certificate was negotiated, um the median was 105 milliseconds, and then for the control group which um still I guess sends the trust anchor IDs TLS extension but doesn't actually negotiate MTC, the median was 116 milliseconds. So we were a little faster with NTCs. And this is a um this is a nice improvement um even even if we weren't didn't have post-quantum signatures looming, um this would be something that would, I don't know, maybe maybe justify some deployment being a a performance boost like this.
Guilin Han: Okay. Thank you.
Tom Ritter: Okay, I believe we've exhausted the queue. Um, thank you Luke and let's move on to the last presentation for Filippo who has asked permission. But where does that go? Grant.
Filippo Valsorda: And I got a over-constrained error, whatever that means.
Tom Ritter: I've passed control.
Filippo Valsorda: Yes. Excellent. Uh, okay, so lots of interest in MTC for private PKIs, so this is probably going to be interesting to people that care about that. So what we're going to do is look at MTC and prune it down until it's just a signature algorithm, and then we're going to look at how you can then modularly add back pieces of MTC that are useful to your—to your PKI.
So, the core insight is that you can use MTC wherever you like. Um, the thing that requires a interactive protocol with a client that can do sync and landmarks are the size benefits. Um, for those you need the Web PKI and TLS style setting. But if you're just doing a private PKI, as long as you can do X.509 signatures with a new algorithm, you can do MTC, and we're going to see how the MTC shapes down to being completely isomorphic to a signature algorithm. Uh, we could call it, you know, MTCDSA.
So, let's start with MTC. MTC you have a few public keys, the CAs and the other cosigners that sign a tree head. You put your certificates into a log and you sign that tree head. Okay. Although in practice, what you actually there is this optimization which is the subtree signing, where you actually obtain a signature over a smaller portion of the tree and use that signature instead of the one over the whole tree because that makes the inclusion proof smaller.
Anyway, that might sound complicated. There are moving parts, there is stateful stuff, there is transparency stuff. So the question I I got at Real World Crypto in chat is, "Okay, how do I use it for this constrained PKI that can't do all of these bells and whistles?"
Okay. Step one, you use standalone Merkle Tree Certificates. Uh, forget about landmark certs for a moment. A standalone Merkle Tree Certificate is that bundle on the right. It's the signatures from the cosigners over the subtree head and the inclusion proof, the Merkle Tree inclusion proof for the certificate. That thing in the in the yellow box on the right is the signature. Like, you can think of that as the MTCDSA signature. So it's what goes into the signature field of a certificate.
Now, first thing you can do is my PKI does not have transparency, I don't have cosigners, I only have the one signature from the issuer. So now you have the issuer signature over the subtree head and then the inclusion proof for the certificate.
The next step is that you can actually make that subtree size one. And if the subtree size is one, the signature is over the leaf. Um, so now the whole thing that's in that box on the right, which is the signature from the issuer, is the signature from the issuer. So essentially we reduced the MTC signature to nothing other than a roundabout way to get to the to a single signature from the issuer on the certificate.
Finally, what you can do is that you can forget there was ever a log. You don't have to implement MTC statefully. The only thing you should avoid doing is putting two certificates in the same place in in the log, but we already had that requirement for CAs which is the serial number uniqueness requirement. You are already supposed not to sign two certificates with the same serial number.
So you can make a stateless MTC CA that just sign things by signing a subtree size one and produces a standalone certificate of that size one subtree and doesn't even log the certificate anywhere. This will work with a general enough MTC verifier.
Now, yes, this is a degenerate case. The reason I wanted to go all the way down in pruning is to show that you get if you scratch enough, you get something that's isomorphic to the current X.509 PKI. Like, currently X.509 PKIs have a signature from the issuer on the certificate, and you can prune MTC all the way down to that.
Now, why would you do that? Like why go all the way down into the degenerate case? Well, you can then add pieces of MTC back up. Uh, for example, one thing you can add back is you might want to rotate the issuer key. And MTC has essentially key rotation embedded for free because you can sign with two different public keys. Now, this is if you don't care about size, but maybe in your private PKI case you don't care about size and you like the idea of sending down a certificate that is signed by two issuers at the same time.
Then um you might want to add back the log and actually have the audit log, and you might want to do that specifically because quantum computers are coming. And you get the same downgrade strategy as the one that Chrome described for the Web PKI where the signal for opting in to a downgraded classical signature scheme is to get a certificate with a classical public key in it and logging that into the PQ PKI. And for that, you need the audit log, so MTC has an audit log just ready for you there.
But now that audit log you might also want to get cosigned by someone. For example, you are a CA operator or you have different organization parts in your in your parts in your organization and you want your client or your other team to cosign your your PKI so that you can sell something like "we will run your PKI for you but you retain control because your clients will check both our signature and your signature" and you can do monitoring just like in CT. So essentially you can do CT for private PKIs. This is all if you want. These are things you can add back. And finally, if you have a slow HSM, you could make the subtree size not be one anymore, and now you sign with the HSM once every few certificates. These are all options of things you can do.
So what I hope this shows is that subtree sized one standalone MTCs are isomorphic to X.509 signatures right now, so they will work anywhere they should work anywhere the current ones do. So we could actually make that the only PQ PKI code path. I'm not saying we should, to be clear, this presentation is about getting a intuition for how these things are possible and how you can use pieces of MTC. Maybe we also should so that we only have one PQ issuance code path or only one PQ verifier code path. I'm not sure about that. But at least it's a thing we could do and it probably informs how you can do private PKIs. Thank you.
Tom Ritter: Thank you Filippo, I think those figures were very helpful for lots of people. Um, is there anyone that wants to insert a comment in this last minute of the meeting, or there's any other business that we want to talk about as a group?
Russ Housley: Thank you everyone, I think we had a very productive first session for the PLANTS working group.
Tom Ritter: Yeah, thanks again to everyone who presented and weighed in with comments, and we will see each other on the list then, since we're at time. Good night.
Russ Housley: Good night.
Tom Ritter: Goodbye everyone.