On Mon, Jul 22, 2024 at 12:52 PM David Benjamin <david...@chromium.org> wrote:
> I say sometimes because this is not always viable. It's a more indirect > way of addressing the root issue, so there are some limitations. First, > this requires foresight on the part of the service operator and client > vendor. If everyone knew ahead of time that the client might diverge (e.g. > by way of standing still while the ecosystem moves), then one might set > this up. But this is a perennial problem *because* people empirically do > not know ahead of time. Or perhaps the vendor even intended to continue > servicing their IoT devices, went out of business, but enough folks bought > them and continue to happily use them that some other service provider does > not wish to abandon them. > > We can try to help this by encouraging such foresight as best practice, > but it takes just one important client of one important server to gum up > the works. Trust anchor negotiation, if successful, provides a solution > that doesn't require as much deployment-level foresight. (If the IoT device > can negotiate trust anchors, it's easy. If it can't, the clients that *do* > negotiate > trust anchors can still evolve freely and do not add to the PKI > intersection problem.) > Yep, I absolutely look forward to a web where we have this sort of capability, either on endpoints themselves or even managed by a more-modern intermediary. I’m not informed enough to comment on the protocol elements of the specific Trust Anchor proposal, but I agree that more PKI agility will be healthy. Fundamentally, the TLS implementation community will be pushing this agility into endpoints by default, which means that it would take active divergence by a system implementor to create the sort of TBTF systems that impede trust changes today. Mike
_______________________________________________ TLS mailing list -- tls@ietf.org To unsubscribe send an email to tls-le...@ietf.org
