[{"author": "Robert Moskowitz", "text": "

Oh course, my few times in China and their taxis, they all had fancy seat covers and covered the seat belts. Literally no way to \"buckle up\".

", "time": "2026-03-16T08:30:12.000Z"}, {"author": "David Benjamin", "text": "

:potted_plant:

", "time": "2026-03-16T08:31:28.000Z"}, {"author": "Richard Barnes", "text": "

love that we're watching out for ekrbot now

", "time": "2026-03-16T08:34:02.000Z"}, {"author": "Richard Barnes", "text": "

gotta take care of the AI

", "time": "2026-03-16T08:34:07.000Z"}, {"author": "Jonathan Lennox", "text": "

Also be aware that while names are displayed live, they are not in the recordings (for people in rooms)

", "time": "2026-03-16T08:34:17.000Z"}, {"author": "Deirdre Connolly", "text": "

pruned!

", "time": "2026-03-16T08:34:33.000Z"}, {"author": "Mike Ounsworth", "text": "

Are we taking votes on which github mode to use for PLANTS?

", "time": "2026-03-16T08:39:36.000Z"}, {"author": "Russ Housley", "text": "

Yes

", "time": "2026-03-16T08:39:47.000Z"}, {"author": "Jonathan Lennox", "text": "

Well, not votes per se

", "time": "2026-03-16T08:40:01.000Z"}, {"author": "David Schinazi", "text": "

Issue Discussion Mode!

", "time": "2026-03-16T08:40:18.000Z"}, {"author": "Tommy Pauly", "text": "

Looks good

", "time": "2026-03-16T08:40:33.000Z"}, {"author": "Deirdre Connolly", "text": "

lgtm

", "time": "2026-03-16T08:40:41.000Z"}, {"author": "David Benjamin", "text": "

LGTM!

", "time": "2026-03-16T08:40:44.000Z"}, {"author": "Filippo Valsorda", "text": "

LGTM

", "time": "2026-03-16T08:40:52.000Z"}, {"author": "Deb Cooley", "text": "

cc me when you send the message to support for the plants organization.

", "time": "2026-03-16T08:41:10.000Z"}, {"author": "David Schinazi", "text": "

You can have GitHub email a summary to the list once a week

", "time": "2026-03-16T08:41:13.000Z"}, {"author": "Filippo Valsorda", "text": "

yeah let's enable the weekly digests

", "time": "2026-03-16T08:41:26.000Z"}, {"author": "Martin Thomson", "text": "

Thanks Russ, that's the most important thing.

", "time": "2026-03-16T08:41:53.000Z"}, {"author": "David Benjamin", "text": "

(Will move repo to org as soon as chairs give me the all-clear.)

", "time": "2026-03-16T08:41:54.000Z"}, {"author": "Deirdre Connolly", "text": "

:lettuce:

", "time": "2026-03-16T08:42:20.000Z"}, {"author": "Nathanael Ritz", "text": "

I will never be unhappy with the puns for this WG

", "time": "2026-03-16T08:42:38.000Z"}, {"author": "Sean Turner", "text": "

:laughing:

", "time": "2026-03-16T08:43:50.000Z"}, {"author": "David Schinazi", "text": "

@meetecho we're hearing some echo with remote chairs/presenters. I think it might be coming from the Shenzhen room

", "time": "2026-03-16T08:43:52.000Z"}, {"author": "Lorenzo Miniero", "text": "

We can decrease the gain there a bit, since no one is talking there: can you let us know if it's better?

", "time": "2026-03-16T08:44:52.000Z"}, {"author": "David Schinazi", "text": "

I think it's better now, thanks

", "time": "2026-03-16T08:45:33.000Z"}, {"author": "Martin Thomson", "text": "

david is voiping on and off still

", "time": "2026-03-16T08:45:38.000Z"}, {"author": "Martin Thomson", "text": "

It seems like the AEC is struggling a little

", "time": "2026-03-16T08:45:50.000Z"}, {"author": "Richard Barnes", "text": "

the 6962 is soooo caching hostile

", "time": "2026-03-16T08:46:33.000Z"}, {"author": "Filippo Valsorda", "text": "

yep, Go Checksum Database, Sigstore, Android firmware transaprency, Sigsum, and more are using parts or all of the tlog specs

", "time": "2026-03-16T08:48:32.000Z"}, {"author": "Mike Ounsworth", "text": "

Filippo Valsorda said:

\n
\n

yep, Go Checksum Database, Sigstore, Android firmware transaprency, Sigsum, and more are using parts or all of the tlog specs

\n
\n

So much for the IETF SCITT WG then :rolling_on_the_floor_laughing:

", "time": "2026-03-16T08:49:32.000Z"}, {"author": "Dennis Jackson", "text": "

I'd quite like to see a simpler negotiation mechanism in TLS as an alternative to TAI that won't have to rely on DNS (quite a pain for automation). E.g. giving the landmarks timestamps and the client just saying: I know all timestamps up to X.

", "time": "2026-03-16T08:51:21.000Z"}, {"author": "Dennis Jackson", "text": "

(will write to the TLS mailing list with a proposal, though it might make more sense for it to come to plants)

", "time": "2026-03-16T08:51:59.000Z"}, {"author": "Richard Barnes", "text": "

i take it \"landmarks\" are what have been referred to in the past as \"blessed STHs\" / \"STH discipline\"?

", "time": "2026-03-16T08:52:15.000Z"}, {"author": "Bas Westerbaan", "text": "

yes

", "time": "2026-03-16T08:52:23.000Z"}, {"author": "Richard Barnes", "text": "

thanks

", "time": "2026-03-16T08:52:28.000Z"}, {"author": "Devon O'Brien", "text": "

@Richard Barnes They're generally analogous, yeah

", "time": "2026-03-16T08:52:41.000Z"}, {"author": "Dennis Jackson", "text": "

Well, that's probably cursed things :-)

", "time": "2026-03-16T08:56:52.000Z"}, {"author": "Richard Barnes", "text": "

it seems like any error besides forking history can just be logged and the log can keep going

", "time": "2026-03-16T08:57:19.000Z"}, {"author": "Richard Barnes", "text": "

but i might be missing something

", "time": "2026-03-16T08:57:28.000Z"}, {"author": "Jonathan Lennox", "text": "

Victor is unintelligible in the room

", "time": "2026-03-16T08:57:39.000Z"}, {"author": "Richard Barnes", "text": "

Barely intelligible online

", "time": "2026-03-16T08:57:49.000Z"}, {"author": "Dennis Jackson", "text": "

I had a cute idea about using the null entry (currently at the 0th position in a generation) to pop in a hash of the old tree head, but not sure if its actually useful for anything.

", "time": "2026-03-16T08:58:07.000Z"}, {"author": "Michael Richardson", "text": "

I think, but maybe I'm wrong, that if one has a root CA, and that it periodically creates a subordinate CA, which actually signs EE, that if a subordinate CA screws up >64 times, that one can just roll over to a new subordinate CA. I think: because I am getting hints that we might not have two-level PKI anymore.

", "time": "2026-03-16T08:58:15.000Z"}, {"author": "Bas Westerbaan", "text": "

Think for instance bitflips.

", "time": "2026-03-16T08:58:23.000Z"}, {"author": "Filippo Valsorda", "text": "

Another use for a specified trust anchor format is MDM provisioning.

", "time": "2026-03-16T08:59:46.000Z"}, {"author": "Bas Westerbaan", "text": "

@Michael Richardson Technically we can still do chains. They won't benefit from the landmark certs size savings, and probably the WebPKI wouldn't want them.

", "time": "2026-03-16T09:00:27.000Z"}, {"author": "Dennis Jackson", "text": "

Bas: Can you say why intermediates and landmarks are impossible to use together?

", "time": "2026-03-16T09:00:59.000Z"}, {"author": "Richard Barnes", "text": "

please no new ASN.1

", "time": "2026-03-16T09:01:09.000Z"}, {"author": "Dennis Jackson", "text": "

(no position on whether they're desirable)

", "time": "2026-03-16T09:01:25.000Z"}, {"author": "Filippo Valsorda", "text": "

I'll take ASN.1 over anything else _in X.509_

", "time": "2026-03-16T09:01:29.000Z"}, {"author": "Bas Westerbaan", "text": "

Dennis Jackson said:

\n
\n

Bas: Can you say why intermediates and landmarks are impossible to use together?

\n
\n

If you didn't know about the intermediate, then you also probably didn't know about its landmarks.

", "time": "2026-03-16T09:01:31.000Z"}, {"author": "Mike Ounsworth", "text": "

One point I've made a few times about chains is that WebPKI is a highly audited environment via the WebTrust set of standards.
\nWe know how to do root X.509 CAs, key ceremonies, blah blah.
\nI suspect that treating MTC as a funny Issuing CA tucked under a traditional Root CA will be more auditor-friendly (and therefore get this thing deployed faster with less regulatory headache) than needing to change all the WebTrust rules to natively deal with MTC Roots.

", "time": "2026-03-16T09:02:22.000Z"}, {"author": "Dennis Jackson", "text": "

Right, but if I do know about the landmark, why can't I know about the intermediate? That is - can I have intermediates to allow offline signing but still keep landmarks for fresh clients?

", "time": "2026-03-16T09:02:26.000Z"}, {"author": "Dennis Jackson", "text": "

(again, not sure we need this really)

", "time": "2026-03-16T09:02:40.000Z"}, {"author": "Michael Richardson", "text": "

Bas Westerbaan said:

\n
\n

Michael Richardson Technically we can still do chains. They won't benefit from the landmark certs size savings, and probably the WebPKI wouldn't want them.

\n
\n

We do two-level so that the long-term trust anchor keys are offline. I understand this is a pain byte-wise if we transfer the subordinate CA online, so since they change rarely, it seems like they could retrieved on demand once or twice a year.

", "time": "2026-03-16T09:03:14.000Z"}, {"author": "Richard Barnes", "text": "

multilingual plant puns!

", "time": "2026-03-16T09:03:29.000Z"}, {"author": "Deb Cooley", "text": "

almost ekr speed

", "time": "2026-03-16T09:03:51.000Z"}, {"author": "Martin Thomson", "text": "

I have to confess that the speed of talking was such that I wasn't tracking well.

", "time": "2026-03-16T09:03:54.000Z"}, {"author": "Martin Thomson", "text": "

The audio issues didn't help.

", "time": "2026-03-16T09:04:05.000Z"}, {"author": "Richard Barnes", "text": "

i mean, this seems pretty well laid out at an overall system level, seems like we just need to nail some details down

", "time": "2026-03-16T09:04:26.000Z"}, {"author": "Martin Thomson", "text": "

Some of this seemed to be too far ahead of settling other details.

", "time": "2026-03-16T09:04:44.000Z"}, {"author": "John Gray", "text": "

Its 5am where I am, I'm sure I have questions, I just don't know where to start or whether they would be coherent at this point...

", "time": "2026-03-16T09:05:23.000Z"}, {"author": "Richard Barnes", "text": "

Seems like the arch doc should help flush out some of those high-level things

", "time": "2026-03-16T09:05:25.000Z"}, {"author": "David Benjamin", "text": "

Ah sorry, I talk very fast. :-(

", "time": "2026-03-16T09:05:54.000Z"}, {"author": "Dennis Jackson", "text": "

I have the sense a lot of folks in the room would enjoy reading (and contributing questions to) the arch doc.

", "time": "2026-03-16T09:06:46.000Z"}, {"author": "Michael Richardson", "text": "

Deirdre, I think that the \"L\"imited part of LAMPS means that the work you think might require, should happen here.

", "time": "2026-03-16T09:07:04.000Z"}, {"author": "Richard Barnes", "text": "

have the puns about PLANTS liking LAMPS been made?

", "time": "2026-03-16T09:07:11.000Z"}, {"author": "Devon O'Brien", "text": "

Mike Ounsworth said:

\n
\n

One point I've made a few times about chains is that WebPKI is a highly audited environment via the WebTrust set of standards.
\nWe know how to do root X.509 CAs, key ceremonies, blah blah.
\nI suspect that treating MTC as a funny Issuing CA tucked under a traditional Root CA will be more auditor-friendly (and therefore get this thing deployed faster with less regulatory headache) than needing to change all the WebTrust rules to natively deal with MTC Roots.

\n
\n

The human-auditable surface of MTCs is greatly reduced from the WebTrust status quo. Not to trivialize that undertaking, but I think MTCs (or any equivalent) would be better served by first identifying what needs to be audited and building it upwards into audit criteria rather than further shoehorning it into existing models to broaden adoption. Architecting hierarchies for this consideration in particular feels the wrong approach to me.

", "time": "2026-03-16T09:07:23.000Z"}, {"author": "Jonathan Lennox", "text": "

I think anything that gets work out of LAMPS is a good thing

", "time": "2026-03-16T09:07:26.000Z"}, {"author": "Deb Cooley", "text": "

plants need light, so....

", "time": "2026-03-16T09:07:31.000Z"}, {"author": "Richard Barnes", "text": "

Devon O'Brien said:

\n
\n

Mike Ounsworth said:

\n
\n

One point I've made a few times about chains is that WebPKI is a highly audited environment via the WebTrust set of standards.
\nWe know how to do root X.509 CAs, key ceremonies, blah blah.
\nI suspect that treating MTC as a funny Issuing CA tucked under a traditional Root CA will be more auditor-friendly (and therefore get this thing deployed faster with less regulatory headache) than needing to change all the WebTrust rules to natively deal with MTC Roots.

\n
\n

The human-auditable surface of MTCs is greatly reduced from the WebTrust status quo. Not to trivialize that undertaking, but I think MTCs (or any equivalent) would be better served by first identifying what needs to be audited and building it upwards into audit criteria rather than further shoehorning it into existing models to broaden adoption. Architecting hierarchies for this consideration in particular feels the wrong approach to me.

\n
\n

To be a bit more blunt, WebTrust exists to serve the needs of the relying parties, so if the needs of the relying parties change, WebTrust needs to change. Its the tail, not the dog.

", "time": "2026-03-16T09:09:07.000Z"}, {"author": "Robert Moskowitz", "text": "

Different frequency bands for different plants

", "time": "2026-03-16T09:09:15.000Z"}, {"author": "Mike Ounsworth", "text": "

@Devon O'Brien

\n

Right. No real disagreement; I'm really just asking: is anyone actually looking at what modifications are required to WebTrust in order to have a certified MTC deployment?

\n

My understanding of WebTrust is that most of the auditable parts have to do with the roots -- HSMs, root CA infra in air-gapped networks, etc.
\nI _suspect_ that the more you make the MTC root look like a traditional WebTrust X.509 root, the easier this will be?

\n

But my overall point is: could someone please do a presentation on the progress towards adapting WebTrust rules for MTC?

", "time": "2026-03-16T09:10:23.000Z"}, {"author": "Robert Moskowitz", "text": "

I did get a BS in Botany back in '72 and we knew much of this already then. :) Plants need light. but which light?

", "time": "2026-03-16T09:11:02.000Z"}, {"author": "Deb Cooley", "text": "

lamps

", "time": "2026-03-16T09:11:15.000Z"}, {"author": "David Benjamin", "text": "

Richard Barnes said:

\n
\n

multilingual plant puns!

\n
\n

https://en.wikipedia.org/wiki/Jiayou_(cheer) might help in decoding that one.

", "time": "2026-03-16T09:11:17.000Z"}, {"author": "Filippo Valsorda", "text": "

If the UAs don't require WebTrust, that's up to them, right?

", "time": "2026-03-16T09:11:22.000Z"}, {"author": "Bas Westerbaan", "text": "

That IE logo makes me nostalgic.

", "time": "2026-03-16T09:11:35.000Z"}, {"author": "Robert Moskowitz", "text": "

And you could get lamps which were good for some plants but not so good for others. So we put gels over the lamps to get the freq we wanted for our work. Is that kind of what we are doing here? ;)

", "time": "2026-03-16T09:12:38.000Z"}, {"author": "Dennis Jackson", "text": "

Filippo Valsorda said:

\n
\n

If the UAs don't require WebTrust, that's up to them, right?

\n
\n

It's not obvious that the value of audits is in what they audit, so much as what they cost and what they (hopefully) imply about the care taken. They're arguably as much a first-screen for new CAs as anything

", "time": "2026-03-16T09:13:14.000Z"}, {"author": "David Benjamin", "text": "

We went through the negotiation space in TLS WG quite thoroughly. The DNS dependency is optional (and indeed the extension also lets us play with the broader solution space a bit more). A shared timestamp means one temporarily inaccessible CA breaks landmark certificates for all certificates. I don't think that's acceptable. But, hey, if someone wants to encode {name-of-my-root-set}.{timestamp} in a trust anchor ID, that's pretty easy, and the extension gives you the tools to program that in.

", "time": "2026-03-16T09:14:10.000Z"}, {"author": "Dennis Jackson", "text": "

There's no need for a temporarily inaccessible CA to break landmarks. But maybe it's better to have it written down first so it can be shot at properly :-)

", "time": "2026-03-16T09:15:33.000Z"}, {"author": "Martin Thomson", "text": "

Is this true? I thought that cosigners were limited in what they checked from the main log.

", "time": "2026-03-16T09:15:36.000Z"}, {"author": "Devon O'Brien", "text": "

This was an unexpected deep dive into audits, but I think we should broadly think about MTC audit needs first from a CT perspective with a series of verifiable technical controls, and then and only then seeking to fill the gaps with human audits. CT has taught us that even a 30 day initial period of operation is sufficient to weed out a host of not-fully-capable entities.

", "time": "2026-03-16T09:16:04.000Z"}, {"author": "Richard Barnes", "text": "

i'm waiting for this to end up with a blockchain

", "time": "2026-03-16T09:16:10.000Z"}, {"author": "Filippo Valsorda", "text": "

I feel like monitors are picked by site operators in the same way their e.g. CDN or host is, which are also trusted in the same way.

", "time": "2026-03-16T09:16:16.000Z"}, {"author": "Martin Thomson", "text": "

My understanding is the witnesses in the sunlight case only checked that the log was append-only. Not that each certificate was issued correctly to someone who passed a check.

", "time": "2026-03-16T09:16:17.000Z"}, {"author": "Filippo Valsorda", "text": "

(Verifiable Index: https://github.com/transparency-dev/incubator/tree/main/vindex)

", "time": "2026-03-16T09:16:29.000Z"}, {"author": "Bas Westerbaan", "text": "

Verifiable index :heart:

", "time": "2026-03-16T09:16:56.000Z"}, {"author": "Deirdre Connolly", "text": "

Richard Barnes said:

\n
\n

i'm waiting for this to end up with a blockchain

\n
\n

generations of logs smells blockchainy

", "time": "2026-03-16T09:17:14.000Z"}, {"author": "Mike Ounsworth", "text": "

Dennis Jackson said:

\n
\n

Filippo Valsorda said:

\n
\n

If the UAs don't require WebTrust, that's up to them, right?

\n
\n

It's not obvious that the value of audits is in what they audit, so much as what they cost and what they (hopefully) imply about the care taken. They're arguably as much a first-screen for new CAs as anything

\n
\n

Right. If UAs start accepting MTC roots without any audit requirements, then you're gonna get a whole bunch of people showing up with an MTC root that they run off their gaming PC, asking to be included in the UA's trust store.

\n

UAs will need _some_ transparent criteria for deciding which MTCs are \"well-run\". You need definitions of \"well-run\" and a way to go check that their system actually does the things they claim, which quickly turn into Audit Requirements and an army of Auditors.

\n

If MTC isn't going to go with WebTrust, fine. But I would love for someone to give a presentation about what you're planning to replace it with.

", "time": "2026-03-16T09:17:19.000Z"}, {"author": "Filippo Valsorda", "text": "

(You could argue that a malicious CDN/host also undermines the security of the WebPKI, similarly)

", "time": "2026-03-16T09:17:50.000Z"}, {"author": "Bas Westerbaan", "text": "

@Mike Ounsworth I think it's not IETF's decision to make.

", "time": "2026-03-16T09:18:45.000Z"}, {"author": "Mike Ounsworth", "text": "

Bas Westerbaan said:

\n
\n

Mike Ounsworth I think it's not IETF's decision to make.

\n
\n

Never claimed it was. I am asking as a concerned member of the public.

", "time": "2026-03-16T09:19:08.000Z"}, {"author": "Devon O'Brien", "text": "

@Mike Ounsworth That feels like a valuable exercise once we're confident that major design changes have settled down. WTTF took 8 years to produce a slightly more valuable audit report that was begged for by browser/OS vendors when everything was already defined, for example

", "time": "2026-03-16T09:19:25.000Z"}, {"author": "Bas Westerbaan", "text": "

Yes, something to keep in mind. But IETF is the current forum.

", "time": "2026-03-16T09:19:33.000Z"}, {"author": "Bas Westerbaan", "text": "
\n

Right. If UAs start accepting MTC roots without any audit requirements,

\n
\n

Root programs have agency here.

", "time": "2026-03-16T09:21:29.000Z"}, {"author": "Martin Thomson", "text": "

if you have N verifiable index operators and you are taking min() across all their counts, does that not make it possible for a misbehaving verifiable index operator to block updates from others?

", "time": "2026-03-16T09:24:57.000Z"}, {"author": "Filippo Valsorda", "text": "

The easiest solution here would be to have a Vindex per MTC CA

", "time": "2026-03-16T09:25:05.000Z"}, {"author": "Dennis Jackson", "text": "

I'm sort of confused as to why the 'trusted vindex operator designation' isn't the root program operator.

", "time": "2026-03-16T09:25:16.000Z"}, {"author": "Martin Thomson", "text": "

I'm not sure if root program operators fit into this. Are we really interested in providing a lookup table?

", "time": "2026-03-16T09:25:59.000Z"}, {"author": "Robert Moskowitz", "text": "

client certs may cause the MT to blow up?

", "time": "2026-03-16T09:26:43.000Z"}, {"author": "Deirdre Connolly", "text": "

can victor mute when not speaking

", "time": "2026-03-16T09:26:44.000Z"}, {"author": "Jonathan Lennox", "text": "

Is there CT for client certs today?

", "time": "2026-03-16T09:26:52.000Z"}, {"author": "Bas Westerbaan", "text": "

Jonathan Lennox said:

\n
\n

Is there CT for client certs today?

\n
\n

Not on purpose

", "time": "2026-03-16T09:27:16.000Z"}, {"author": "Filippo Valsorda", "text": "

Defining the leaf type for index tree heads lets us make decisions on who runs the index later

", "time": "2026-03-16T09:27:28.000Z"}, {"author": "Martin Thomson", "text": "

I think that client certs are rare enough that this is workable. If the size gets too much because one CA is issuing too many client certs, then they can attempt mitosis.

", "time": "2026-03-16T09:27:29.000Z"}, {"author": "Dennis Jackson", "text": "

Client certs are already split out to different hierarchies

", "time": "2026-03-16T09:27:45.000Z"}, {"author": "Michael Richardson", "text": "

So, client-certs have many issues, and I think the challenge is the business model for co-signers. More to the point, what about code signing certificates.

", "time": "2026-03-16T09:27:49.000Z"}, {"author": "Filippo Valsorda", "text": "

It's also good that we can ship MTC with CT-like monitoring to get the PQ benefits and then iterate/experiment with efficient monitoring without blocking the PQ transition

", "time": "2026-03-16T09:28:16.000Z"}, {"author": "Martin Thomson", "text": "

Verifiable index operations for client certs probably isn't going to fly...

", "time": "2026-03-16T09:28:16.000Z"}, {"author": "Martin Thomson", "text": "

The question is whether we think that something like efficient lookups are an essential part. It seems like it doesn't need to be.

", "time": "2026-03-16T09:29:30.000Z"}, {"author": "Dennis Jackson", "text": "

image.png
\nTrust relationships in transparency ecosystems :-)

\n
", "time": "2026-03-16T09:29:41.000Z"}, {"author": "Dennis Jackson", "text": "

Martin Thomson said:

\n
\n

The question is whether we think that something like efficient lookups are an essential part. It seems like it doesn't need to be.

\n
\n

I think 'solvable later' is how I would describe it

", "time": "2026-03-16T09:30:03.000Z"}, {"author": "Devon O'Brien", "text": "

@Dennis Jackson
\nimage.png
\nFTFY

\n
", "time": "2026-03-16T09:30:36.000Z"}, {"author": "Filippo Valsorda", "text": "

yeah I think we have iterative operational learning to do on efficient monitoring, like we learned a lot about log operation in the last 10 years (and MTC distills that)

", "time": "2026-03-16T09:30:57.000Z"}, {"author": "Bas Westerbaan", "text": "

@John Gray Very happy to sit down and write a \"MTC in private PKIs\" document with you or anyone else!

", "time": "2026-03-16T09:33:24.000Z"}, {"author": "Bas Westerbaan", "text": "

(Also think a separate document is better fit than architecture doc)

", "time": "2026-03-16T09:33:59.000Z"}, {"author": "Bas Westerbaan", "text": "

(But both need to be started now)

", "time": "2026-03-16T09:34:04.000Z"}, {"author": "Mike Ounsworth", "text": "

I'll +1 myself to help on a \"MTC for Private PKI\" doc

", "time": "2026-03-16T09:34:34.000Z"}, {"author": "John Gray", "text": "

@Bas - sounds good... I started a discussion about a few places where I think it can be used.

", "time": "2026-03-16T09:34:51.000Z"}, {"author": "Robert Moskowitz", "text": "

I should at least review this. We have lots of private PKI in aviation.

", "time": "2026-03-16T09:35:05.000Z"}, {"author": "John Gray", "text": "

Based on David's question about architecture document items...

", "time": "2026-03-16T09:35:15.000Z"}, {"author": "Robert Moskowitz", "text": "

We just published ICAO DOC 10169 for the certificate policy profile and we are already reving it for PQC.

", "time": "2026-03-16T09:35:57.000Z"}, {"author": "John Gray", "text": "

@Bas - Yes, probably eventually a separate document is better... But pulling out pieces like the MTC structure, landmarks and subtrees and inclusion proofs from the core document (or architecture document if stuff gets moved there).

", "time": "2026-03-16T09:37:41.000Z"}, {"author": "Devon O'Brien", "text": "

One of the conversations/presentations/docs we owe the WG is a better explanation of the mappings of X.509 PKI today to landmark-less MTCs. They're a lot closer together than many realize, which helps frame conversations like private PKI use cases.

", "time": "2026-03-16T09:37:41.000Z"}, {"author": "Jan Klau\u00dfner", "text": "

I am also interested in MTC for Private PKI, willing to help

", "time": "2026-03-16T09:37:49.000Z"}, {"author": "Devon O'Brien", "text": "

Notably, the MTC parameters that Luke discusses are tunable (landmark cadence, effective cert lifetime, etc), but the major ones require consensus among the MTC relying parties and cannot be easily changed on the fly.

", "time": "2026-03-16T09:40:27.000Z"}, {"author": "Michael Richardson", "text": "

So, MTC is a win, even if we never have to go quantum-safe.
\nThat's really a good result.

", "time": "2026-03-16T09:40:43.000Z"}, {"author": "Filippo Valsorda", "text": "

It is also a major win in CT scalability and cost

", "time": "2026-03-16T09:41:06.000Z"}, {"author": "John Gray", "text": "

@Devon, yes, distill it down to most simple implementation... Also I think there are huge potential performance gains in revocation.

", "time": "2026-03-16T09:41:06.000Z"}, {"author": "John Gray", "text": "

... Revocation is still needed for Private PKI... Private Identities usually last longer than 7 days.... :)

", "time": "2026-03-16T09:41:42.000Z"}, {"author": "Bas Westerbaan", "text": "

Revocation is orthogonal to MTC.

", "time": "2026-03-16T09:42:12.000Z"}, {"author": "Dennis Jackson", "text": "

This slide says 'clients' where it probably should say 'browsers' :-)

