reword goals - #123
Conversation
| ## 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) |
There was a problem hiding this comment.
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"?
There was a problem hiding this comment.
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.
| ## 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) |
There was a problem hiding this comment.
Are any IKEv2 peers enforcing transparency?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
Closing since the charter is being tracked elsewhere now. |
3 participants
No description provided.