Skip to content

reword goals #123

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
mcr wants to merge 1 commit into from
Closed

reword goals #123

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion charter-ietf-plants.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@ This is a draft charter for a new IETF working group. The working group does not

## PKI, Logs, And Tree Signatures (PLANTS)

The goal of the PLANTS Working Group is to trim the costs of large post-quantum signatures on PKIs with Certificate Transparency (CT; RFC 6962 and RFC 9162), when used in interactive protocols like TLS (RFC 8446).
The goal of the PLANTS Working Group is to rethink the tradeoffs between certificate signatures and Transparency Logs. This is driven the size and performance of quantum-safe algorithms. The initial focus of the WG is on PKIs that use Certificate Transparency (CT; RFC 6962 and RFC 9162), with interactive protocols like TLS (RFC 8446) and IKEv2 (RFC7296)

@bwesterb bwesterb Aug 13, 2025

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This "tradeoff" doesn't type-check for me, do you perhaps mean trading transparency against performance? Or did you mean "rethink division of tasks between certificate authorities and transparency logs"?

@mcr mcr Aug 13, 2025

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

okay, so maybe some words are missing here.
certificates cost bytes and CPU.
transparency logs cost bytes and CPU.
Quantum-safe algorithms change the values, and thus the tradeoffs.

@bwesterb bwesterb Aug 13, 2025 •
edited
Loading

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are any IKEv2 peers enforcing transparency?

@mcr mcr Aug 13, 2025

Copy link
Copy Markdown
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are any IKEv2 peers enforcing transparency?

Not today. Many think that's a bug.
They are "private" PKIs, and CT cost too much, required a third party, and there are usually cheaper ways to kill clients. But, CRLs do exist and also OCSP, and they have all the problems.

@davidben davidben Aug 13, 2025

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm. I am quite wary of the WG taking on too broad and open-ended of a scope.

It's certainly good to make things reusable. While, I don't know much about IKEv2, it does seem plausible that any solution here would also apply to IKEv2. And indeed I wrote "interactive protocols" to try to capture the property of TLS that matters here. (I.e. room to build a negotiation story. The signatureless certificates optimization really wants the authenticating party to tailor the certificate to the relying party, e.g. with trust anchor negotiation. By contrast, something like offline encryption needs to send a payload that works for all recipients at once, making most size optimizations moot.)

At the same time, I think if we try to solve all of PKI all at once, we won't get anywhere. Different applications do ultimately have different needs. Trying to address them in the abstract won't help the WG make decisions. In TLS, we have a lot to fall onto to guide our decisions: real world deployments of CT today, and work around certificate negotiation.

I think progress would be best served to focus on that, while keeping an eye towards generality. Then when the IKEv2 community is ready to think about what transparent PKIs mean for them, they'll have something concrete to look at and hopefully apply.

@davidben davidben Aug 13, 2025

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And if the IKEv2 community is ready to build out a transparent PKI while this work is ongoing, there's nothing stopping the WG from discussing other use cases then. But I don't think the charter should commit us to doing something for IKEv2 prematurely.


Today, such applications apply two separate systems: a certification authority (CA) signs individual bindings between public keys and application identifiers (e.g. a DNS name), returning an X.509 certificate. CT logs then log entire certificates, returning signed certificate timestamps. The outputs of these two steps are presented to the relying party.

Expand Down