", "time": "2026-03-16T09:42:27.000Z"}, {"author": "Filippo Valsorda", "text": "

But MTC makes strategies like Clubcards faster and easier

", "time": "2026-03-16T09:42:39.000Z"}, {"author": "Deirdre Connolly", "text": "

:tada:

", "time": "2026-03-16T09:43:28.000Z"}, {"author": "David Benjamin", "text": "

The realization that entry index should just be the serial number, and how well that matches revocation expectations, was a major lightbulb when we figured that out.

", "time": "2026-03-16T09:43:55.000Z"}, {"author": "Mike Ounsworth", "text": "

Devon O'Brien said:

\n
\n

One of the conversations/presentations/docs we owe the WG is a better explanation of the mappings of X.509 PKI today to landmark-less MTCs. They're a lot closer together than many realize, which helps frame conversations like private PKI use cases.

\n
\n

YES! I am extremely interested in this, and it sounds like the bases for the \"MTC in Private PKI\" discussion!

", "time": "2026-03-16T09:43:56.000Z"}, {"author": "Bas Westerbaan", "text": "

Experiment currently is only on QUIC. That'll filter out a bunch of Enterprise interception

", "time": "2026-03-16T09:44:18.000Z"}, {"author": "James Howe", "text": "

Is MTC more tailored because of ML-DSA or would you still see benefits even using an isogeny or multivariate signature scheme?

