[Plants] Re: Scope and charter

[David Benjamin <[e-mail]>]

On Wed, Aug 13, 2025 at 12:43 PM Michael Richardson <[e-mail]>
wrote:

> David Benjamin <[e-mail]> wrote:
>     > On other use cases, I think it’s important to keep the scope at
> transparent
>     > PKIs, as so many requirements come from that. Other cultivars
> (private PKIs
>     > and IoT came up) may partially overlap, sow it can make sense to
> consider
>     > them, but their exact requirements and limitations will be different.
>
> private PKIs aren't a uniform, distinct thing.
> The only thing they have in common is that they aren't installed by default
> in /etc/ssl/certs.   Beyond that, there is more overlap with some WebPKIs
> than
> there are differences.
> Enterprise private PKIs have the most in common, perhaps.
> And quite possibly have even *MORE* need for additional mechanism around
> revocation.
>
> Even *IoT* PKIs are not distinct, as IoT is a marketing, and not technical
> term.
> Today, most IoT PKIs are about identifying the devices by the cloud.
> (Because, most IoT today, are device to cloud, as a private vertical)
> The device to cloud trust is far too often consisting of pinning the public
> key of the cloud, no indirection at all.  Often *literally* curl --cacert.
> (It makes me very sad)
>

Oh certainly. My point was less to exclude private PKIs or IoT cases and
more trying to be clear on what problem space we are and aren't targeting.
The shape of your PKI will depend heavily on the requirements of your
application, specifically how connectivity looks like between the players
in the system. (I can't claim credit for this insight. It was part of Ryan
Sleevi's saag presentation at IETF 109. The insight that PKI design follows
the connectivity model really stuck with me.)

Let's take revocation as an example:

On the Web, the Web's RP <-> CA connectivity is nonexistent. We cannot
assume that RPs can talk to CAs, CAs usually cannot handle the load that
the Web's scale produces, and there are privacy constraints on pinging a
third party that is affiliated with neither the website the user's visiting
nor the user agent. RPs in the Web can, kinda by construction, assume
connectivity to the server they're *currently* talking to, at (and only at)
the time they are trying to talk to the server. They often can ping their
software vendor periodically in the background, but cannot guarantee
connectivity, especially at the time of an actual connection. And then both
communication paths are limited by their own privacy constraints.

That connectivity model means, *specifically on the Web*, RPs fetching
CA-hosted CRLs or OCSP responses is not viable. Instead, our revocation
solutions that look more like:

1. Short-lived certificates and their equivalents: The only way to tightly
upper bound on the revocation delay is expiry of the server payload. One
way or another, *something* that the server hands the client *must* be
bounded to our target revocation delay, with the server <-> CA channel
(i.e. how good is your automation) being the main limiting factor today.

2. Out-of-band revocation lists like CRLite and CRLsets: We can, best
effort, have the software vendor push down revocation information. This is
bounded by how well the RP can actually get updates, and how compactly we
can represent the universe of revocations before they expire (ties into
cert lifetime above).

Again, that was specifically for the Web. Other applications might look
very different. Perhaps in some other application, your servers have poor
CA connectivity (e.g. poor server <-> CA automation), but your clients have
good connectivity to a commercial CA, e.g. because these are all clients on
some enterprise network. And perhaps, at the scale of that
application's PKI, the CA is able to and maybe even better than the
enterprise at hosting things. In that environment, online OCSP checks
perhaps *are* a better answer over short-lived certificates.

That's why we don't see one-size-fits-all PKIs. They depend on
requirements. When we try to force the PKI to be one-size-fits-all, things
don't work well. I think it's key that our solutions are clear on the
problem space that they are good for. Then applications can decide whether
they are a good fit for them, or whether they should go with a slightly
different model.

Now, back to the problem at hand. Here, the transparency requirement is
both the cause and solution to our problems. The PQ overhead is especially
pronounced when you need to carry signatures from extra entities like logs.
But the opportunity to do clever things with Merkle Trees naturally falls
out of needing to build these anyway. And thus I think that's the right
space for this work to target. That's not to say this is a Web-only
solution. (The draft charter tries to avoid saying "Web".) The Web is just
the prototypical application with this shape of requirement.

Whether that fits "private PKI" depends on your private PKI. "Private
PKIs", as you say, are not uniform. It's a really vague term that tends to
just mean "everything else". I would imagine that some private PKIs have a
lot in common with this problem space, and some do not:

* Perhaps you're a commercial CA and operate a private PKI on behalf of a
customer, may you *do* want auditability! Perhaps you would use something
like MTCs to log everything you sign, and publish it, not publicly, but to
your customer. Then you could tell the customer, "look, you are trusting me
with all your authentication, but I've chosen to use a certificate design
that guarantees things are in this log, that I will publish to you to
audit."

* Or perhaps you're self-hosting your private PKI for, I dunno, jobs in a
data center, so you trust the CA. But maybe you want some assurance against
your CA machines getting compromised, and want to use the append-only log
as a defense against that.

* Or perhaps all this is too much operational overhead for your private
PKI, and you are perfectly happy shipping one signature from CA over the
TBSCertificate and moving on with life. Then you don't really care about
this.

Relating to scope here, I briefly mentioned in the secdispatch talk that I
think we should try to separate the certificate construction from the
details of the transparency ecosystem. I think that can help more
applications make use of this work:

Consider the question of who serves the log. On the Web, we have CT logs
that host logs at the scale and bandwidth needed for this scale. Asking
every CA to durably host at that scale would be a significant shift in
responsibilities. And so I think, for the Web, a model where the cosigners
are mirrors <https://c2sp.org/tlog-mirror> makes a lot of
sense. Conversely, in that first hypothetical private PKI use case,
probably the customer is *not* up to do that hosting, while the CA is
already providing a service to host stuff. There, mirror cosigners may be
less appropriate, but perhaps the customer, or some other service,
operates witness
cosigners <https://c2sp.org/tlog-witness> that just enforce
append-only-ness.

The MTC draft is currently intentionally flexible about the cosigner model.
While not so important for any one use case (we could just write down the
appropriate model), I think it would be valuable as a general building
block to preserve that.


>     > I
>     > think we need a clear scope to keep the WG focused on its primary
>     > deliverables. If this is useful for private PKIs, as-is or with a
> secondary
>     > document, great! If private PKIs are better served with a separate
> design,
>     > perhaps with inspiration from our work, that’s fine too.
>
> My impression is that operating private PKIs on behalf of Enterprises and
> PKI-verticals is among the more profitable sides of current commercial
> certification authorities.   Were I in that space, I'd insist that I use
> exactly the same tools and workflows.   Or in other words: the private PKI
> is
> what is going to pay for developing and deploying the WebPKI side of
> things.
> I could be wrong.
>
>     > On size, obviously handshake size is a focus, but I think log size
> is also
>     > important. Given CT today, I wouldn’t say it’s “untenable”. But
> based on
>     > those deployments, many costs scale with log size. Fortunately, we
> have a
>     > good solution. I sampled today’s CT logs and estimated corresponding
> MTC
>     > entries. Even with today’s algorithms, MTC takes *one tenth* the
> size of
>     > today’s entries, gzipped. Simulating a naive transition to
> ML-DSA-44, MTC
>     > saves *50x*.
>
> This belongs in the appendix of the architecture document.
>
>     > There was a comment that the status quo’s security/transparency
> properties
>     > are too low of a bar. I don’t think we should discard all that’s
> been built
>     > thus far. The CT of today exists, and has been incredibly valuable
> for the
>     > Web PKI. We thus should at least be comparable to its current
> properties.
>     > The charter mentions finding ways to improve on them, but I do not
> think we
>     > should pre-commit the WG into solving research problems where we
> have no
>     > viable approach today.
>
> I never see CT do anything today.
> That might be extremely good news, that's working.
> I would find it hard to argue with C* that CT is doing anything.
> Again, I'm not saying that it's not.  I'm saying that it's invisible, and
> my
> impression is that this work will probably make it more visible.
>

Over in the Web space, I think one can unreservedly say that CT has done
quite a lot today. :-)


>     > To avoid getting too down in the weeds, lettuce get the core of the
> system
>     > down first.
>
>     > A peony for your thoughts,
>
> oh, the punny.  My black-eye's are susaning water.  Can we keep it up?
>
> --
> ]               Never tell me the odds!                 | ipv6 mesh
> networks [
> ]   Michael Richardson, Sandelman Software Works        |    IoT
> architect   [
> ]     [e-mail]  http://www.sandelman.ca/        |   ruby on
> rails    [
>
>
>
>