Conversation
| Though not the initial focus, the PLANTS Working Group may consider other properties of transparent PKIs to improve upon the status quo, such as auditing, monitoring, or revocation. If feasible concrete improvements are identified, the Working Group may recharter to seed secondary deliverables that build on its initial work. | ||
|
|
||
| In evaluating decisions and design tradeoffs, the Working Group will consider security, privacy, transparency, performance, and deployment properties, aiming to comparably meet the needs of today's applications that use CT-based PKIs with TLS. 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. | ||
| In evaluating decisions and design tradeoffs, the Working Group will consider security, privacy, transparency, performance, and deployment properties, aiming to comparably meet the needs of today's applications that use CT-based PKIs with TLS. The Working Group may consider and explain how these mechanisms could be adapted for deployment in a private or limited scope PKI as a secondary use case. |
There was a problem hiding this comment.
This does lose "may ultimately have different requirements or limitations", which was meant to capture that, yes, it is OK if we decide that this particular shape of private PKI is not relevant. We do not have to solve everything. I suppose this is implicit from "may". 🤷
It is interesting because I would argue that "CT-based PKI" and "private PKI" are not opposites. It's totally plausible that a private-PKI-as-a-service provider would offer a CT- or MTC-style log to their customer so they can say "we're doing auth for you, but we'll let you audit what we today, using systems with the same guarantees as the Web PKI". That's more annoying to do with CT as a bolted-on thing. But if logging is intrinsically part of CA operations, and getting cosigners is just slightly reconfiguring you're software, maybe that'd be of interest to people? (I'm just spitballing here. I'm not aware of anyone who is thinking of this. I just think it'd be neat.)
But that's not quite what this says. This implies that "today's [...] CT-based PKIs" and "private [...] PKI" are opposites. And that's almost certainly true in practice. So... 👍
2 participants
See https://mailarchive.ietf.org/arch/msg/plants/4bdDJLDkQfsM7qiW5lW2PjBwKZY/