\n

(sorry I would ask this on the mic but the airport wifi is not good)

", "time": "2026-03-16T09:44:22.000Z"}, {"author": "Bas Westerbaan", "text": "

James Howe said:

\n
\n

Is MTC more tailored because of ML-DSA or would you still see benefits even using an isogeny or multivariate signature scheme?

\n

(sorry I would ask this on the mic but the airport wifi is not good)

\n
\n

SQISign is still way too slow. Multivariate will not be ready in time.

", "time": "2026-03-16T09:44:48.000Z"}, {"author": "Dennis Jackson", "text": "

Bas Westerbaan said:

\n
\n

Experiment currently is only on QUIC. That'll filter out a bunch of Enterprise interception

\n
\n

Ah.

", "time": "2026-03-16T09:44:59.000Z"}, {"author": "Filippo Valsorda", "text": "

There is nothing algorithm-specific. MTC reduces the count of signatures, so it benefits most large signatures, but CF is showing how it helps even with smaller classical signatures.

", "time": "2026-03-16T09:45:13.000Z"}, {"author": "Mike Ounsworth", "text": "

Filippo Valsorda said:

\n
\n

It is also a major win in CT scalability and cost

\n
\n

Outside of Web, private PKIs don't run CT today. So I'm personally more interested in performance comparisons with PKIs that don't today do CT.

