[Plants] Re: Scope and charter

["Kampanakis, Panos" <[e-mail]>]

By state of the webPKI, I meant CRLs, CRLite, cached OCSP (if it was ever used), SCT signers, trust anchors or abdridged certs, MTC co-signers, or MTC landmark checkpoints. Browser and similar apps make a lot of calls to their backend where they can do all of these things, but some of the applications I am talking about have just the OS, the SDK and whatever app code the user has written on top.

Let me show why I am sticking to the specifics of the solution and what it is for as laid out in the charter by asking a question: A draft defining TimestampedCertificateEntryDataV3 which compresses the contents of an ML-DSA TBSCertificate would address one of the main issues MTC is aiming to address. Would it fall in the PLANTS charter?

From: David Benjamin <[e-mail]>
Sent: Thursday, August 21, 2025 11:48 AM
To: Kampanakis, Panos <[e-mail]>
Cc: Stephen Farrell <[e-mail]>; Wendy Brown - QT3LB-C <[e-mail]>; Thom Wiggers <[e-mail]>; Michael Richardson <[e-mail]>; [e-mail]
Subject: RE: [EXTERNAL] [Plants] Re: Scope and charter


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.

On Thu, Aug 21, 2025 at 10:39 AM Kampanakis, Panos <[e-mail]<mailto:[e-mail]>> wrote:
> Not sure, but I can live with the above FWIW - I'm sure if we do something that causes breakage, we'll hear about that;-)

I would go further than email uses of TLS. Basically, any place where you cannot stand up and operate an always-on CT type of service or places that work over a browser along with other non-browser non-constantly updating clients. There are many of those.

It would be nice for the charter to document this clearly beyond just saying that it will focus on the web and other PKIs are nice to have. Maybe it would be beneficial to define WebPKI. For example, https://cloud.google.com/sdk clients connect to TLS servers using WebPKI certs but they are not exactly the web. These clients don't fetch and show what we know as web content and they don't maintain the "state of WebPKI" like a browser does. Are these the web?

I'm not sure what you're referring to. The word "web" does not appear at all in the draft charter. I don't believe it has appeared in any version of that text.
https://github.com/davidben/merkle-tree-certs/blob/main/charter-ietf-plants.md

With quite a lot of experience on browser PKI concerns, I also do not know what it means to 'maintain the "state of WebPKI" like a browser does'. Are you referring to the list of trust anchors? That's not specific to web browsers. That's a fundamental part of configuring X.509. If you're referring to the extra state needed for signatureless optimization, that hasn't been required in any version of MTC. In the first version, the whole scheme was meant to be paired with a fallback. In the current version, the fallback is integrated (two views of the same log entry). Even within the web browser use case, we cannot assume every client is up-to-date, so this would always have been necessary.

I think this confusion shows the dangers of trying to prescribe this level of detail in a charter. We end up working off of our own internal assumptions about what the design is, finding something we want to change or not change, and then reversing that back into abstract charter-level guidance. We'll inevitably talk in circles doing that, because we're not really talking about the same thing.

Let's get the charter-level things down, and then we can all get on the same page with something concrete and discuss.

David

-----Original Message-----
From: Stephen Farrell <[e-mail]<mailto:[e-mail]>>
Sent: Thursday, August 21, 2025 10:22 AM
To: David Benjamin <[e-mail]<mailto:[e-mail]>>; Wendy Brown - QT3LB-C <[e-mail]<mailto:[e-mail]>>
Cc: Thom Wiggers <[e-mail]<mailto:[e-mail]>>; Michael Richardson <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>
Subject: [EXTERNAL] [Plants] Re: Scope and charter

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.



Hiya,

On 21/08/2025 13:38, David Benjamin wrote:
> The charter already has this sentence, that was meant to capture this:
>
> "The Working Group may consider how these mechanisms may apply to
> other PKIs or non-interactive protocols, but these will not be the
> primary use case and may ultimately have different requirements or limitations."
>
> Do you think it needs some tweaks?

Not sure, but I can live with the above FWIW - I'm sure if we do something that causes breakage, we'll hear about that;-)

>
>> I would like that we at least consider how what we're doing
> would work-for/break the use of TLS in email protocols.
>
> Is there a concrete shape of breaking things for email that you are
> concerned about?

Nope. I guess the extent to which clients depend on browser updates might cause some issue for SMTP/TLS as sending MTAs don't have the same update frequency, and maybe IMAP/SUBMIT servers might have a much longer tail of older clients, but I'd imagine there should be ways to get around such things, or else it'd be fine with just have such setups stick with their current PKI setups and/or someone spends time thinking about how PLANTS affects DANE/MTA-STS etc and figures things out.

> It's quite hard to abstractly reason about why email warrants a
> specific mention. Note that the charter does not say the word "Web" in
> it at all (I took some effort to *not* be Web-specific), so calling
> out email seems extra odd.
>
> I also don't think we need to codify every single design question
> ahead of time in the charter. It's to form an IETF working group, not
> some last chance to nudge an opaque process. If one wants to consider
> some application, there is an easy way to do it: go consider it and
> bring thoughts to the WG! :-) if some concrete detail turns out to be
> a problem for some concrete application, we can use the usual IETF
> process to talk about it and decide where we want to go from there.
>
> I expect that'll be much easier for everyone in concretely than in the
> abstract. Let's try to get to that concrete stage quickly.

Agreed.

Cheers,
S.