", "time": "2026-03-16T09:45:30.000Z"}, {"author": "Filippo Valsorda", "text": "

I said \"also\" :)

", "time": "2026-03-16T09:45:44.000Z"}, {"author": "Bas Westerbaan", "text": "

Mike Ounsworth said:

\n
\n

Filippo Valsorda said:

\n
\n

It is also a major win in CT scalability and cost

\n
\n

Outside of Web, private PKIs don't run CT today. So I'm personally more interested in performance comparisons with PKIs that don't today do CT.

\n
\n

There is value to some transparency even for private PKIs as it'll help against downgrade attacks.

", "time": "2026-03-16T09:45:52.000Z"}, {"author": "Bas Westerbaan", "text": "

Something to discuss in the new document :)

", "time": "2026-03-16T09:46:09.000Z"}, {"author": "Filippo Valsorda", "text": "

(I go over those in my presentation :))

", "time": "2026-03-16T09:46:13.000Z"}, {"author": "Joe DeBlasio", "text": "

(it does indeed do diffing things)

", "time": "2026-03-16T09:46:36.000Z"}, {"author": "Jonathan Lennox", "text": "

Does this make the problems with certs for computers with wildly off clocks any worse than it already is?

", "time": "2026-03-16T09:47:59.000Z"}, {"author": "Bas Westerbaan", "text": "

Jonathan Lennox said:

\n
\n

Does this make the problems with certs for computers with wildly off clocks any worse than it already is?

\n
\n

If you have landmarks sent to you, you have a clock

", "time": "2026-03-16T09:48:15.000Z"}, {"author": "Dennis Jackson", "text": "

Jonathan Lennox said:

\n
\n

Does this make the problems with certs for computers with wildly off clocks any worse than it already is?

\n
\n

7 day certs may well cause problems - independently of MTC.

", "time": "2026-03-16T09:48:34.000Z"}, {"author": "Jens-Rene Giesen", "text": "

mic 1 is very low on volume, is it just me?

", "time": "2026-03-16T09:48:47.000Z"}, {"author": "Devon O'Brien", "text": "

At the very least you have a clock-shaped ratchet.

", "time": "2026-03-16T09:48:53.000Z"}, {"author": "Bas Westerbaan", "text": "

7 days is not a strict requirement. These are knobs that can be turned.

", "time": "2026-03-16T09:48:58.000Z"}, {"author": "Deb Cooley", "text": "

They turned the gain down in the room because of the echo

", "time": "2026-03-16T09:49:08.000Z"}, {"author": "Mike Ounsworth", "text": "

Dennis Jackson said:

\n
\n

Jonathan Lennox said:

\n
\n

Does this make the problems with certs for computers with wildly off clocks any worse than it already is?

\n
\n

7 day certs may well cause problems - independently of MTC.

\n
\n

Also orthogonal to the core MTC design, right? You _could_ issue 10 year employee ID cards off an MTC, you'd just need to tune it differently?

", "time": "2026-03-16T09:49:28.000Z"}, {"author": "Deb Cooley", "text": "

This is literally the only speaker we have had that is in the room.

", "time": "2026-03-16T09:49:32.000Z"}, {"author": "Lorenzo Miniero", "text": "

@Deb Cooley just raised the gain

", "time": "2026-03-16T09:49:49.000Z"}, {"author": "Jens-Rene Giesen", "text": "

thank you!

", "time": "2026-03-16T09:49:58.000Z"}, {"author": "Lorenzo Miniero", "text": "

We'll check if this causes echo

", "time": "2026-03-16T09:50:03.000Z"}, {"author": "Bas Westerbaan", "text": "

@Mike Ounsworth Yes, but... given migration timelines you probably want to be able to update certificates faster than in ten years.

", "time": "2026-03-16T09:50:46.000Z"}, {"author": "Bas Westerbaan", "text": "

Doesn't mean it needs to go down to 7 days, but 10 years...

", "time": "2026-03-16T09:50:58.000Z"}, {"author": "Devon O'Brien", "text": "

10 years is a heck of a lot of MTC client-side state :)

", "time": "2026-03-16T09:51:37.000Z"}, {"author": "Dennis Jackson", "text": "

30 days feels uncomfortably long

", "time": "2026-03-16T09:51:37.000Z"}, {"author": "Bas Westerbaan", "text": "

Devon O'Brien said:

\n
\n

10 years is a heck of a lot of MTC client-side state :)

\n
\n

With very few landmarks it could be done, but uh, not how it was designed.

", "time": "2026-03-16T09:53:12.000Z"}, {"author": "Mike Ounsworth", "text": "

@Bas, sure, 10 years is maybe hyperbole, but not completely insane for physical things like building access cards, IDevID certs on networking equipment that is likely to sit in a cardboard box for many years before being powered on the for first time, etc. TL;DR: Private PKI has complexities that are very different from the complexities of Web PKI.

", "time": "2026-03-16T09:53:12.000Z"}, {"author": "Robert Moskowitz", "text": "

And aircraft avionics.

", "time": "2026-03-16T09:53:47.000Z"}, {"author": "Dennis Jackson", "text": "

@Mike Ounsworth - What Filippo is sketching might be a more comfortable fit

", "time": "2026-03-16T09:54:18.000Z"}, {"author": "David Benjamin", "text": "

You also don't have to use landmark certificates if their parameters don't fit your application.

", "time": "2026-03-16T09:54:27.000Z"}, {"author": "Deirdre Connolly", "text": "

in the 10 years case do we need to fast forward through 10 years of log

", "time": "2026-03-16T09:54:56.000Z"}, {"author": "Richard Barnes", "text": "

this seems like quite a degenerate case

", "time": "2026-03-16T09:55:39.000Z"}, {"author": "Jonathan Lennox", "text": "

It would be amusing if this degenerate case could actually be bit-identical to the current case, but it probably can't be.

", "time": "2026-03-16T09:56:29.000Z"}, {"author": "David Benjamin", "text": "

It needs to at least still have the subtree coordinates to tell you it's the degenerate case. And cosigner IDs to say which signer did it (e.g. for this key rotation idea).

", "time": "2026-03-16T09:57:09.000Z"}, {"author": "Devon O'Brien", "text": "

David Benjamin said:

\n
\n

You also don't have to use landmark certificates if their parameters don't fit your application.

\n
\n

This is an important observation when thinking about less commonly-shaped PKIs. While you lose the specific benefits of landmark certificates, everything else can be MTC shaped if desired, enabling economies of scale in implementation, operation, audits if we still do that. See previous remark about owing y'all a doc, but Filippo's presentation is doing much of this work as we speak.

", "time": "2026-03-16T09:57:17.000Z"}, {"author": "Luke T", "text": "

Is the plan to standardise the individual components of MTC separately so people can just do standalone certs in their PKI for example? (or however much MTC they want to do)

", "time": "2026-03-16T09:58:02.000Z"}, {"author": "Bas Westerbaan", "text": "

@Luke T Current plan (in the charter) is to start with the whole thing for the WebPKI usecase. And we can profile it down later in separate docs.

", "time": "2026-03-16T09:58:33.000Z"}, {"author": "Luke T", "text": "

Thanks Bas!

", "time": "2026-03-16T09:58:53.000Z"}, {"author": "David Benjamin", "text": "

The document is also already structured to say \"oh yeah you can use this if you want\" and \"oh you decide what kind of cosigners you want\". But it's not so great right now for helping you realize this is possible.

", "time": "2026-03-16T09:59:17.000Z"}, {"author": "Bas Westerbaan", "text": "

(@Luke T Let us know if you want to be involved.)

", "time": "2026-03-16T09:59:17.000Z"}, {"author": "Robert Moskowitz", "text": "

I got to split. Interesting and I want to follow private PKI MTC.

", "time": "2026-03-16T09:59:17.000Z"}, {"author": "David Benjamin", "text": "

(But maybe the architecture doc will help there!)

", "time": "2026-03-16T09:59:31.000Z"}, {"author": "Mike Ounsworth", "text": "

Also, and maybe this is a point for the @Chairs, while I care about Private PKI much more than Web PKI, it's possible that making MTC fit the long-tail of X.509 use cases this will lead to boiling the ocean, and this WG could consider chartering this down to only consider Web PKI.

", "time": "2026-03-16T09:59:50.000Z"}, {"author": "Dennis Jackson", "text": "

Mike Ounsworth said:

\n
\n

Also, and maybe this is a point for the @Chairs, while I care about Private PKI much more than Web PKI, it's possible that making MTC fit the long-tail of X.509 use cases this will lead to boiling the ocean, and this WG could consider chartering this down to only consider Web PKI.

\n
\n

I think this was already done :-)

", "time": "2026-03-16T10:00:05.000Z"}, {"author": "John Gray", "text": "

Wouldn't the subtree size one still require the full signature to be fetched? I think subtree of higher sizes would be more efficient.

", "time": "2026-03-16T10:00:13.000Z"}, {"author": "Dennis Jackson", "text": "

So the private PKI is very much 'if it fits' / opportunistic. But I think it fits well!

", "time": "2026-03-16T10:00:25.000Z"}, {"author": "Martin Thomson", "text": "

John Gray said:

\n
\n

Wouldn't the subtree size one still require the full signature to be fetched? I think subtree of higher sizes would be more efficient.

\n
\n

Oh, it would be quite inefficient.

", "time": "2026-03-16T10:00:28.000Z"}, {"author": "John Gray", "text": "

But this is a good start of thinking about how it can work!

", "time": "2026-03-16T10:00:28.000Z"}, {"author": "Deb Cooley", "text": "

good job!

", "time": "2026-03-16T10:00:33.000Z"}, {"author": "Deirdre Connolly", "text": "

good job @Thom Wiggers

", "time": "2026-03-16T10:01:05.000Z"}, {"author": "Deirdre Connolly", "text": "

(and @Russ Housley but he's pro)

", "time": "2026-03-16T10:01:17.000Z"}, {"author": "Filippo Valsorda", "text": "

@Mike Ounsworth Yeah to be clear I am not saying we should make MTC more complicated to cater to Private PKIs, but MTC as designed already allows these affordances, so I wanted to highlight them

", "time": "2026-03-16T10:01:21.000Z"}, {"author": "John Gray", "text": "

Thanks everyone!

", "time": "2026-03-16T10:01:31.000Z"}]